I hope something like Zig gets widespread adoption, including in embedded/IoT/automotive environments. Especially automotive. We're moving more and more life-and-death scenario-type tools into software.
There definitely is a design space for a simpler language than Rust that is easier to write, but Zig is too far on the side of C and has lots of trivially introducable unsafety. It's an improvement over C , but imo not enough.
I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve.
In some niches Rust is perfect, but in every language thread on HN there's often someone that suggests to use Rust whatever the use case. C, in that respect, is more flexible and gets out of the way much more, of course while being unsafer, but it's easier to keep your mind on the goal and not figuring out the best memory safe approach for this piece of logic.
Which is why I'm very excited for Zig. I don't want another C++. Give me safer C, thanks.
I've always wanted a "shut up about memory safety for a while, just don't free anything, I want to find out if my code produces the right answer" mode in rustc.
Beyond the correctness argument, also because the GC can really come back to bite you when you least expect, following the sudden "knee" of Little's Law. I've seen multi-minute pauses every few seconds even with V8's GC in production and it was not a pleasant experience. It cropped up, out of the blue, and in the end required a V8 core team member to advise and help comment out a few lines of C++ GC code that were overzealous.
GCed is orthogonal (as in: doesn't have anything to do) to type safety.
Java is GCed, so are Scala, Kotlin, C#, F#.
Even dynamic GCed languages towards the scripting side of things are moving to static typing: Typescript, Python Mypy, Ruby types (I forgot the name of the project).
To be honest I haven't used C in a long time, but I've been looking for a low level language that sparks as much joy as C does. Go, Rust ain't it, IMO.
Now there's an argument the front loading these decisions may be beneficial overall but I don't find that compelling either. After the "make it work" stage there's thinking about performance, comments, logging, etc and you usually need to think about lifetimes as they change at this point as well, so front loading it has only added work overall.
During the exploratory phase of my projects, I very rarely run into nontrivial lifetime issues, and when I do, I can just put whatever data into an Arc and then it just works. Most of my exploratory code is just objects that own their data.
Later in a project, while doing a bunch of refactoring to handle performance, logging, etc. , I have a much easier time letting the compiler tell me when I've made mistakes with a value's lifetime rather than trying to keep the whole program in my head for the duration of the refactor.
I don't spend a lot of time thinking about lifetime issues during either phase of my projects. Mostly I just write the same sort of thing that I'd have written in other languages, and the compiler tells me when I've made a mistake.
But especially in all those domains where memory safety is an issue , in my view it is currently the best option.
Rust forces you to think about memory safet and ownership, which is hard to adjust to for many. But it does so for a good reason.
In C you also have to think about lifetimes all the time, but the compiler let's you do whatever you want , and the issues instead have to get fixed when bugs pop up, or with static analysis tooling, etc.
"I don't want to think about lifetimes" is exactly how we end up with vulnet and buggy software.
After the initial learning curve, Rust is a very productive language, exactly thanks to the powerful type system.
Like I said, I do wish for a simpler language that can provide similar guarantees, and I do think the design space is in reach, but Zig is (currently) not it.
And taking this further, since Zig's convention around allocators is for them to be an explicit argument of all functions needing to allocate, it's trivial to write tests specifically to validate correct behavior in OOM conditions. There's even a custom allocator in the standard library for exactly this purpose.
Anyway, for Windows and other plateform where this is a reasonable goal, there is work in progress to add this to Rust. See this RFC[1] which has been merged and whose implementation progress can be followed here [2]
For example, if an attacker could arbitrarily inject overload to restart rate-limiting processes and then abuse this to trivially brute-force OTP logins.
The definition of safety with respect to a resource in general always needs to include the safety of the system as it crosses the threshold i.e. in this case into out-of-memory, so if a system claims memory safety, the first thing I would want to ask is, what about OOMs?
That's a really strange argument, because as soon as you're not in a GCed language, you need to think about the lifetime of your objects. The big difference with Rust is that you can't make mistakes when doing so, because the compiler will catch it.
You don't have the mental burden that if you make a mistake everything will blow up and you can focus on your business rules instead.
JetBrains went out of their way to make migrating to Kotlin as easy as possible: you can literally upgrade your Java project file by file.
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
As Java evolves and Kotlin needs to cater to Mountain View masters, upgrading the Java file won't be enough as many modern features don't exist on ART.
I think the first Kotlin version to use post-Java 9 bytecode is the Kotlin 1.4.20 using invokedynamic for string concatenation: https://blog.jetbrains.com/kotlin/2020/11/kotlin-1-4-20-rele...
Kotlin sealed classes are planned to be rendered as JVM sealed classes when JVM sealed classes go out of preview (probably Java 17), and the same is planned for mapping Kotlin value classes as Project Valhalla user-defined primitive types.
All these features obviously won't be available if you target Android, but they will still be there for you if you don't.
Faking JVM features on other platforms means that the performance is not the expected one when moving across them, and some surprises might happen when linking to libraries that use modern features.
Yes, offering a good path to switching (and conversely keeping the old voodoo part of the code no one wants to touch) is the way to go. And as I understand it, Zig offers this possibility as well.