
So long rust, why I built ZZ - est31
http://aep.github.io/from-rust-to-zz/
======
noncoml
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.

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

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

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

------
noelwelsh
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
More substance on the benefits of zz in their particular case over Rust or Zig
would have been appreciated.

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

don't ever use Zig

~~~
blandflakes
Ok, but why?

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

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

Missing digits?

~~~
steveklabnik
Whoops, yep. Should be million, not thousand.
[https://data.firefox.com/dashboard/user-
activity](https://data.firefox.com/dashboard/user-activity)

Sorry about that :(

------
aw1621107
The blog post has been removed.

Archive.org link:
[https://web.archive.org/web/20200331134855/http://aep.github...](https://web.archive.org/web/20200331134855/http://aep.github.io/from-
rust-to-zz/)

~~~
neonate
Also [https://archive.md/QZPm4](https://archive.md/QZPm4)

------
peterbraden
Contentless flame-bait, not worth reading.

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

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

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

------
juststeve
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?

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

