3 ms·

Tbf, Rust is catching up fast to become the same mess (especially in the stdlib). > it's safer and higher productivity than C or assembly Debatable - in C and

Tbf, Rust is catching up fast to become the same mess (especially in the stdlib). > it's safer and higher productivity than C or assembly Debatable - in C and even more so in assembly, the unsafety is at least directly in your face, while in C++ it's cleverly diguised under C++ stdlib interfaces (like dangling std::string_views, all the iterator invalidation scenarios etc... meaning that memory corruption bugs may be much harder to investigate in C++ than in C (or even assembly) - which in turn affects productivty (e.g. what's the point in writing higher level buggy code faster when debugging takes much longer). > it feels like a matter of time before Rust replaces C/C++ It may replace C++, but C will most likely outlive at least C++, and I wouldn't be surprised if Rust too - even if just as C API wrappers to allow code written in different modern languages to talk to each other ;)

kibwen 2y ago
> Tbf, Rust is catching up fast to become the same mess (especially in the stdlib). I've never seen any users who avoid using Rust's stdlib on principle. The closest thing is the use of the parking_lot crate over the standard Mutex types, but that's getting better over time, not worse, as the stdlib moves closer to parking_lot in both implementation and API. Other than that, there's only been one "wrong" API that needed to be deprecated with a vengeance (mem::uninitialized, replaced by mem::MaybeUninit). Especially compared to C++, the fact that Rust doesn't have a frozen ABI means it's free to improve the stdlib in ways that C++ can only dream of. While I do wish that the Rust stdlib contained some more things (e.g. a standard interface to system entropy, rather than making me pull in the getrandom crate), for what it provides the Rust stdlib is quite good.
- vlovich123 2y ago
  Ironically c++ as well refused to define an ABI. That’s not why the language is bad. It’s the lack of editorial tools within the language the standard body has so it has no evolution path and thus ossifies under its own inertia. It’s amazing they still haven’t done anything about it.
- accelbred 2y ago
  I avoid the Rust stdlib. The stdlib uses panics and dynamic memory allocation, neither of which are great for embedded usecases or writing software adhering to safety-critical coding practices. no_std is common for embedded targets, and IIRC the linux kernel couldn't use stdlib because of panics.
vlovich123 2y ago
> Rust is catching up fast to become the same mess (especially in the stdlib) Care to provide examples? I think they generally do a very good job at curating the APIs to feel very consistent. And with editions, they can fix almost any mistakes they make whereas c++ doesn’t have that. In fact, the situation in c++ is so bad that they can’t fix any number of issues in basic containers and refuse to introduce updated fixes because “it’s confusing”. The things they keep adding to the stdlib aren’t even core useful things that come out of the box. Like missing a networking API in 2025. The reason is they have to get it perfect because otherwise they can’t fix issues and they can’t get it perfect because networking is a continuously moving target. Indeed we managed to get a new tcp standard before c++ even though it had even worse ossification issues. Or not caring about the ecosystem enough to define a single dependency management system because the vendors can’t get agreement or a usable module system. Or macros being a hot mess in c++ some 20 years after it was already known to really suck. Now it’s possible given enough time rust will acquire inconsistent warts over time similar to c++, but I just don’t think it’ll ever be as bad in the standard library due to editions and automated migration tools being easier against rust. Similarly, I think editions give them the flexibility to address even many language level issues. Inertia behind ways of doing things are the harder challenges that are shared between languages (eg adoption of Unsend might prevent the simpler Move trait from being explored and migrated to), but c++ is getting buried under its own weight because it’s not a maintainable language in terms of the standard because the stewards refuse to realize they don’t have the necessary editorial tools and keep not building themselves such tools (even namespace versions ended up being aborted and largely unused).
- flohofwoe 2y ago
  Just look at the Option type and all the methods on it, the whole concept of optionals should be built into the language, not stdlib: https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html Same with Result, Box, Rc, Arc, Cell, RefCell, (plus even more *Cells), Iter, ... the resulting 'bread crumbs syntax' is IMHO the main reason why typical Rust code is so hard to read. This philosophy to push what should be language features into the stdlib is the same as in C++ (and IMHO one of the main problems of C++), it's probably also a reason why both languages are so slow to compile.

kibwen 2y ago

> Tbf, Rust is catching up fast to become the same mess (especially in the stdlib). I've never seen any users who avoid using Rust's stdlib on principle. The closest thing is the use of the parking_lot crate over the standard Mutex types, but that's getting better over time, not worse, as the stdlib moves closer to parking_lot in both implementation and API. Other than that, there's only been one "wrong" API that needed to be deprecated with a vengeance (mem::uninitialized, replaced by mem::MaybeUninit). Especially compared to C++, the fact that Rust doesn't have a frozen ABI means it's free to improve the stdlib in ways that C++ can only dream of. While I do wish that the Rust stdlib contained some more things (e.g. a standard interface to system entropy, rather than making me pull in the getrandom crate), for what it provides the Rust stdlib is quite good.

vlovich123 2y ago
Ironically c++ as well refused to define an ABI. That’s not why the language is bad. It’s the lack of editorial tools within the language the standard body has so it has no evolution path and thus ossifies under its own inertia. It’s amazing they still haven’t done anything about it.
accelbred 2y ago
I avoid the Rust stdlib. The stdlib uses panics and dynamic memory allocation, neither of which are great for embedded usecases or writing software adhering to safety-critical coding practices. no_std is common for embedded targets, and IIRC the linux kernel couldn't use stdlib because of panics.

vlovich123 2y ago

> Rust is catching up fast to become the same mess (especially in the stdlib) Care to provide examples? I think they generally do a very good job at curating the APIs to feel very consistent. And with editions, they can fix almost any mistakes they make whereas c++ doesn’t have that. In fact, the situation in c++ is so bad that they can’t fix any number of issues in basic containers and refuse to introduce updated fixes because “it’s confusing”. The things they keep adding to the stdlib aren’t even core useful things that come out of the box. Like missing a networking API in 2025. The reason is they have to get it perfect because otherwise they can’t fix issues and they can’t get it perfect because networking is a continuously moving target. Indeed we managed to get a new tcp standard before c++ even though it had even worse ossification issues. Or not caring about the ecosystem enough to define a single dependency management system because the vendors can’t get agreement or a usable module system. Or macros being a hot mess in c++ some 20 years after it was already known to really suck. Now it’s possible given enough time rust will acquire inconsistent warts over time similar to c++, but I just don’t think it’ll ever be as bad in the standard library due to editions and automated migration tools being easier against rust. Similarly, I think editions give them the flexibility to address even many language level issues. Inertia behind ways of doing things are the harder challenges that are shared between languages (eg adoption of Unsend might prevent the simpler Move trait from being explored and migrated to), but c++ is getting buried under its own weight because it’s not a maintainable language in terms of the standard because the stewards refuse to realize they don’t have the necessary editorial tools and keep not building themselves such tools (even namespace versions ended up being aborted and largely unused).

flohofwoe 2y ago
Just look at the Option type and all the methods on it, the whole concept of optionals should be built into the language, not stdlib: https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html Same with Result, Box, Rc, Arc, Cell, RefCell, (plus even more *Cells), Iter, ... the resulting 'bread crumbs syntax' is IMHO the main reason why typical Rust code is so hard to read. This philosophy to push what should be language features into the stdlib is the same as in C++ (and IMHO one of the main problems of C++), it's probably also a reason why both languages are so slow to compile.