Rust’s use of magical sugar constructs, where the compiler will automatically insert dereferences and copies and clones and drops for you has an initial appealing “it’s all simple underneath” quality to it, but in practice this leads to bad compile errors: The worst kind of compile error is the one where the compiler is complaining about something that it generated for you, rather than something you explicitly wrote.
Fair enough. Rust's error messages are great though, have been getting better all the time. Maybe one day they can get good enough that this won't be an issue anymore.
In practice, people just want to be able to write a tree-like type without having to play Chess against the compiler. I predict that garbage collectors will become popular in Rust eventually.
Fair enough. If you're not already very experienced with Rust, and don't need performance, it may be rational to use Python or something instead.
The use of unsafe is a little disturbing, because every library features it. But it’s not much different to using an FFI. I don’t see this is a big downside.
I have to assume that by "every library features it" they simply mean that many do. But this is not a fair comparison. The only reason Rust has unsafe blocks at all is because it achieves something that other systems languages don't even try to (compiler-guaranteed memory safety). In, for example, C or C++, literally all code is unsafe, in the sense of "unsafe" meant by Rust.
I see a lot of “we rewrote X in Rust and it got faster” posts. I think that if you rewrite anything from scratch with performance in mind, you’ll see a significant performance improvement. I’m suspicious of how much Rust itself is needed versus the developers having some performance discipline.
I'm skeptical of this claim, you're not going to microoptimize pure-Python data processing to be anywhere near the level of half-reasonably written Rust code unless you use a completely different algorithm. But I agree that RiiR is a bit of a bad trend, but for a different reason: rewriting something from scratch is extremely time consuming. Which is why I like to send people How to not RiiR (which is about how to create Rust bindings for existing codebases).
I’ve seen this play out for Haskell. Around 2007, when I started with Haskell, the community was friendly as anything, evangelic, open. People praised it for this. Everyone just felt blessed to be able to use this exciting language. Today, it’s more like any other community. What happened? People started using Haskell for real, that’s all.
Meh, I don't find it too convincing that language communities teleologically become more toxic as they start being "used for real." We'll see though.
Rust’s choice to exclude a runtime/scheduler blessed and built-in to the language means they had to develop alternative strategies in the language itself. This is not turning out well.
Nah, this was the right decision. There's a thread somewhere I can't find that explains better than me why this is. But basically, code "built-in to the language" is just libraries that everybody's stuck with forever, even if it was designed badly, even if they don't need it. And at the scale of complexity Rust operates at, it's basically impossible not to get things wrong. That's why the model of "have de-facto official libraries, and if a library is very essential and completely stable for several years, merge into the stdlib" works so well. And the presence of multiple competing async runtimes isn't just an artifact of decentralized figuring out of what's the best design, they serve different incompatible goals which different people need in different contexts.
I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things.
This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for.
That's true, Rust's popularity is resulting in people using it to write things like web apps which eg. Python is just fine for. I'm not convinced this is a bad thing though. I think that largely the reason for this is neither performance nor pure mass of popularity, but rather that, in ways unrelated to performance, Rust is just a really well designed language. Even if its commitment to being systems-level adds some complications that eg. Python can avoid.
