My company devguard was – by numbers of deployments – the largest user of rust before we stopped using rust entirely.
So that plus me not being subtle about it, leaves people to question their choice of rust. I’ll try to answer that as best as i can.
Let me first establish the context of what we do. Devguard is an embedded systems company. We primarily do IoT at massive scale with insane deadlines on impossibly cheap hardware. The reason devguard is a successful company without any sales or marketing people whatsoever, is that we do stuff nobody can do.
If you do x86 cloud based web services, rust is a good choice
So ask yourself: are you doing anything unusual? The rust strategy – like almost all large communities – is very much prioritized by popularity, and if you do the thing with it that everyone does with it, the chances that it works are very high.
We at devguard do not do any of those things. Our biggest customer is mips custom chips, which is eternally broken on rust due to very novice toolchain design. rust has great support for building apps that work on linux, windows and mac. Very much like Qt. If you target anything else, you’ll be fighting upstream
If you have no responsibility, you can prioritize fun over results
Does your company or project have to make money? Does anyone die if your software fails? If it’s a startup or hobby, both of those are likely no, so you’re fine. Have fun, go rust.
Rust’s primary mission is to be empowering. What that vague mission statement in my experience means is that they’re welcome to newcomers. That’s a good thing for business, because hiring from an elitist community actually has higher development cost. Golang has the same idea, but Rob Pike comes with uncomfortable honesty
What it however also means is that they prioritize that over deep technical knowledge. Yes, coding can be fun, and I love seeing the creative ideas that come out of the maker community … at the maker fare, not in automotive emergency braking systems. Sometimes rules have reasons, and sometimes you need to shut up and read the scientific papers of people who do in fact know better.
If you have a cult, who cares about interoperability
My biggest and most personally frustrating complaint about rust is that it somehow became a purpose on its own, rather than a tool to do something. The developers are very isolated from the real world economic effects of their decisions. Somewhat on purpose i guess.
For example there’s a cognitive dissonance thing going on that rust has no runtime cost, because that’s what they advertise, and anyone finding workarounds for the actual very real runtime cost will feel the wrath of the cult, which sometimes ends up in acusing the offenders of not being politically correct enough.
Rust makes bold claims about being a system programming language, that is if you’re willing to build a new system around rust because all of the millions of dollars that chip vendors put in SDKs are somehow not usable
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.
Where do we go from here?
Is rust a bad language? no! Should you use it? yes!
That is unless you need to do anything commercial near hardware, then you should probably stay with the tools that have a huge amount of tooling to deal with exactly that. This is why i’m building zz. Drawing from rusts enthusiasm to make system programming less terrible, but also from decades of experience building hardware products at scale.
see also slides from rust and tell
The two main missions are:
- make raw pointers safe at compile time
- tie into the existing C ecosystem
We can finally have all those good tools that web service programmers have, but for real life embedded. Could you build web services with it? Probably, but I do think nodejs is the defacto standard there, which is why zz also compiles to nodejs modules automagically.
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.