My negative views on Rust (2023)

"There are only two kinds of languages: the ones people complain about and the ones nobody uses".

---

Glad to see fluffy negative articles about Rust shooting up the first slot of HN in 20 minutes. It means Rust has made finally made it mainstream :)

---

The points, addressed, I guess?

- Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling

- Rust inserts Copy, Drop, Deref for you: it would be really annoying to write Rust if you had to call `.copy()` on every bool/int/char. A language like this exists, I'm sure, but this hasn't stopped Rust from taking off

- Fetishization of Efficient Memory Representation: ... I don't understand what the point is here. Some people care about avoiding heap allocations? They're a tool just like anything else

- Rewrite anything and it gets faster: okay sure, but there are limits to how fast I can make a Py/JS algorithm vs a compiled language, and Rust makes writing compiled code a bit easier. People probably aren't rewriting slow Python projects in C these days

- Rust is as complex as C++: ...no, it's not. Rust really hasn't changed much in the past 6 years. A few limitations being lifted, but nothing majorly new.

- Rust isn't as nice of community as people think: subjective maybe? People are nice to me at conferences and in discussion rooms. There's occasional drama here and there but overall it's been pretty quiet for the past year.

- Async is problematic: Async Rust really is fine. There's a huge meme about how bad it is, but really, it's fine. As a framework author, it's great, actually. I can wrap futures in a custom Poll. I can drive executors from a window event loop. Tokio's default choice of making `spawn` take Send/Sync futures is an odd one - occasionally cryptic compile errors - but you don't need to use that default.

I'm unsure why this article is so upvoted given how vapid the content is, but it does have a snappy title, I guess.

My big problem with Rust is too much "unsafe" code. Every time I've had to debug a hard problem, it's been in unsafe code in someone else's crate. Or in something that was C underneath. I'm about 50,000 lines of Rust into a metaverse client, and my own code has zero "unsafe". I'm not even calling "mem", or transmuting anything. Yet this has both networking and graphics, and goes fast. I just do not see why people seem to use "unsafe" so much.

Rust does need a better way to do backlinks. You can do it with Rc, RefCell, and Weak, but it involves run-time borrow checks that should never fail. Those should be checked at compile time. Detecting a double borrow is the same problem as detecting a double lock of a mutex by one thread, which is being worked on.

Needs (2023)

> I predict that tracing garbage collectors will become popular in Rust eventually.

The use of Rc is already very widespread in projects when people don't want to deal with the borrow checker and only want to use the ML-like features of Rust (Sum types, Option, Error etc.)

> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.

I wonder when we will see the rise of Haskell like LanguageExtensions in Rust. AFAIK, pretty much everybody uses things like GADT, PolyKinds, OverloadedStrings etc. The most similar thing I can think of Rust right now for is python-like decorator application of things like builder macros using Bon.

> Async is highly problematic

Agreed. Tokyo is the only reason, I think, anybody is able to use Rust for this stuff.

"X is as complex as C++" is a preposterous statement for all values of X.

A lot of people seem to assume that "C++ is complex" is referring to how the committee adds new language features every 3 years. The conventional wisdom that C++ is wickedly difficult to learn is NOT about "oh man, now I need to learn about the spaceship operator?" C++ is an almost unfathomably bottomless pit. From the arcane template metaprogramming system to the sprawling byzantine rules that govern what members a compiler auto-generates for you, and on to the insane mapping between "what this keyword was originally introduced for" and "what it actually means here in _this_ context, there is no end to it. Keeping up with new language syntax features is an absolute drop in the bucket compared to the inherent complexity required to understand a C++11 codebase, build it (with a completely separate tool that you must choose) and manage its dependencies (with a yet different completely separate tool that you must choose).

You don't have to know anything about Rust to know that saying "Rust has become complex as C++" is objectively incorrect.

> Distinguishing mutability has its advantages

I think it's misleading to say that Rust distinguishes mutability. It distinguishes _exclusivity_. If you hold a reference to something, you are guaranteed that nothing else holds an exclusive reference to it (which is spelled &mut). You are _not_ guaranteed that nothing accessible through that reference can change (for example, it might contain a RefCell or other interior-mutable type). Shared references (spelled &) usually imply immutability, but not always. On the other hand, if you hold an exclusive reference to something, you are guaranteed that nothing, anywhere, holds any kind of reference to it.

IMO, the fact that exclusive references are spelled "&mut", and often colloquially called "mutable references", was a pedagogical mistake that we're unfortunately now stuck with.

> People waste time on trivialities that will never make a difference.

This is an aha moment as I read it. The complexity of your tools must be paid back by the value they give to the business you’re in.

> People waste time on trivialities that will never make a difference.

Depending on the situation, memory layout could be trivial (copying 200 bytes once at startup vs. not in a way that should never be user-perceptible and difficult to even measure) or actually a big deal (chasing down pointers upon pointers in a tight inner loop). It's entirely situational. To dismiss all of that as "trivial" and saying it will "never" make a difference is not helpful. There are a lot of shitty apps that are impossible to get running reasonably without a total rewrite and their shitty use of memory is part of that.

I actually used to agree that Rust generally wasn't good for high-level application code, but working with Bevy has made me change that opinion for certain domains. I simply haven't seen a system that makes automatically parallelizing all application logic (game logic, in this case) feasible, other than Bevy and other Rust-based systems. The trick is that the borrow check gives the scheduler enough information to automatically safely determine which systems can run in parallel, and that's very powerful. It's not that you couldn't do this in C# or whatever--it's that you won't without a system that helps express your intent and enforces that those declarations are up to date.

