Rust is centred around its grandiose claims of safety, always boasting its guarantees of fearless concurrency, memory safety, zero-cost abstractions and other mumbo-jumbo.
First of all, there's nothing such as zero-cost abstractions. Any abstraction, no matter how close to what its meant to abstract, brings a performance penalty; it applies not only to Rust, but also to its rival languages like C++.
Secondly, concurrency is never a child's play. It maybe easy to spawn a couple of threads to do a task, but it also has to be considered whether that's actually beneficial or even detrimental to performance. The topic of concurrency is complex and hard to get right, and it demands hypothesis, experiments and observations. The algorithm that is designed to do the task in a non-concurrent scenario, may often be suboptimal in a concurrent scenario, and must be modified accordingly, given that it's even possible.
And, I've seen many—if not all—Rust users act with hostility towards unsafe code. I understand that often there's no need for unsafety, but in certain cases it has been shown in the past that performance is achieved through unsafety. And not just that, sometimes unsafety is a necessity, such as when dealing with FFI (Foreign Function Interface). Many take "safety for granted" without considering the circumstances where the unsafe code used to implement the safe interface may nondeterministically malfunction, which is the case with a lot binding libraries out there. Bindings exist because not all code has been rewritten in Rust, much to dismay of the Rust community. Not all bindings are high quality, complete or have excellent test coverage. In my personal experience, most bindings sorely lack (useful) documentation, and require examination of the source of the binding to understand how exactly is it interfacing with the underlying library (perhaps written in C or C++).
People coming from a background in C-like languages find Rust rather hard to understand at first, because in those languages the norm is to manually manage memory or resources (sockets, files, etc). However, Rust is based on the model of ownership and borrowing; i.e. a resource may have a single owner, and it can be mutably borrowed once, but immutably borrowed an infinite number of times. This rule doesn't encompass all use cases however, and concepts such as interior mutability or pinning have to be considered otherwise types such as Rc<T> (reference counted), Arc<T> (atomically reference counted) couldn't be implemented. Pin<T> exists an elusive concept of a pointer to a pinned value, for the sole reason that Rust couldn't afford move constructors like C++ and had to adapt with the fact that all moves in Rust are bitwise memory copies. But, the ownership model is promoted to newcomers as if its infallible.
The Rust community doesn't teach people to consider tradeoffs, and forces a singular authoritative opinion. The whole community thrives on meaningless politics1—always, right from the start. And, god forbid you make a remotely politically incorrect opinion, the entire community would cannibalise you!
And, last but not least, Rust lacks a stable ABI as of now, therefore when you compile a Rust project, all its dependencies must be compiled along with it no matter how large! Apparently, the Rustaceans believe in static linking everything—an excuse they provide for the lack of a (stable) ABI.
Checkout this blog by Arija A. (https://blog.ari.lt/b/rust-bad-ii/). She has done a great job of pin-pointing exactly where the deficits of Rust lie. Fuck Rust. Peace.
Addendum A
Ownership isn't the final answer to all problems. There's a resason the cell-types (
Cell<T>,RefCell<T>, and friends) exist; to go beyond the ownership-and-borrow principle.Concurrency is not parallelism
Besides, concurrency and parallelism are different. Concurrency is related to asynchronous programming. Parallelism is related to running simulatenous OS threads; sometimes on different machines as well. It's a topic that requires good hypothesis and analysis, and is not made any easier in Rust. You need to read that thick book you've been ignoring. Learning a little bit of rayon at a bootcamp isn't going to get you far — except coding toy programs ofcourse. Rust users pretend as if OpenMP doesn't exist.
More on
Pin<T>Besides, Rust's approach to asynchronous programming is quite awkward (with confusing topics like
Pin<T>), and is primarily Tokio-centric, despite providing options for other runtimes. And still, it's fragmented and not cohesive (even within the Tokio ecosystem), requiring a person to use various adaptors and other monkey-patching.Pin, a very confusing concept (I never fully understood), is fundamental to asynchronous Rust — for a coroutine requires to contain state: a self-referential structure, whose location must be invariant for it holds raw pointers (no, Rust's magic couldn't save us here) — was introduced in the first place as Rust couldn't afford move constructors like C++, because it would break the ownership model (i.e. a move couldn't be a simple bitwise copy of a variable). The designers stubborn and having no foresight, introduced Pin. It's meant to be a contract of the API developer and user, that the holder of a pinned reference to a variable is guranteed that it's memory location is invariant. Perfect. Now an incompetent design would lend itself to the same problem with C-like languages: dangling pointers. Where's your safety? Up your ass, bitch!