3 ms·

> 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

> 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.

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.