I know this is highly unpopular opinion, but I don't consider permanent backwards compatibility a good thing.
I think the current version, with its minor warts, is a very pleasant and consistent experience for the most part -- very much unlike C++. So I'm not sure what I'd change to such a drastic degree that it'd require such breaking changes.
And if I want to risk going too far, I'd also advocate for refactoring the type system to be slightly less generic in favor of chasing faster compile times.
Also, ideally the lead designer of SafeLang2.0 would be much more heavy on engineering experience than PL theory. Rust made a lot of tradeoffs that were beautiful in PL theory but are annoying to use on a day to day basis.
I honestly think rust is equal parts amazing ideas and mediocre ideas, and I think a slighky less ambitious language would still be almost as safe (world class compared to any other language) but 10x more fun to use.
Similarly, I’m curious as to what the details of a “slightly less generic” type system entails.
Changing Iterator to make use of Generic Associated Types.
Change std::env::set_var to be unsafe. Because using it in multithreaded program causes undefined behavior for any c code that reads the environment (which includes quite a few libc and posix functions).
Change channels to have a better API that is mpmc and closer to crossbeam.
And probably others I can't think of at the moment.
About `std::env::set_var()`, there was a proposal for a `#[deprecated_safe]` attribute that triggers a warning if the function is used without an unsafe block, and eventually make that a hard error in future edition.
Now, it may be something that still can be fixed and improved upon, but a Rust 2.0 with nicer async experience would be a big win.
I'd love to see programming languages and frameworks add a "gamma" phase to their initial releases. Alphas can be for the internal development, betas can be for stuff that's being tested for bugs and functionality on a public level, and gamma can be a state of "the code can be used out in production, but the API and functionality may change in the future once we see how the tool is used and can identify and resolve operational bottlenecks". Just a handy state that says "feel free to use this, but keep in mind that the interface will likely change for the better but in a non-backwards compatible way based on your experiences using it".
I'm pretty sick and tired of almost every project needing a version 2 because version 1 was essentially publicly released proof of concept that didn't know better.
And if anybody brings up breaking changes in C++ I will point to how after any of those it sometimes takes almost a decade for everyone to update.
And that was for breaking changes designed to have minimal impact. See how Python 2 is still used in many places 15 years later for what happens if you change how strings work for example.
C++ already changed the definition of std::string, that's why your Linux distro went through painful C++ ABI changes many years ago. They went from one terrible string design to a different terrible string design, ruling out some optimisations GNU can chosen, but mandating optimisations other groups had chosen.
Don't worry though, they didn't standardize an actual string slice type (Rust's &str) until much later, as std::string_view in C++ 17, so most software which didn't actually care about string allocation needed to be thrashed around anyway because there was no vocabulary type for this most obvious thing aside from the hopeless C-style "nul terminated char *".
It's actually hard to over-estimate how terrible they are at this (language standardization). Is it really just that there are too many of them? I find it hard to imagine that just large numbers of people can explain it, plenty of people co-operate to create Rust and the results aren't anywhere close to as awful. Maybe it's the ISO process? I have never participated in ISO standardization of something this complicated, maybe the process is somehow poisonous.
But I think the best explanation is the culture. C++ has developed a culture which prizes arcane nonsense.
Everyone uses GCC C++ or MSVC C++ or Clang C++.
This includes the committee that makes the standard and requires a working battle tested implementation before inclusion.
So you get a Frankenstein result because that is the input.
And while yes in theory the standards define a kind of C++ that works on every compiler but the reality is most compilers don't fully support that for literal years best case.
So everyone uses what is available and writes abstractions to handle the harsh edges if they support multiple compilers.
This "requirement" is a mirage, as you can tell by simply installing any of the three compilers from say the week C++ 20 was published and trying to use the headline "modules" feature described in the standard. There are no working implementations.
If you've worked at a large dysfunctional organisation you'll recognise the pattern. Nobody wants to say "No" and make a decision themselves which may go badly - so instead they look for excuses and you're listing one of the excuses. But when they want to do it none of the excuses apply.
GNU didn't do any optimizations that are acceptable in a language with move semantics. The new `std::string` is _strictly_ better than the old one. Although there do exist very many superior string containers outside of the standard library. libstdc++ still supports the old ABI, by the way, as `std::__cxx11::string`.
There are people who make a lot of very short strings and need them to go fast, but not so many to justify making that a core language feature, if not for the fact that C++ empty string needs a zero byte for C compatibility.
That's why Rust got away without it, their empty string has length zero.
Except Fortran, Fortran is forever.
Like pearl and parrot, as I understand it.
It completely avoids the chance that "python" will become ambiguous regarding which set of rules it refers to: version 2 or version 3.
And the downside is minimal, because anyone can find the most current name online.