4 ms·

I think eventually or at some point there might be a need for Rust 2.0 even if it won't be called Rust. Think something like JavaScript and TypeScript. A langua

by Ygg2 3y ago

I think eventually or at some point there might be a need for Rust 2.0 even if it won't be called Rust. Think something like JavaScript and TypeScript. A language that's a super set except the former would be soft deprecated. I know this is highly unpopular opinion, but I don't consider permanent backwards compatibility a good thing.

vimpunk 3y ago
What parts of Rust would you like changed, though? 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.
- lawn 3y ago
  async still feels half-baked and not pleasant like the rest of the language. 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.
- Taek 3y ago
  I would definitely want to see async totally overhauled. Also it would be great if major components of the standard library were all version 1. 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.
  - gmnash 3y ago
    A complete overhaul of async sounds nice in the abstract, but without exact details it’s difficult to see how it would be better than what exists. Similarly, I’m curious as to what the details of a “slightly less generic” type system entails.
- thayne 3y ago
  Besides the Move and Leak traits mentioned in this article, there are several changes I would make to the standard library if backwards compatibility wasn't a concern, including: 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.
  - afdbcreid 3y ago
    I'm curious about the "change channels to be mpmc" one. Why isn't it backwards-compatible? 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.
- deleted 3y ago
  [deleted]
ysavir 3y ago
I generally agree with you there. Permanent backwards compatibility has strong early rewards and strong late punishments. 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.
ferfumarma 3y ago
I agree, and would go even further: that all major versions of languages should be renamed. 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.
twic 3y ago
I'm not sure if it is an unpopular opinion; i'm not sure it's an opinion at all, since it seems like a statement of fact - no programming language lives forever, eventually being superseded by newer languages designed with the benefit of lessons learned with the older one. Except Fortran, Fortran is forever.
- Ygg2 3y ago
  And Ada, Ada was created perfect.
Guvante 3y ago
We still don't have C++ 2.0 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.
- tialaramex 3y ago
  WG21 ships a completely new language - very similar to but technically unrelated to the previous one - every three years. C++ 11, C++ 14, C++ 17, C++ 20, and (later this year presumably) C++ 23. It is fascinating that people consider the resulting arbitrary source code breaks to be complete compatibility and yet Rust's choice to offer ongoing compatibility to Rust 2015 edition (Rust 1.0) is somehow not enough... 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.
  - Conscat 3y ago
    > ruling out some optimisations GNU can chosen 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`.

by Ygg2 3y ago

vimpunk 3y ago

What parts of Rust would you like changed, though? 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.

lawn 3y ago
async still feels half-baked and not pleasant like the rest of the language. 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.
Taek 3y ago
I would definitely want to see async totally overhauled. Also it would be great if major components of the standard library were all version 1. 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.
- gmnash 3y ago
  A complete overhaul of async sounds nice in the abstract, but without exact details it’s difficult to see how it would be better than what exists. Similarly, I’m curious as to what the details of a “slightly less generic” type system entails.
thayne 3y ago
Besides the Move and Leak traits mentioned in this article, there are several changes I would make to the standard library if backwards compatibility wasn't a concern, including: 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.
- afdbcreid 3y ago
  I'm curious about the "change channels to be mpmc" one. Why isn't it backwards-compatible? 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.
deleted 3y ago
[deleted]

ysavir 3y ago

I generally agree with you there. Permanent backwards compatibility has strong early rewards and strong late punishments. 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.

ferfumarma 3y ago

I agree, and would go even further: that all major versions of languages should be renamed. 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.

twic 3y ago

I'm not sure if it is an unpopular opinion; i'm not sure it's an opinion at all, since it seems like a statement of fact - no programming language lives forever, eventually being superseded by newer languages designed with the benefit of lessons learned with the older one. Except Fortran, Fortran is forever.

Ygg2 3y ago
And Ada, Ada was created perfect.

Guvante 3y ago

We still don't have C++ 2.0 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.

tialaramex 3y ago
WG21 ships a completely new language - very similar to but technically unrelated to the previous one - every three years. C++ 11, C++ 14, C++ 17, C++ 20, and (later this year presumably) C++ 23. It is fascinating that people consider the resulting arbitrary source code breaks to be complete compatibility and yet Rust's choice to offer ongoing compatibility to Rust 2015 edition (Rust 1.0) is somehow not enough... 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.
- Conscat 3y ago
  > ruling out some optimisations GNU can chosen 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`.