news.ycombinator.com
Several core problems with Rust | Hacker News
There were multiple failures before that `unwrap()` and the argument can easily be made that this is no different than an unchecked exception or a release assertion. > Sync/Send, Mutex and reference counting (Arc)? Unfortuantely, those lock or simply mess with CPU caches badly, so they are inefficient for multithreaded communication, at least an intensive one. They are safe, but inefficient. Which kinda destroys the first uncompromising thing in Rust — performance. … There’s a handful of pain points that the Rust model does impart which are not fundamental. For example, unsafe code is required to get a mutable borrow to two different fields of a struct at the same time. But really that’s the only example I can think of offhandedly, and I expect there are not many in total. Nearly all of the pain is merely the trouble of thinking through these issue upfront instead of kicking the can down the road. … ... 1. Previous claims that Rust code often just works after compiling. 2. Previous claims that low-level error-handling idioms like matching, using Result, etc improve code reliability. 3. Previous claims that using unwrap in example code is ok for brevity. Also, Rust developers would know not to use it in production code. 4. The fact that significant portions of the internet were taken down because a production unwrap from a big, mature player and one of the Rust early adopters. … However, this article is overall not at the level expected of Rust anti-fans in 2025. I commend the author for trying, but they need to improve in several areas like providing iron-clad real-world examples, proving the required level of experience, focusing more on pain points like dependencies and the potential for supply-chain attacks, addressing reskilling issues and internal corporate politics, etc. There was a blog by a veteran Rust game developer a while back which single-handedly destroyed the enthusiasm for Rust in gaming. That is the gold standard of Rust criticism for me. … - Mutable shared state: make bad designs hard to write. Mutable shared state is another one of these eternal bug sources. Use channels and pass messages. Honestly, it reads like a lot of critiques of Rust: people haven't spent enough time with it, and are not over the learning curve yet. Of course everything is cumbersome before you're used to it. … > Honestly, it reads like a lot of critiques of Rust: people haven't spent enough time with it, and are not over the learning curve yet. Exactly. I’ve spent years with rust and my complaints are very different. Well, I still wish it compiled faster but all the other stuff is noobie problems. As someone with more experience, my frustration points are things like how async blocks do compiler magic you can’t write yourself. I hate unnameable types. I think Pin is confusing and weird. And the syntax for interacting with raw pointers is unnecessarily inconvenient and ugly.
Related Pain Points3件
Async Rust complexity creates a separate, difficult programming model
7Async functionality feels like a completely different programming model from synchronous Rust, causing many developers to avoid it entirely. The complexity is cited even by non-beginners as a major pain point affecting framework choices and code architecture.
Multithreaded communication primitives are safe but inefficient
6Sync/Send semantics, Mutex, and Arc provide memory safety for concurrent code but have poor CPU cache behavior and performance characteristics, undermining Rust's performance-first positioning for intensive multithreaded applications.
Unsafe code required for aliased mutable borrows within structs
4Getting mutable borrows to different fields of the same struct simultaneously requires unsafe code despite the compiler being able to verify memory safety, creating friction for common programming patterns.