4 ms·

So long rust, why I built ZZ

58 points by est31 7y ago

NonEUCitizen 7y ago
Link to ZZ itself is way down the article. Here it is for convenience: https://github.com/aep/zz https://github.com/aep/zz
- chubs 7y ago
  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.
jleahy 7y ago
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.
- the_hoser 7y ago
  Agreed twice. Zig is doing some really neat stuff, and Jai is... an idea.
- ironmagma 7y ago
  I would love to see a Zig vs. ZZ vs. Rust vs. Odin comparison sometime.
  - jleahy 7y ago
    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.
    - ironmagma 7y ago
      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.
peterbraden 7y ago
Contentless flame-bait, not worth reading.
baq 7y ago
> 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.
steveklabnik 7y ago
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.
noelwelsh 7y ago
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.
- faitswulff 7y ago
  More substance on the benefits of zz in their particular case over Rust or Zig would have been appreciated.
  - vmchale 7y ago
    > the benefits of zz in their particular case over Rust or Zig don't ever use Zig
    - blandflakes 7y ago
      Ok, but why?
    - j88439h84 7y ago
      What about Nim or pony or ...
noncoml 7y ago
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.
aw1621107 7y ago
The blog post has been removed. Archive.org link: https://web.archive.org/web/20200331134855/http://aep.github.io/from-rust-to-zz/ https://web.archive.org/web/20200331134855/http://aep.github...
- neonate 7y ago
  Also https://archive.md/QZPm4 https://archive.md/QZPm4
nojvek 7y ago
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.
vmchale 7y ago
The author might like ATS, it is an academic project with many of the same choices.
juststeve 7y ago
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?

58 points by est31 7y ago

Link to ZZ itself is way down the article. Here it is for convenience: https://github.com/aep/zz https://github.com/aep/zz

chubs 7y ago
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.

jleahy 7y ago

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.

the_hoser 7y ago
Agreed twice. Zig is doing some really neat stuff, and Jai is... an idea.
ironmagma 7y ago
I would love to see a Zig vs. ZZ vs. Rust vs. Odin comparison sometime.
- jleahy 7y ago
  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.
  - ironmagma 7y ago
    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.

peterbraden 7y ago

Contentless flame-bait, not worth reading.

baq 7y ago

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

steveklabnik 7y ago

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.

noelwelsh 7y ago

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.

faitswulff 7y ago
More substance on the benefits of zz in their particular case over Rust or Zig would have been appreciated.
- vmchale 7y ago
  > the benefits of zz in their particular case over Rust or Zig don't ever use Zig
  - blandflakes 7y ago
    Ok, but why?
  - j88439h84 7y ago
    What about Nim or pony or ...

noncoml 7y ago

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.

aw1621107 7y ago

The blog post has been removed. Archive.org link: https://web.archive.org/web/20200331134855/http://aep.github.io/from-rust-to-zz/ https://web.archive.org/web/20200331134855/http://aep.github...

neonate 7y ago
Also https://archive.md/QZPm4 https://archive.md/QZPm4

nojvek 7y ago

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.

vmchale 7y ago

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

juststeve 7y ago

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?