The big difference (inasmuch as I am aware) is in source compatibility in practice. If I use a header file, as any pre-C++-20 library will (have the major comp

The big difference (inasmuch as I am aware) is in source compatibility in practice. If I use a header file, as any pre-C++-20 library will (have the major compilers implemented modules yet?), I am SOL. I am specifying a text-import of that library’s code into my code. You’d need an “extern C++11”. As for comparing them at 10 years old, apparent language size might be similar, but in terms of program complexity C++ would be DOA. You’re telling me it takes an equal amount of time to learn these languages, but with Rust I can write code that works on the first try, while with C++ I have to account for data races and memory mistakes at every level of my program? Why do I, a 90s programmer dealing with OSes without process separation and soon the dotcom boom, want to touch that with a 10-foot pole? Java and C# would not exist. There’d be far too little value proposition with an alternative to C++’s memory-unsafety to justify the development of a whole new language. You’d probably see the equivalent of Python and JavaScript (probably named RustScript following the logic of the time). There’d probably be a Go equivalent developed, ie “language that compiles fast and runs almost as fast as Rust that stresses language simplicity”. Language expressiveness and simplicity are at odds with each other and there are uses of both. To be fair, Rust was developed with the last 30 years of programming in mind. But the thing is, memory safety kept on being a central issue of the languages that followed. The next big design issue will probably have more to do with people trying to use LLMs as a first-class programming language. Eg something that’s easy for LLMs to write and humans to read. Or something to do with heterogenous computing resources all sharing the same “program”. However here Rust seems already positioned to do well with its compile-time tracking of asynchronous resource dependencies between threads of computation, and procedural macros that can invoke an external compiler. So I’m not sure that conventional language design is going to change the path it’s been on for the last 30 years until the human side of that interface starts to significantly change. Most of the language design considerations we’re discussing boil down to “make things manageable to humans with limited memory”. If cybernetic augmentation or bioengineering sharply expands those limits, I suppose it could change the direction. Otherwise it feels like things are going to naturally cluster around “complex correct thing” and “simple iterable thing” because those are the two strategies humans can use to deal with complexity beyond the scope they can keep in their head at once.