Hi @sir - I wanted to respond to your post of today on Rust.
You open the post by saying that "Rust breaks a lot of stuff, and in ways that are difficult to fix."
What do you mean? Do you mean that the _existence_ of the Rust language breaks things? Presumably not; you later say that there is a "Rust cargo-cult" and that "Rewrite-it-in-Rust has become a moral imperative", but you don't offer any further elaboration on either of these points.
The rest of your post largely makes sense. Rust does not work on as many platforms as C; it is not diversely implemented; it is less simple. Your assertion that it requires "10× to 100× or more RAM, CPU time, and power usage" should be qualified with "at compile time", but that's a quibble.
1/4
The problem is that this all misses the point. Rust is extremely useful in some use cases _as it exists today_. I work at a company whose literally lifesaving business would be very difficult to achieve as reliably, or with as few developers or machines as today. Rust is moving our infrastructure in the direction of better energy efficiency, not worse.
We have issues with the immaturity of the ecosystem (though not, so far, the language itself), but our alternatives would be Ruby or Python, which are both used within our ecosystem and which are both slow and of which both have a higher rate of bugs; C, which would require more effort to represent the same complexity of data, and would almost certainly have more logic errors due to the lacking type system; PHP or Perl, which combine these problems; or another niche language, like Elixir, a Lisp, an OCaml, or perhaps Haskell.
2/4
Choosing Rust is an engineering decision; it comes with tradeoffs. Your post is clearly in reference to the Python cryptography package’s decision to require a Rust dependency, but your post elides that detail. There is a legitimate discussion to be had about whether that was a valid engineering decision, but given the age, reach, scope, and large network of the cryptography project, I think you need to assume that the maintainers of that project made that decision in good faith.
So, I’ll ask more specifically – what do you mean? When you ask the Rust team to “calm down”, what course of action would you prescribe? When you call a bunch of hard-working, brilliant, and talented FOSS and commercial developers “toddlers”, what do you expect to achieve? When you appeal to tired memes and the supposed prevalence of behavior the Rust community explicitly discourages, what are you trying to evoke? When you say that Rust “breaks a lot of stuff”, what do you mean?
3/4
Are you asking Rust to cease existing? Are you asking the core Rust team to tell people not to use Rust? Are you asking _other projects_ not to use Rust? Are you asking people to spend time implementing alternative Rust toolchains, bringing up new platforms, and improving compiler performance?
Please help the rest of us understand just what, if anything, you’re looking for. Rust solves real problems for real people and organizations. It is something genuinely new in the realm of systems programming, and while it’s not perfect, it’s not useless either. Some engineering decisions related to Rust cause problems for people, too, but you’re going to need to be a lot more specific if you actually want anything substantive to come from this discussion.
I generally appreciate your perspective, but you are way off base with your post here. I’d like to move this conversation in a more productive direction.
4/4
For context, this is the post I'm responding to. https://drewdevault.com/2021/02/09/Rust-move-fast-and-break-things.html
@tindall
Something drew didn't mention is Rust's support for WASM which is one of the best. I remember working with C++ and emscriptem and that was a nightmare but its been a while and that might have changed.
I've also had zero problems getting rust working on raspberry pis so I think Drew was a bit heavy handed about rust only working on tier 1 targets.
In my experience Rust has produced about equally preforming software compared to C++ at least as far as CPU time.
rust
@tindall While his post makes the tactless comments common to those who share his views on the subject...I think the crux of his concerns are thus: the pace at which Rust software is becoming essential feels reckless when compared to the pace of platform support and improvements to the bootstrap process. The "ask any distro packager that works with Rust" sentence is not used lightly—working with Rust on fringe platforms as a distro maintainer comes with a lot of pitfalls.
Void Linux on ppc is a perfect case study for this. Because there's no Rust spec and the compiler is self-hosting, bootstrapping is an arduous process of building each version of the toolchain in sequence, fixing any issues that crop up along the way. mrustc and the future gcc-rs can help with this, but only so much—they're still going to be dozens of versions behind the current "stable" Rust. (Points of reference: gcj reduces Java bootstrap length to 5, while gccgo has musl problems and Void resorted to official Go bootstrap binaries.)