For applications that don't need high performance for the CPU code and aren't systems code, sure, Rust may not be a good choice. I'm not writing the server-side code for low traffic Web sites in Rust either.

It's funny when people mention Go as the gold standard of not adding features to the language and Rust as ever-changing when Rust hasn't introduced any major changes in at least 3-4 years and Go introduced a major paradigm shift in how people structure their code (generics).

Before you start replying with "Rust introduced X" - ask yourself - is X extending an existing feature slightly or does it introduce an entirely new concept?

I learned to program around the peak of object oriented fetishization. Shortly after that came functional programming's moment, and now it seems we are slightly past Rust and other safety focused languages' peak period of hype. All three language families have useful things to offer, but were never the panacea their proponents claimed them to be. "No Silver Bullet" continues to be true.

Related:

My negative views on Rust - https://news.ycombinator.com/item?id=29659056 - Dec 2021 (89 comments)

I think to some extent Rust is a victim of its own unreasonable effectiveness. It is great at its narrow niche of memory safe low level programming, but frankly pretty good at lots of other things. But at these other applications some of its design principles get in the way - like the pedantic borrow checker. Languages not used outside their niches don't tend to collect such criticism.

Python is a bit like that. It is a top choice for a few things, and ends up used effectively for other things, simply because it is versatile. But then people run into issues with dynamic typing, zero static safety, start slapping type annotations everywhere... and bemoan Python as a bit of a horror show.

My use case for Rust is complementing Python, where frankly I don't care about half the complex features, still it's nicer than C or C++ to code in. The complexities of the borrow checker are more like a tax to me. I understand people who are frustrated with it thought, as otherwise they see it as a bit of a perfect language.

I like Rust but at the same time I agree with the points here. These things are indeed problems with Rust.

Nevertheless, C++ has even worse problems. When your alternative is using C++, that's the time to consider Rust.

Who uses panic instead of `?` and anyhow / Box<dyn Error> (error propagation?)

I think there is even a (gross) way to achieve try/catch around a block of code that panics?

Some points resonate with me:

> People don't want "to have to play Chess against the compiler"

Things that are easy to express in other languages become very hard in Rust due to the languages constraints on ownership, async...

> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.

It's indeed hard to keep up.

> Async is highly problematic.

Yes, more complexity, more fragmentation and feel like another language.

But one point feels unfair:

> the excellent tooling and dev team for Rust [..] pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in.

What? No. The main appeal was the safety. It's still a distinctive feature of Rust. To almost eliminate a whole class of safety issues. It has been proven by several lengthy reports such as https://security.googleblog.com/2024/09/eliminating-memory-s....

They are many projects for which the reliability and efficiency are worth the trouble.

i could buy an alphabet soup, add in some cereals, mix it up and throw it on the table, knowing it would end up looking indistinguishable from rust code.

I agree with a couple points here, specifically I agree that choosing a language based on it's community (and not it's ecosystem) is just silly. And we all know that async ended up being a bit of a thorn in rust's side.

But yeah, rust is very much a systems language: so it will be forcing you to think about memory layout one way or the other. Idk how valid of a complaint that is when you really consider that, and specifically the other alternatives you have.

rust is fine, it's a solid mix of performance and expressiveness, it has good constructs and it's gaining traction

it's hard to learn so we shall see what kind of niche it can carve for itself, but it's fine

So much to disagree with....

> In practice, people just want to be able to write a tree-like type without having to play Chess against the compiler.

Sure, Rust's strong encouragement of tree-structured ownership may be annoying when you try and make a spaghetti ownership soup, but it's not like it doesn't have upsides. Many people have written about how the ownership & borrowing rules lead to code structure that has fewer bugs.

> I think that if you rewrite anything from scratch with performance in mind, you’ll see a significant performance improvement.

Maybe, but I think this is missing the point. The "rewrote it in Rust and it's X times faster" stories are generally when people rewrite from very slow (Python) or medium fast languages (JavaScript or maybe even Go).

In those cases you can rewrite in Rust without considering performance and get amazing speedups. I recently did a straight 1:1 port of some Python code with zero extra optimisation effort and got a 45x speedup.

Sure I maybe could have got the same in C or C++ but there's no way I would have rewritten it in C++ because fuck segfaults and UB. I don't want to spend any more of my life debugging that.

> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.

I don't really know about Haskell, but I don't think Rust's complexity is anywhere close to as bad as C++'s. Even if it were it doesn't matter because in Rust if you forget some complex rule the compiler will tell you, whereas in C++ it will randomly crash but only in release mode after the program has been running for 2 hours. Totally different.

> The “Friendly” Community

Gotta agree with this though. The "we're friendly" thing is bullshit.

> Async is highly problematic

Also agree here. Async is a huge wart on Rust's otherwise relatively unblemished face. Big shame. Oh well. You can mostly avoid it, and there are some cases where it's genuinely good (e.g. Embassy).

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

I don't see why he's disappointed about this. Rust is great for command line tools and web backends.

> I think that the excellent tooling and dev team for Rust, subsidized by Big Tech, pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in. There’s danger in that type of thinking.

Ok this guy is not worth listening to.

I've read this before, it's been passed around the Rust community a few times.

The annotated tl;dr is: Chris doesn't want to learn how hardware works, they don't want to learn how to write optimal software, they don't want to write safe software, they just want to write in a language they already know because they're not comfortable with learning other languages because their home language is a functional language (Haskell). It's a weird, yet short, essay that doesn't actually go anywhere.

I suspect Chris wrote the essay against their will, or because people asking them about Rust rubbed them the wrong way, because they lash out and say "This post still offends many who have tied Rust to their identity, but that’s their problem, not mine."

Its the Internet, man, if you're not offending someone, nobody is reading your shit.