There seem to be a ballooning number of entrants to the space of C-level languages recently (which is a fantastic thing after two decades with little going on).
Zig and Odin are the two others that have appeared recently, at least of the ones I can immediately recollect (in addition to Rust, of course). I'll discount Jai as it's currently vaporware. Zig seems to be doing some really impressive stuff especially around target/libc management.
Well Rust and ZZ are both trying to prove safety, Rust does it via the borrow checker and ZZ does it by formal verification. I would be surprised if the ZZ approach would scale beyond trivial examples (you're going to end up with programs that it can't give a yes/no answer to, that's always the issue with formal), but I'd be happy to be proven wrong.
Zig and Odin are both trying to be a "better C", they don't try to prove safety (that's up to you) but they try to make it harder to shoot yourself in the foot (and may end up being simpler than Rust as a result).
I don't know much about Odin, but Zig has some very nice features to help embedded development:
- All standard library containers allow you to provide your own allocator (there is no magical central allocator, ie. the dreaded 'malloc').
- All errors must be handled, including running out of memory.
- It's easy to just not use the standard library at all.
- Cross-compiling is a breeze (eg. you can just build a Windows .exe on Linux as easily as building a Linux executable).
- You can measure frame sizes so you know how large your stack needs to be (and thus guarantee your stack will never overflow).
Certainly I'd be interested in anyone's 'Zig vs Odin' if they've used both.
Thanks for the comparison! Another one in the fray I forgot to mention is Nim. With all these new languages marketing themselves in roughly the same way albeit with slightly different vocabulary and with similar syntax, it's difficult to iron out what exactly the differences are.
The ZZ language looks interesting, from a very quick skim. The blog post would have been a lot better if it swapped out the passive aggressive whining.
As a side note, I've had a few arguments with the author in the past, so I am not a neutral party here.
There's some stuff in this post that I feel like I should address. I'm not gonna go line by line, though I could, because this will be long enough. Just gonna cover the highlights:
> My company devguard was - by numbers of deployments - the largest user of rust before we stopped using rust entirely.
I don't actually believe this is true. The link at the end has a slide that says "We shipped a quarter million devices with rust." This is certainly a big deployment, but if we just consider Firefox, Mozilla reports ~800,000 YAU, and about 250,000 MAU. I don't think this is a problem; I want people to have a good time with Rust, regardless of how big they are. But when summed up with all the other stuff, well... I only even mention this because it frames this article as "Rust's largest user is leaving."
> If you target anything else, you’ll be fighting upstream
There is no fight here. These architectures require help to support. This is how open source generally works. If the author wanted to pitch in, we would have loved the help.
We'll get back to this later.
> If you have no responsibility, you can prioritize fun over results
We take our responsibilities very seriously. If Rust were about fun, we wouldn't put so much work into stability, or performance, or anything else. This section reads mostly like an insult, so I'm not really going to get into the rest.
> The recent ecosystem break with async has put the nail in the coffin for us, because again they put the burden of actually making their poor design work on the community, again hiding the true runtime cost (TLS) away from the user while ignoring any prior work on the topic.
This has been a persistent issue with the author. He wrote his own coroutine + async io system. In the release announcement, (and on twitter) he made a number of factually incorrect statements about Rust and async/await. The largest of which that you could not use it on embedded, when that was a hard constraint on the design in the first place. TLS is not a true runtime cost, as I mentioned in a thread yesterday, async/await no longer uses TLS. This was always the plan; the initial implementation was shipped using TLS so that folks who didn't mind could get started using it. The author links to a blog post by Ferrous systems (another company using and selling a lot of Rust in the embedded space, incidentally) about how this was accomplished. It seems like this is saying that we forced other people to fix some sort of mistake. This is not the case; like any open source project, there was some work to be done, and someone did it. (I am not sure if this work was sponsored by Ferrous or not, I think it was.) I think this sort of ties back into the earlier bit about architectures; Rust is not a company, nor a foundation. We have no money. We cannot support everything internally. This is how open source works.
But even then... jschievink is on the teams. So this is the Rust team building the feature.
---------
Anyway, I wish him well with ZZ. It sounds like it's a better arrangement for all parties involved.
The async on embedded work was mostly sponsored by Ferrous (dedicating Jonas and Jorge’s time to work on the bulk of it), but I know they both put a significant amount of personal effort into that work as well.
> Essentially ZZ is a tool built with a narrow commercial purpose, integrating into existing ecosystems for economic efficiency. If that sounds boring, it’s because its in fact boring. Real work creating real value is usually boring.
yes. well done for doing the right thing for your business.
ZZ looks genuinely interesting! I like that it compiles to C; this makes life much easier for embedded, say you're working with the ESP32 with it's obscure CPU there's no chance you'd use anything but the supplied C compiler. Could be an interesting option for systems/embedded programming.
i don't understand why he chose to build a new language? if rust sucks for embedded, why not spend you time helping improve it? if asm/C/C++ s so good, why not just continue to use his favorite language?
There are articles with good criticism of Rust. This is not one of them.
> My company devguard was - by numbers of deployments - the largest user of rust
Numbers?
> is that we do stuff nobody can do.
> Sometimes rules have reasons, and sometimes you need to shut up and read the scientific papers of people who do in fact know better.