4 ms·

I see a lot of people comparing Rust favorably against C++, largely due to C++'s complexity. And yet at the same time, the Rust dev team are changing and expand

I see a lot of people comparing Rust favorably against C++, largely due to C++'s complexity. And yet at the same time, the Rust dev team are changing and expanding the language very quickly. Is there any plan to feature-freeze Rust? Otherwise it'll just become C++ 2.0 - a giant mass of features that are progressively designed to replace each other, until the language becomes too complex for any one person to master.

steveklabnik 7y ago
There is no plan to do that, but as time goes on, the bar gets higher and higher. We are not changing the language in backwards-incompatible ways.
- nrclark 7y ago
  Good to know. Worth pointing out that the C++ standards committee also almost never breaks backwards-compatibility. Instead, they just introduce The New Way (and then The Old Way becomes just one more trap). If you're in a position to affect this for Rust, it's worth thinking about. Give the documentation and libraries a few years to catch up, so that we don't have to chase a moving target. Maybe focus more on compiler and toolchain optimizations, and less on language features. It's a little rough to play in an ecosystem where the language itself effectively has a nightly/unstable variant.
  - steveklabnik 7y ago
    We are all very much aware :) That's very much been the theme of 2019 and 2020. 2019 really only saw the introduction of async/await as a new language feature. Almost all other additions were smaller things, like "this feature expanded a bit" or "this edge case is no longer an edge case." There was only one instance of something straight-up replacing the old thing; mem::uninitialized by MaybeUninit.
nicoburns 7y ago
Notably almost none of Rust's new features are replacing old ones. Most of them are either opening up new capabilities (e.g. async-await), or making existing mechanisms more general/flexible (e.g. const generics, GATs). It might accumulate cruft eventually, but I think it's at an inherent advantage over C++ due to its heavy functional influence, which is all based on math / PL theory. On the other hand C has always been a quick-and-dirty language, and C++ inherited a lot of that legacy. The macro system also helps a lot, as features can be prototyped as macros, and only stabilised once the design has been iterated and used. More niche features can stay as macros in 3rd party libraries.
- _bxg1 7y ago
  It also has years of crucial hindsight in language-theory. OOP and FP are both fairly mature at this point, and Rust started out of the gate by elegantly weaving them into a single coherent model, compared with C++ which started with neither (C) and had to monkey-patch both of them on, over the very decades when the ideas behind them were most actively evolving.
_bxg1 7y ago
My take is that it's an S-curve, which we're approaching the end of. Rust had a lot of ground to cover to include all the features people expect in a modern language. I think it very nearly has all the important ones at this point.

steveklabnik 7y ago

There is no plan to do that, but as time goes on, the bar gets higher and higher. We are not changing the language in backwards-incompatible ways.

nrclark 7y ago
Good to know. Worth pointing out that the C++ standards committee also almost never breaks backwards-compatibility. Instead, they just introduce The New Way (and then The Old Way becomes just one more trap). If you're in a position to affect this for Rust, it's worth thinking about. Give the documentation and libraries a few years to catch up, so that we don't have to chase a moving target. Maybe focus more on compiler and toolchain optimizations, and less on language features. It's a little rough to play in an ecosystem where the language itself effectively has a nightly/unstable variant.
- steveklabnik 7y ago
  We are all very much aware :) That's very much been the theme of 2019 and 2020. 2019 really only saw the introduction of async/await as a new language feature. Almost all other additions were smaller things, like "this feature expanded a bit" or "this edge case is no longer an edge case." There was only one instance of something straight-up replacing the old thing; mem::uninitialized by MaybeUninit.

nicoburns 7y ago

Notably almost none of Rust's new features are replacing old ones. Most of them are either opening up new capabilities (e.g. async-await), or making existing mechanisms more general/flexible (e.g. const generics, GATs). It might accumulate cruft eventually, but I think it's at an inherent advantage over C++ due to its heavy functional influence, which is all based on math / PL theory. On the other hand C has always been a quick-and-dirty language, and C++ inherited a lot of that legacy. The macro system also helps a lot, as features can be prototyped as macros, and only stabilised once the design has been iterated and used. More niche features can stay as macros in 3rd party libraries.

_bxg1 7y ago
It also has years of crucial hindsight in language-theory. OOP and FP are both fairly mature at this point, and Rust started out of the gate by elegantly weaving them into a single coherent model, compared with C++ which started with neither (C) and had to monkey-patch both of them on, over the very decades when the ideas behind them were most actively evolving.

_bxg1 7y ago

My take is that it's an S-curve, which we're approaching the end of. Rust had a lot of ground to cover to include all the features people expect in a modern language. I think it very nearly has all the important ones at this point.