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 just ignore Zig. It will be there for you when you want it, and it will take you less than an hour to learn when the time comes that you want to use it.
zig is as small as c, perfect for my brain to actually be able to remember without checking some 100s page reference book like other languages have, learning it now.
my only 'wish' for zig is to replace its {} with indentations kind of like nim/python for readability.
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:
My understanding is that rust is a better C++, Zig is a better C. They're better than their respective antecedents in different ways (Rust is memory safe, Zig is ergonomic).
... wat? imperative; compiled to machine code, either static exe or dynamic libs; builtin RAII & polymorphism (parametric, subtyping); maps, vectors, trees, and other data structures in the stdlib; raw access to pointers; C ABI compat. there are some big differences, but "nothing like c++" is absolutely not true.
I see this line repeated a lot, especially in Zig spaces, but it doesn't really make sense to me. Rust is an excellent replacement for C, even though it has more features. What makes C the language of choice for so many applications is not its lack of features.
> I see [Rust : Zig :: C++ : C] repeated a lot, especially in Zig spaces, but it doesn't really make sense to me. Rust is an excellent replacement for C, even though it has more features.
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).
The feels are not very accurate. Rust adopted C++-like syntax to look less weird to C++ programmers, but semantically it is quite a different language. It's more like a low-level Ocaml than C++.
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.
> 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.
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.
I've done it with a few libraries. They usually have defined ownership, but it's specified in the library's manual, not in the code. Even unusual patterns can generally be mapped to Cow or Option or worst case some custom smart pointer with minimal amount of unsafe. But very often merely converting pointers to & vs &mut vs Box as appropriate gets the job done.
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.
C++ is the most important source inspiring Rust throughout its development. Rust devs just like to downplay that role.
- 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.
Sibling comment also says "has interface inheritance with pretty much the same syntax", but this is another case where people see the same ASCII char and think it's the same feature, when it's so different.
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++!
Rust limits programs (even when you use unsafe) to those you can prove correct to the copmiler, and it has a habit of taking on more dependencies than necessary for a given task (using syscalls and locks when not required, allocating frequently, ...). It's a nice language, but it made tradeoffs, and a meaningful fraction of C code would be hard to port to or even link from Rust.
It's been a long time since I've programmed in C, but AFAIK the major pain points were and continue to be the build system and the preprocessor (or consequences of those). Zig does seem to fix in a pretty simple way
It is not "better" it is different. Rust is "safer" although with the modern C++ along with tooling I do not really encounter any safety issues for about 3 years already. Looking at feature set C++ has way more. In my opinion Rust sits somewhere between C and C++.
I don't want to get grabbed on a side street and beaten but... Rust is language designed to solve a process problem (bad buggy code) with a straitjacket language approach. It is pedantic to the point of being unreadable and in it's own problem domain (system, embedded and up) has been ticking the wrong boxes.
Zig is substantially better yet I think a better language is still around the corner. Having said that, you absolutely can't go wrong mastering C. Zig wraps C in a way that doesn't choke you on configuration issues. Zig's out-of-the-box support for many target's is a savvy decision too.
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.
Rust is by far the more mature option if you're really trying to replace C++. Zig is personally interesting to me though. But if you need to write actual production critical code then you should definitely go with Rust.
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.
idk about a "war" or we, but features aside, zig feels like a less obnoxious language, and i mean that as politely as possible. to make an analogy, rust is like a friend that constantly nags about _everything_; like you know they mean well, but girl chill i know. about to cross a street, rust reminds you to look both ways. empty street with no cars around and it's safe to cross, rust wont let you cross until the crosswalk sign lights up. cooking something, rust will pester you about proper knife safety. like yes i know, being a nuisance about things i already know about doesn't help me write better software; i already know to look both ways before crossing. every once in a while it catches something you wouldn't have otherwise, but you have to deal with that constant pestering _all_ the time. also, just my personal opinion, but rust has some of the worst language ergonomics i've seen in any modern mainstream language and i don't think it can reasonably be fixed due to its 1.0 promise
Rust is annoying when you are doing something you know is sound, "yes I looked both ways and re-checked twice, chill out OK", but the compiler yells at you anyway. Zig is great in such situations. Rust really shines when you are doing something you are not confident at all in—juggling 17 knives, in a large codebase with many contributors that you are new to, and you haven't had any coffee—and you can relax because you know the compiler will catch your soundness mistakes.
I find rust easy to use when you are doing high level programming, but it becomes very annoying language when you are trying to do something low level, or trying to manage memory yourself.
"Rust vs. Zig" is like "Ruby vs. Python": both languages occupy more or less the same space, but have a rather different approach to things. Which is "better"? It's kind of a matter of preference and taste.
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.
I hear this repeated quite often in Zig crowds, but Rust is absolutely, 100% aiming to displace C. There's no way it would have made it into the Linux kernel otherwise. It just so happens that it can also replace most of C++, which is why it's also found in the Windows kernel.
Not sure I follow your line of reason. From a technical standpoint, I see only one reason why Rust could not completely replace C. And that reason is obscure hardware platforms that LLVM doesn't target. Otherwise, it's superior in every way I can imagine. More complex? I guess that depends on your project. If you work mostly in small code bases where it's easy to get things right, then I'd say it's a toss up. But if you're dealing with a large multi-threaded code base, with lots of heap allocations and shared ownership etc... Rust will be far less complex than C. I highly doubt the Linux kernel developers introduced Rust to add more complexity. They did it to reduce complexity in the system, and make it more accessible to new developers. The Rust compiler is soooo liberating once you get over the initial learning curve, which I admit can be a little annoying.
There are a vast number of “obscure hardware platforms” especially once you include embedded systems. There are also many circumstance where you must write unsafe code. While you could in theory use Rust for most cases where C is being used, there are a lot of cases where it would be a bad fit. There will never be one language that can do everything well.
For those obscure hardware platforms, I agree that Rust isn't a good tool for the job. (Although there are GCC integrations for Rust too, which may solve those issues in the future). But arguing that having to write unsafe Rust means it's a bad fit, makes no sense. 100% of C is "unsafe" in the sense of the word, whereas you may reduce that close to 0% with Rust. Even if you only got to 50%, that's a large chunk of your code base that you have certain guarantees about, simply by compiling it. Anyway, my whole point here is that I haven't heard any good arguments about why Rust isn't a good C replacement, other than the fact that it cannot target as many platforms. If it targets the ones you care about, then it's a wonderful choice to replace C.
For a lot of cases, 0% unsafe code is pretty unrealistic. Using even 50% unsafe code means that you must be able to reason about how safe and reliable the code really is. At which point you are better off with a simple language that a good developer can quickly figure out what is happening. A complex language makes this harder, not easier.
I think we can just disagree here. But I have to assume you haven't done any significant development in Rust, or at least haven't experienced the freedom it gives once you get over the initial awkwardness. I find Rust is easier to reason about than C, partially because it's more explicit. And that its compiler is better than a good C developer. I've mentored many veteran embedded C developers who scoffed at Rust with a similar attitude. Within a month or two though, they all changed their tune and came to prefer it.
You are basically attacking a strawman. It is not Rust vs. C, but Rust vs. alternatives to C. It is unlikely that Rust will end up being better than all alternatives that are being developed.
Not any more than there was a C/C++ war. C++ is for people that aren't scared of features and want their code to be reliable. C is for people that really value simplicity and don't care about the odd segfault or catastrophic security vulnerability (in some situations that is reasonable).
