| > For regular application code there's no real benefit Can't disagree, naive garbage collected code would outperform naive Rust code that allocates Strings and Vecs up the wazoo. And performance isn't a real issue with simple CRUD/ORM-type services. Wrapping business logic in newtypes and enforcing specific invariants for them and serde style "parse don't validate", can do wonders for business logic, but then again you can probably just use a garbage collected functional language with dependent typing and a bunch of other tricks in its hat, and get more mileage out of it, if that's the code you write. > It's not really a systems language because of all the hidden memory allocations C and C++(especially) can hide memory allocation just fine themselves. Allocations are pretty explicit in Rust, but layers of libraries can hide those (if you don't use no_std and the like), just like in C or C++. > lack of a stable ABI there is the C ABI, a stable Rust ABI at any stage would just be an optimization killer and a massive PITA, ask C++. Stable ABI, international standard, and multiple implementations of the compiler, are not a requirement for a systems language. For a language that relies on compile-time monomorphization, a stable ABI beyond what C already provides gives precious little. Swift ABI forgoes monomorphization, but it's not really a trade-off a systems language should embrace. The template header issue in C++, I won't even touch. There are also crates in the ecosystem that can generate 2-way FFI glue code to provide a stable ABI for Rust based on extern "C". > It's garbage for embedded because of all the gratuitous copies you have to make to appease the borrow checker. It blows up your memory budget. We use embedded Rust on a memory constrained MCU and besides slightly increasing the maximum stack size (because less is allocated on the heap), memory budget is not an issue we have. And in LLVM 16, Rust's stack usage will decrease even more, due to recent optimizations. You don't need to use "gratuitous copies", you can statically allocate just fine, and if your value is ephemeral and is read/mutated by multiple threads, heap allocating with reference counting is just fine. |