Hacker News is a community-driven platform for sharing and discussing technology news, startups, and programming-related topics. Through user submissions and comments, Hacker News offers insights into emerging technology trends, industry developments, and entrepreneurial ventures. Readers can participate in discussions, share their insights, and stay informed about the latest advancements in technology and innovation.

Hacker News

A critical examination of Rust's design tradeoffs, arguing that it fails to meaningfully improve upon C++ despite its promises. The author identifies four core issues: extremely slow compilation by design, complexity comparable to C++ without legacy justification, prioritization of memory safety over reliability (leading to crashes), and poor performance with mutable shared state. While acknowledging C++'s numerous flaws, the piece contends that Rust's borrow checker and ownership model create impractical development experiences, particularly for GUI applications, databases, and stateful services. The conclusion positions Rust as mediocre but viable for specific use cases like static site generators and parsers with immutable data flows.

Rust is a disappointment

<blockquote>
When you do <code>for i in 0..limit {}</code> — you don’t just iterate, you create a range, you create an iterator, you iterate over it — all of it monomorphized to your concrete types and have to be optimized individually
</blockquote>
Actually that’s just a for-next loop. If you were talking about <a href="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2024&amp;gist=9f11ec99f7489cf1a8bd7812b3745471" target="_blank" rel="noopener nofollow"><code>(0..limit).into_iter().for_each(|| {})</code></a>, you might have a point. But if you do that for simple index enumeration or other simple cases, your project manager or mentor should rightfully correct you. Partly because Rust has better options than simple (and tallable) index iteration.
<blockquote>
non-optimized Rust code is insanely slow, it’s mostly unusable even for debugging
</blockquote>
False.
<blockquote>
you will have to semi-manually pack all your data into a tree of ownership. You have to be fluent in ownership, borrowing, traits to write just a few lines of code
</blockquote>
False. Also, Rust’s ownership lifetimes merely make explicit what C++ allows or ignores: “Where does it come from, and how long is it valid?” I can violate ownership rules in C++, and C++ won’t even drop a warning. This is not a good thing. Trivially constructable C++ case:
<pre><code class="language-cpp">std::vector&lt;int&gt; items = {1, 2, 3};

int* a = &amp;items[1];

items.push_back(4);

std::cout &lt;&lt; *a;
</code></pre>
There seems to be four stages to learning the borrow checker:
<ol>
<li>Ugh this is so annoying.</li>
<li>Ok I think I got it figured out.</li>
<li>No wait actually it’s just making explicit something that always existed.</li>
<li>I’m starting to see ownership is a universal concept that all languages have, but that actually Rust pays attention to.</li>
</ol>
<blockquote>
You know the containers are actually implemented with unsafe functions
</blockquote>
The entirety of C++ is implemented using, effectively, <code>unsafe {}</code>.
<blockquote>
Rust designers went wa-a-ay overboard with memory safety… Rust sacrificed sanity and practicality for memory safety
</blockquote>
Opinion.
<blockquote>
and gets none of them at the end of the day, it’s still not 100% memory safe.
</blockquote>
So, in your opinion, anything less than 100% memory safety is equivalent to no memory safety whatsoever. I have some bad news for you, then. It’s impossible for any software to be 100% safe.
<blockquote>
We actually had a recent Cloudflare outage caused by a crash on unwrap() function:
</blockquote>
No production code should contain <code>.unwrap()</code> unless the app should CTD on failure. That being said, no software is immune to failure. Partly because it’s written by humans. Add “Add replace <code>.unwrap()</code> with proper error/failure case handling” to your procedures. <code>Option&lt;T&gt;</code> or <code>Result&lt;T, E&gt;</code> are still better than checking for null, or a failure state value, because they make the check explicit.
BTW, C++ has had <code>std::optional</code> since C++ 17, and <code>std::expected</code>, a <code>Result</code> equivalent, since C++ 23.
<blockquote>
It’s possible, but employing mutable shared state in Rust just makes no sense. You lose most of advantages and are left with all the deficiencies of Rust.
</blockquote>
<code>Arc&lt;RwLock&lt;T&gt;&gt;</code> gives you all the advantages of Rust, and mutable, shared state.
<blockquote>
Pretty much all of the successful Rust projects are employing shared read-only state, one way data flow, acyclic data structures:
</blockquote>
Shared read-only state with one-way data-flow and acyclic data structures, is a standard way to build large, enterprise-scale applications, because it simplifies a lot of the logic, and generally comes out faster to much faster than mutable state.
Rust’s ownership rules help ensure that read-only state is read-only, that shared data structures are either immutable, or safely mutable, and that data structures either actually are acyclic, or only contain safely mutable, indirect references.
The rest of the post is complaining that you can write bad code in Rust, and Rust can’t stop you. You can write bad code in any language, BTW.

He calls himself a Rust hater at the start, and create arguments that rely solely on bad developer choices. Using that mentality no language is good

I’m not a Rustacean, but this reeks of someone equating their insufficient understanding of a language with the language being bad.

Is a screwdriver is bad because it’s awkward to use with your foot?
Sometimes the problem is not with the tool but the user as most of the article goes on about how Rust is bad… if you do the things you shouldn’t do (that are also not the default way to do things).
This smells of someone not proficient with either C++ or Rust