So long rust, why I built ZZ | Hacker News Reader

So long rust, why I built ZZ

aep.github.io

58 pointsest3124 comments

Open articleView on HN

The author comes across as a know it all bigot with some personal grudge against Rust developers/community.

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.

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.

Agreed twice. Zig is doing some really neat stuff, and Jai is... an idea.

I would love to see a Zig vs. ZZ vs. Rust vs. Odin comparison sometime.

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.

More substance on the benefits of zz in their particular case over Rust or Zig would have been appreciated.

> the benefits of zz in their particular case over Rust or Zig

don't ever use Zig

Ok, but why?

What about Nim or pony or ...

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.

> Mozilla reports ~800,000 YAU, and about 250,000 MAU

Missing digits?

Whoops, yep. Should be million, not thousand. https://data.firefox.com/dashboard/user-activity

Sorry about that :(

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.

The blog post has been removed.

Archive.org link: https://web.archive.org/web/20200331134855/http://aep.github...

Also https://archive.md/QZPm4

Contentless flame-bait, not worth reading.

> 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.

Link to ZZ itself is way down the article. Here it is for convenience:

https://github.com/aep/zz

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.

Seems author took down their blog post.

> had to remove this again, because my random rants keep trending on hackernews, and really don’t have the time to write quality blog posts.

Would love it if he at-least left a non-emotional summary.

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?

The author might like ATS, it is an academic project with many of the same choices.

Reply on news.ycombinator.com