Is there a Rust vs Zig war going on? I just started to learn Rust because I figured that it was going to be the C++ successor and I want to be sure that my skills are (somewhat) future-proof. So what's going on with Zig? Should I learn Zig?
You can't tell me what to do!
Please no
It's a language made for people who like to do things a certain way both in terms of technical details (eg no macros, no hidden control flow) and when it comes to governance of the project (small, independent, non-profit organization free from big tech influence). While we do believe that there's value in this approach, this doesn't mean any other way of doing things is now obsoleted in favor of what we're doing :^)
More in general, Zig and Rust are different enough that if you spend enough time to properly evaluate both, you will probably find one more congenial to you than the other. I like Zig because I like simplicity, somebody else might like Rust because they like sound memory safety guarantees and a powerful type system.
You shouldn't see Zig as a threat to Rust, also because Rust already succeeded pretty much, and in fact I would recommend Rust as the much safer bet if you're looking for a new language to bet on, all else being equal.
> Is there a Rust vs Zig war going on?
Uhhh, no? There are certainly different sensibilities at play when it comes to the different communities, but that's it. I think I understand where this is coming from, but I really feel compelled to point out that I find crazy how people get really worked up when it comes to programming languages and immediately assume there has to be a fight for ultimate dominance there, while instead are completely oblivious about actual wars being fought under their noses. If you want to look at a war, watch Deno vs Bun, where different VCs have backed a different horse, and now they truly are in a battle for dominance. The ZSF has taken no VC money, has no big tech company brand to bolster, and lives off of donations. We just want to be able to move forward with the development of Zig and, for as long as we can do it, all is good, no need to convert the entire planet.
If you do end up evaluating Zig, I would recommend reading these two non technical blog posts about the ZSF & the people involved with it:
https://kristoff.it/blog/interfacing-with-zig/ https://kristoff.it/blog/the-open-source-game/
It’s the feels, not the features :) Rust code feels like C++ code, at least when you’re reading it (I haven’t written any worth talking about). It puts the problem domain in similar terms, it has similar transparency (or lack thereof) regarding what it’s copying or allocating or whatnot, and so on. In that respect (!) they are closer to each other than C is to either—at least vanilla C, not a DSL (“language overhaul mod”?) like GObject. And it makes sense to target the C side of that divide in a new language (though again I lack the experience to say to which degree Zig succeeds in hitting that target).
Notably:
• Rust doesn't have inheritance. This makes a lot of basic C++ programming patterns unfit for Rust, and prevents 1:1 translation of C++ to Rust.
• Rust's generics may look like C++ templates, but they're not. Rust's macros behave more like C++ templates, and generics are closer to C++ concepts, but neither is a close match. C++ programmers are generally flabbergasted how hard is to make a function that takes any integer type in Rust.
• Even though Rust copied C++ moves, and has "RAII", the way these are used in practice ends up different due to having opposite defaults and different guarantees. Rust doesn't have constructors. Its closest equivalent of exceptions is for a different purpose. Rust's types are always movable, don't have meaningful addresses, can't reference own fields. Even C++'s std::string is hopelessly incompatible with Rust.
C++ has two string types, because of C legacy. Rust has two (and more) string types to express different modes of ownership. C++ is a complex language, because they keep adding more ways to initialize a variable. Rust has exactly one way. But Rust has many other features, mostly in its type system, to define thread-safety, memory-safety, and memory management in detail that is beyond what C++ can express. So "but they're both big" is glossing over all the reasons why.
However, C happens to be almost a clean subset of Rust. You can take a C program and translate it line by line to Rust. It won't be idiomatic, but may be easy to refactor into proper Rust. That's generally not true with C++, which requires rethinking everything from basic idioms and constructs to the overall architecture. This is why Rust struggles with GUI libraries, and the best-supported native toolkit is from C.
I can't see how that's possible, unless you litter your code with `unsafe` all over the place. Rust requires a lot of restructuring around ownership and borrowing to get your code to even compile.
The most common sin is C libraries taking just a pointer and hoping for the best, instead of pointer+length for buffers (slices). But that's also a "local" problem you can fix by adding an extra argument, generally not a major redesign.
Thread-safety tends to be worse to map, because C reasons about safety of function calls, while Rust about sharing of data types. So "it's safe to call foo unless option bar is set to -5" doesn't translate well.
The A:B syntax is not inheritance, but a syntax sugar for 'A where Self:B' bound.
The result is these remain separate traits without support for subtyping. dyn trait A:B can't be used where B is required, unless you have access to the concrete type and make a new vtable for B from scratch. There's WIP to fix that, but not here yet. The auto traits that look like subtyping are for built-in marker traits only.
Lack of data inheritance is painful. There's no support for fields in traits. Getters/setters are problematic due to borrowing all of self instead of just the field.
Traits can't have private or protected methods.
Traits aren't inherent to the types, so you have to import both the type and the trait to use it. It's messy and makes interface docs confusingly fragmented.
So Rust really really isn't an OOP language, even though you can put together an awkward-to-use imitation from a few ill-fitting features — but they use the same sigils as OO in C++!
You can enjoy my Rust version of Raytracing on one weekend, then again maybe not.
Just like being an FP language doesn't mean does it like Haskell. Many of which even predate Haskell's birthdate.
Plenty of ACM, SIGPLAN, IEEE, and EUROCOOP papers on the matter, including a few ones from a certain Simon Peyton Jones.
- Rust has interface inheritance with pretty much the same syntax
- Rust’s generics are monomorphized, exactly like C++ templates. They also have the same syntax. The only difference is that Rust generics are trait bound.
- Rust RAII is used exactly as it’s used in C++. Moves in Rust are destructive, while in C++ they are not. At the time where move semantics were proposed for C++ in the C++03 era, both types were proposed and the committee decided to go with non-destructive moves.
- Scope resolution syntax is also a carryover from C++.
When the words superset and subset are used in regards to C, C++ and Objective-C, it is quite a misunderstanding to describe C as a subset of Rust.
Yeah, there are some borrowed concepts, but it's a different language.
However, those who use C because they like the language would not enjoy Rust one bit and would much prefer Zig over it.
Zig and rust are both modern iterations of low level languages.
Rust chooses safety with more complex syntax. Zig chooses a less complex syntax with less safety.
What it has over Modula-2 feature checklist is mostly comptime.
However, both Zig and Rust make some of the same errors so I will put my plea here for future language developers. How you work with Threads, Async, Interrupts are all implementation details. Please don't make them part of the language. A good Function type is sufficient to make elegant solutions that do not require language support.
Honestly, it's still a little bit surreal to me that I won't even consider C++ now for a new project after so many years of my career.
Good blog post to this effect: https://matklad.github.io/2023/03/26/zig-and-rust.html
That said, Zig is still very much in active development and isn't stable. For example the upcoming 0.11 release will change some syntax. Personally I like Zig, but you need to be prepared to deal with these kind of changes and instabilities for the time being, much like early Rust adopters had to before 1.0. Also the Zig ecosystem is less mature: fewer libraries, learning resources, etc. Purely objectively speaking, I think that's the biggest difference at this point.
So I'd say stick with your plan, as there is going to be Rust around for a long time.
It's rather early to learn Zig, as it's not stable yet. It might be worth learning if you're curious and want to tinker.
Use which ever one you enjoy using.
With so many great choices, after a point it comes down to personal preference.
It's basically the same with Rust vs Zig.