Traits now support async fn and -> impl Trait (with some limitations), the compiler got faster, version = in Cargo.toml is now optional, and many small functions have been stabilized!
Sorry to ask, is Rust derived from another language? I know some c++, would that benefit me if I want to learn Rust?
What is powerful about Rust in comparison to other languages?
I find it’s a mix between ML languages and C++, and knowing one of them would help yes. If you’re tired if chasing a wild pointer because of a subtle use-after-free in a multithreaded monster under gdb, you’ll love #rust.
Honestly the only things that are similar to C++ are small amounts of C-like syntax, RAII, smart pointers, and iterators. And even so, Rust improves those features a lot. The list of things that Rust rejects from C++ is much larger; Rust does not have:
new and delete (perhaps discouraged in modern C++)
function overloading
inheritance (replaced by composition or traits)
friend classes (replaced by modules)
exceptions (replaced by Result values)
6 different kinds of first-class constructors (hallelujah)
templates (replaced by constrained parametric polymorphism)
variable mutability by default
Rust does OOP very differently and leans harder into functional paradigms.
The way I often describe it is “Rust makes functional programming feel as intuitive as object oriented programming”.
Pedantically, Rust does offer a subset of object oriented programming paradigms so one could argue that it counts as an object oriented language, but the design patterns that work the best with the language are all coming from functional programming, all without feeling too alien to someone coming from a strictly object oriented background (… which was my own path into Rust).
box::new is pretty directly analogous to std::make_unique (factory for unique_ptr), in general rust’s heap allocating types map to c++’s smart pointer types, which are basically universally recommended over raw new/delete. So another column where rust just gives you the one best C++ feature where it still has 4 supported versions.
Maybe Rust isn’t a good tool for massively concurrent, userspace software.
This conclusion is a very weak one.
The only argument the article successfully makes is that using the raw async/await mechanisms of the Rust language leads to situations where it’s tricky to figure out how to structure your code, and that the raw async mechanisms of some other languages don’t have that friction.
But why would we only consider the strengths of the pure out-of-the-box Rust language and forget that it has an enormous robust ecosystem of crates? For any given use case there will be suitable frameworks that make async Rust programming both natural and performant. Or if such a framework doesn’t exist it is possible to develop one on top of the async mechanisms of the raw language because those mechanisms are so unopionated by design.
My colleagues struggle with async Rust as-is. I did too for quite a while. But that’s why I’m developing two different async Rust frameworks for two different software architecture paradigms (one that fits nicely into an ECS and one that fits nicely into a deterministic scheduled worker pool) each of which we have different use cases for. If the Rust async design was more opinionated and imposing (which is what this article is recommending) then I likely wouldn’t be able to produce frameworks that are as effective for each of these use cases… one or the other would have suffered, likely both.
Add comment