[honr]

C++ (the language) and its extreme complexities (each perhaps added for a good reason at the time, and then held together with backward compatibility as glue) reduced itself to gcc and clang. Not the std lib. The std lib is, de facto, removing some of the complexity.

Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far better than it was, 15-20 years ago. While it is not exactly cool, it can be totally bearable.

My point is the current success can be "copied over" to rust by cloning (or otherwise obtaining) a good base std lib, and a few domain specific comprehensive libraries. That doesn't even need to affect the existing ecosystem. There can be several parallel ecosystems and each one can be relatively thriving (one doing nodejs style YOLO, one doing enterprise extreme best-practices, one doing efficient embedded or OS level work, etc.). However, apart from the nodejs style community, the rest will benefit [heavily] from a base library that is well designed and NOT subject to change. Even a travesty such as a vibe-cloned golang std lib would be an improvement over the current situation.

[pjmlp]

> Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far better than it was, 15-20 years ago. While it is not exactly cool, it can be totally bearable.

Which is the main reason why despite its warts, C++ is my go to systems language, when I need to do something outside Java, C#, node. It is anyway for "unsafe stuff" for the most part.

Additionally being the systems language those runtimes rely on, and for stuff like GPGPU.

Always use static analysers and hardened runtime, it isn't Rust, but still so much better than C.

> My point is the current success can be "copied over" to rust by cloning (or otherwise obtaining) a good base std lib,

That I agree as well, it cannot be that for basic stuff like general purpose error handling, or handling macros, we need to rely on third party crates. Or that for all pratical purposes, tokio is the async runtime.

[honr]

Honestly, at fundamental level, it is less of that need being dependent on third parties, and more of not having at least ONE set of consistent libraries (or one big library). To me the real value add of golang's std lib is not that it is developed by the language authored (that is maybe the third or fourth key point). The first one is the existence of one set (or 1.5, heh, if you consider golang.org/x slightly different) of libraries that are polished and hammered to be consistent together (primarily by spending an enormous effort on simplicity, but also on repeated polishes prior to the first notable public release and some thenafter). This is at the core of what I think rust needs right now to break through and penetrate into real C++ and golang circles.