8 ms·

As others have written, there's basically no connection between Rust's six week release cycle & the rate of actual change to Rust. If Rust switched to a 12 week

As others have written, there's basically no connection between Rust's six week release cycle & the rate of actual change to Rust. If Rust switched to a 12 week release cycle, all that would change is that it would take twice as long for features to reach users on stable once they were decided to be released. Feature development is neither release driven nor release constrained. However, the ground truth is that the design of significant new language features basically stopped in 2018. The work now is shepherding through the language extensions the project already committed to in the first few years after 1.0. For example, const generics, which will have a stable MVP in the next release, was first begun in 2017. Generic associated types, which are still not near stable, in 2016. And my own view, these remaining features are a nearly "feature complete" Rust. Future extensions will be either more niche (a lot of attention in the last few years has been aimed at features to make writing unsafe code less error prone, which wouldn't visibly impact users who write only safe code) or less substantial (such as a syntactic sugar that would improve a lot of users lives, but not deeply change how they write code). And that's actually very good.

nindalf 6y ago
Imagine if Rust only did releases every 18 or 36 months like other popular languages, or every six months like OP wants. Features that haven't been fully baked would be pushed in to the current release because people wouldn't want to wait another 6 months to see their work come to fruition. When the next release is only six weeks away, the cost of saying "aight, let's take our time and make sure it's ready before sending it out" is so small. The MVP of Const generics has been delayed by 6 weeks, upsetting exactly 0 people. Regular releases of the compiler are awesome for the same reason continuous deployment of web apps is - each release only packs a small number of features. The chances of something breaking are much smaller than if it was a massive release of hundreds of features, all of which need to be tested in isolation and then with each other. The releases page (https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md) shows how rare it is for a fix release to be made. Even when it is, it's something minor. Making the language easier to learn is a high priority. Many people are working on this actively right now - better documentation, better error messages, better IDE experience and so on. OP has misdiagnosed the root cause and blamed something that actually makes it easier to learn the language.
- robertlagrant 6y ago
  > Features that haven't been fully baked would be pushed in to the current release because people wouldn't want to wait another 6 months to see their work come to fruition. This psychological tinkering isn't helpful. People can push unfinished stuff in any situation. E.g. you can close it off 5 months in and then stabilise for a month. I don't think the OP is having trouble learning. They're having trouble with the almost-monthly changes.
  - ChrisSD 6y ago
    Here are the release notes for the last release: https://blog.rust-lang.org/2021/02/11/Rust-1.50.0.html https://blog.rust-lang.org/2021/02/11/Rust-1.50.0.html I'm curious, what in there would make someone have to deal with the changes?
    - jhugo 6y ago
      Maintaining ~30 Rust applications and a few libraries at work, a handful of open-source projects, and a few embedded Rust personal projects, I didn't need to change anything at all after updating (which is the norm for most Rust releases).
    - a_humean 6y ago
      I cannot imagine anyone would have to change anything.
    - estebank 6y ago
      In practice, the biggest things have been rustc and clippy lints starting detecting something that was either stylistically dubious or actually problematic previously existing in our codebase.
  - nindalf 6y ago
    > People can push unfinished stuff in any situation. But they don't in Rust. My example of Min Const Generics is an example of this. Async-Await (developed by GP on this thread) was also delayed to give it more time to bake. I urge you to look at the releases page (https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md). Look at how few user facing changes are made with every release. This is a good thing! As long as you're ok with skipping these and the performance improvements, you can stay on an older release for basically forever. Most Rust libraries are conservative about their minimum supported Rust version (MSRV) so there isn't usually a push to upgrade at all. If the OP wants a compiler and toolchain that only changes every six months, that's already available. He can stick with the same compiler for six months or even longer with 0 downsides.
DyslexicAtheist 6y ago
over-engineering in hope that the language does everything for everybody is my biggest worry and why my excitement to consider it as something I want to work with drops with every year. Considering how quickly the language evolves (which ought to be a good thing considering it's still new) I'm being put off by all these features that only few need, while at the same time things like async are broken by design (not to mention the opinionated tooling of cargo, rustup, etc that follow the same flawed principles as npm, rvm and even cpan). Perhaps I'm being too conservative but I'd have more trust in the language if things were moving slower especially that rust positions itself as a systems programming language fit for production (today). Which is odd because what I want from something that ticks these 2 boxes is interface stability. I have more confidence in Zig or Nim for this reason. Give it another 5 years and it will be a similar mess as C++, or worse: Python (which ended up rolling out v3 which wasn't backward compatible with v2). Also the "safety/security" argument which is their big selling-point which goes out the window as soon as you pull 3rd party crates (as is the case in most of the projects).
- roca 6y ago
  Suggesting that Rust will follow Python by forking the language incompatibly is completely unfounded. No-one has shown any interest in that, and the edition system was designed specifically to avoid any need for that. > Also the "safety/security" argument which is their big selling-point which goes out the window as soon as you pull 3rd party crates Not at all. Rust's safety guarantees work in practice. In years working on our largish Rust project we practically never have had to deal with memory corruption or data races.
  - herbstein 6y ago
    > Not at all. Rust's safety guarantees work in practice. They don't just work in practice. I spent 3 months last semester being taught in the separation logic "Iris", which is used to formally prove the safety guarantees of Rust as part of the RustBelt[0] project. That was under Lars Birkedal, for anyone curious. Rust is a language I love doing actual work in, but it's also one I really like from the perspective of the theoretical backing. [0] : https://plv.mpi-sws.org/rustbelt/
sylvain_kerkour 6y ago
Hi author here, This is just a report of the voices of the people I'm converting to Rust because they are never heard. The compound effect of small and fast changes is complexity. Uncontrolled complexity is the thing we want to avoid as it's fatal to any project. Yes there are editions. But from a newcomer's point of view they only add complexity. I'm convinced that short release cycle and feature 'bloat' are related. I simply don't want Rust to become the new C++ (which is the feeling of a lot of people).
- withoutboats2 6y ago
  I hope your book does well.
- _nalply 6y ago
  My opinion (programming with Rust since May 2015): Rust is complex but 2020 I discovered that in «This week in Rust» [0] many weeks pass with the section New RFCs No new RFCs were proposed this week This shows that the rapid pace of change already started to slow. [0]: https://this-week-in-rust.org/ https://this-week-in-rust.org/
- pas 6y ago
  The new C++ is unquestionably preferred to the old C++ (when nothing was standard or built in, everybody spent ages trying to build Boost, and so on). Software development / computer programming is complex. Hiding complexity is bad. News at 11. /s So, that said newcomers are free to pick their poison regarding tech stack, language, etc. They can use something simple, easy, friendly, and sort of self-contained. Let's say Ruby on Rails, Django, or C# stuff. Inevitably they'll very soon run into the problem of managing dependencies, platforms, native code, security considerations, performance issues, etc. Everything is a trade-off after all.
- carols10cents 6y ago
  > I'm convinced that short release cycle and feature 'bloat' are related. I simply don't want Rust to become the new C++ I'm confused... C++ doesn't have a short release cycle and it became feature bloated, so how did that lead you to conclude that the short release cycle of Rust is causing Rust to become feature bloated like C++?
rob74 6y ago
That may be true, but there are already discussions about revisiting some already-implemented features - e.g. Async (https://blog.rust-lang.org/2021/03/18/async-vision-doc.html https://blog.rust-lang.org/2021/03/18/async-vision-doc.html). So I'm not really optimistic that the pace of changes will slow down significantly...
- throwthrowayway 6y ago
  I read the post you linked and it doesn't seem to say that at all... it's about how async can be improved in general, not revisiting existing features. Did you mean to link somewhere more specific?
Peteris 6y ago
Exactly - this release train metaphor that Spotify uses explains this visually: https://medium.com/pm101/spotify-squad-framework-part-i-8f74bcfcd761 https://medium.com/pm101/spotify-squad-framework-part-i-8f74...

nindalf 6y ago

Imagine if Rust only did releases every 18 or 36 months like other popular languages, or every six months like OP wants. Features that haven't been fully baked would be pushed in to the current release because people wouldn't want to wait another 6 months to see their work come to fruition. When the next release is only six weeks away, the cost of saying "aight, let's take our time and make sure it's ready before sending it out" is so small. The MVP of Const generics has been delayed by 6 weeks, upsetting exactly 0 people. Regular releases of the compiler are awesome for the same reason continuous deployment of web apps is - each release only packs a small number of features. The chances of something breaking are much smaller than if it was a massive release of hundreds of features, all of which need to be tested in isolation and then with each other. The releases page (https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md) shows how rare it is for a fix release to be made. Even when it is, it's something minor. Making the language easier to learn is a high priority. Many people are working on this actively right now - better documentation, better error messages, better IDE experience and so on. OP has misdiagnosed the root cause and blamed something that actually makes it easier to learn the language.

robertlagrant 6y ago
> Features that haven't been fully baked would be pushed in to the current release because people wouldn't want to wait another 6 months to see their work come to fruition. This psychological tinkering isn't helpful. People can push unfinished stuff in any situation. E.g. you can close it off 5 months in and then stabilise for a month. I don't think the OP is having trouble learning. They're having trouble with the almost-monthly changes.
- ChrisSD 6y ago
  Here are the release notes for the last release: https://blog.rust-lang.org/2021/02/11/Rust-1.50.0.html https://blog.rust-lang.org/2021/02/11/Rust-1.50.0.html I'm curious, what in there would make someone have to deal with the changes?
  - jhugo 6y ago
    Maintaining ~30 Rust applications and a few libraries at work, a handful of open-source projects, and a few embedded Rust personal projects, I didn't need to change anything at all after updating (which is the norm for most Rust releases).
  - a_humean 6y ago
    I cannot imagine anyone would have to change anything.
  - estebank 6y ago
    In practice, the biggest things have been rustc and clippy lints starting detecting something that was either stylistically dubious or actually problematic previously existing in our codebase.
- nindalf 6y ago
  > People can push unfinished stuff in any situation. But they don't in Rust. My example of Min Const Generics is an example of this. Async-Await (developed by GP on this thread) was also delayed to give it more time to bake. I urge you to look at the releases page (https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md). Look at how few user facing changes are made with every release. This is a good thing! As long as you're ok with skipping these and the performance improvements, you can stay on an older release for basically forever. Most Rust libraries are conservative about their minimum supported Rust version (MSRV) so there isn't usually a push to upgrade at all. If the OP wants a compiler and toolchain that only changes every six months, that's already available. He can stick with the same compiler for six months or even longer with 0 downsides.

DyslexicAtheist 6y ago

over-engineering in hope that the language does everything for everybody is my biggest worry and why my excitement to consider it as something I want to work with drops with every year. Considering how quickly the language evolves (which ought to be a good thing considering it's still new) I'm being put off by all these features that only few need, while at the same time things like async are broken by design (not to mention the opinionated tooling of cargo, rustup, etc that follow the same flawed principles as npm, rvm and even cpan). Perhaps I'm being too conservative but I'd have more trust in the language if things were moving slower especially that rust positions itself as a systems programming language fit for production (today). Which is odd because what I want from something that ticks these 2 boxes is interface stability. I have more confidence in Zig or Nim for this reason. Give it another 5 years and it will be a similar mess as C++, or worse: Python (which ended up rolling out v3 which wasn't backward compatible with v2). Also the "safety/security" argument which is their big selling-point which goes out the window as soon as you pull 3rd party crates (as is the case in most of the projects).

roca 6y ago
Suggesting that Rust will follow Python by forking the language incompatibly is completely unfounded. No-one has shown any interest in that, and the edition system was designed specifically to avoid any need for that. > Also the "safety/security" argument which is their big selling-point which goes out the window as soon as you pull 3rd party crates Not at all. Rust's safety guarantees work in practice. In years working on our largish Rust project we practically never have had to deal with memory corruption or data races.
- herbstein 6y ago
  > Not at all. Rust's safety guarantees work in practice. They don't just work in practice. I spent 3 months last semester being taught in the separation logic "Iris", which is used to formally prove the safety guarantees of Rust as part of the RustBelt[0] project. That was under Lars Birkedal, for anyone curious. Rust is a language I love doing actual work in, but it's also one I really like from the perspective of the theoretical backing. [0] : https://plv.mpi-sws.org/rustbelt/

sylvain_kerkour 6y ago

Hi author here, This is just a report of the voices of the people I'm converting to Rust because they are never heard. The compound effect of small and fast changes is complexity. Uncontrolled complexity is the thing we want to avoid as it's fatal to any project. Yes there are editions. But from a newcomer's point of view they only add complexity. I'm convinced that short release cycle and feature 'bloat' are related. I simply don't want Rust to become the new C++ (which is the feeling of a lot of people).

withoutboats2 6y ago
I hope your book does well.
_nalply 6y ago
My opinion (programming with Rust since May 2015): Rust is complex but 2020 I discovered that in «This week in Rust» [0] many weeks pass with the section New RFCs No new RFCs were proposed this week This shows that the rapid pace of change already started to slow. [0]: https://this-week-in-rust.org/ https://this-week-in-rust.org/
pas 6y ago
The new C++ is unquestionably preferred to the old C++ (when nothing was standard or built in, everybody spent ages trying to build Boost, and so on). Software development / computer programming is complex. Hiding complexity is bad. News at 11. /s So, that said newcomers are free to pick their poison regarding tech stack, language, etc. They can use something simple, easy, friendly, and sort of self-contained. Let's say Ruby on Rails, Django, or C# stuff. Inevitably they'll very soon run into the problem of managing dependencies, platforms, native code, security considerations, performance issues, etc. Everything is a trade-off after all.
carols10cents 6y ago
> I'm convinced that short release cycle and feature 'bloat' are related. I simply don't want Rust to become the new C++ I'm confused... C++ doesn't have a short release cycle and it became feature bloated, so how did that lead you to conclude that the short release cycle of Rust is causing Rust to become feature bloated like C++?

rob74 6y ago

That may be true, but there are already discussions about revisiting some already-implemented features - e.g. Async (https://blog.rust-lang.org/2021/03/18/async-vision-doc.html https://blog.rust-lang.org/2021/03/18/async-vision-doc.html). So I'm not really optimistic that the pace of changes will slow down significantly...

throwthrowayway 6y ago
I read the post you linked and it doesn't seem to say that at all... it's about how async can be improved in general, not revisiting existing features. Did you mean to link somewhere more specific?

Peteris 6y ago

Exactly - this release train metaphor that Spotify uses explains this visually: https://medium.com/pm101/spotify-squad-framework-part-i-8f74bcfcd761 https://medium.com/pm101/spotify-squad-framework-part-i-8f74...