6 ms·

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

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.
  - tubularhells 6y ago
    6 months in an enterprise setting means that we will never touch Rust.
    - paavohtl 6y ago
      There are generally speaking no breaking changes. Upgrading the toolchain practically never requires any changes to code.
      - DyslexicAtheist 6y ago
        > Upgrading the toolchain practically never requires any changes to code. if you work on safety/security critical systems upgrading the toolchain is considered like changing the tires on a moving vehicle. We have introduced and many weeks later discovered critical (and hard to trace) bugs simply by changing -O2 to -O3 in gcc that ended in sporadic crashes when cross-compiling for 1 specific platform. (which is a change much less severe than upgrading gcc itself) And I'd be surprised if upgrading the toolchain wouldn't potentially introduce similar hard to trace issues in rust. My point is that just because the first 2 months after upgrade look like there were no required changes in code doesn't mean there are none. I see rust being used in very large companies for internal projects, test harnesses, and other glue/plumbing. And the places I know are really reluctant to go all the way in and substitute their ~30 years of experience with C/C++ with something that remains a constantly moving target. To be fair there are other reasons such as culture, and distribution of skills across the team that drive these decisions but my main point still holds (i think).
- afarrell 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. The former comment is thoughtfulness about the ways that a system of work influences contributors mindset and thereby project quality. Even if the specific conclusion was incorrect, the earnest attempt is necessary to project health. If you disagree, you probably want to short-sell Toyota stock.
  - robertlagrant 6y ago
    What on earth is projecting health?
    - fernandogmo 6y ago
      I read it the same way at first but maybe they mean "necessary to the health of the project".
      - afarrell 6y ago
        Yes. By “project health”, I mean is “the health of the project”.
- roca 6y ago
  I was at Mozilla when we switched from 3-to-6-monthly releases to 6-weekly releases. It really was an enormous positive improvement. > you can close it off 5 months in and then stabilise for a month. This doesn't help. If a release happens every six months then regardless of what you do during the release cycle, you are faced with situations where someone has a work item just about ready to ship in release X, but not quite, and you face enormous pressure to ship it in release X rather than in release X+1 six months later. On the flip side if you do force it to slip to release X+1 then that's several months of users not having the benefit even though it's ready. If you're releasing every six weeks, there isn't any such pressure. Less work is shipped prematurely, less work is shipped later than necessary, and developers are less stressed.
  - dragonelite 6y ago
    At the company I worked at right now we went from releasing every sprint at a specific release window. To lets release whenever we want because we have some blue-green support. And it has been a game changer if you ask me, Jira tickets don't pile up in the test lane, testers don't have to do one big regression tests at the end of the sprint just to sure. Sometimes even making them work overtime just to be sure. The code area that introduced new bugs is way smaller and the bugs have become easier to trace down.
ddevault 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. Only if Rust has an awful leadership team organizing those releases. Strong leadership and careful release planning nips this right in the bud. "Your feature was only 'finished' a week ago? No way in hell is it making the release. See you in six months." The other view is that shipping less frequently encourages features to be shipped fully baked and matured, with plenty of time for careful thought and attention given to their design and implementation.
- steveklabnik 6y ago
  The point is, you build a process that encourages the outcome you want. A six-week release cycle makes it easier to do the right thing. Even with the six week cycle, we do this, with const generics being the latest example. But it's much, much easier to say "hey it's just six more weeks" than "hey it's just three more years," not just on the folks making the decision, but on the folks doing the work, and on the folks excited to use the feature. > shipping less frequently encourages features to be shipped fully baked and matured, Right, but this is just a view. A significant part of the industry believes that shipping less frequently discourages this. We've found that shipping more frequently allows us to take our time and fully bake and mature features in Rust.
turminal 6y ago
> 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. Developing a compiler for a complex language is very different from developing a webapp.
- GolDDranks 6y ago
  It sure is, but do you have any substantial reason to say why that would invalidate the point they are saying, "each release only packs a small number of features"?

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.
- tubularhells 6y ago
  6 months in an enterprise setting means that we will never touch Rust.
  - paavohtl 6y ago
    There are generally speaking no breaking changes. Upgrading the toolchain practically never requires any changes to code.
    - DyslexicAtheist 6y ago
      > Upgrading the toolchain practically never requires any changes to code. if you work on safety/security critical systems upgrading the toolchain is considered like changing the tires on a moving vehicle. We have introduced and many weeks later discovered critical (and hard to trace) bugs simply by changing -O2 to -O3 in gcc that ended in sporadic crashes when cross-compiling for 1 specific platform. (which is a change much less severe than upgrading gcc itself) And I'd be surprised if upgrading the toolchain wouldn't potentially introduce similar hard to trace issues in rust. My point is that just because the first 2 months after upgrade look like there were no required changes in code doesn't mean there are none. I see rust being used in very large companies for internal projects, test harnesses, and other glue/plumbing. And the places I know are really reluctant to go all the way in and substitute their ~30 years of experience with C/C++ with something that remains a constantly moving target. To be fair there are other reasons such as culture, and distribution of skills across the team that drive these decisions but my main point still holds (i think).
afarrell 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. The former comment is thoughtfulness about the ways that a system of work influences contributors mindset and thereby project quality. Even if the specific conclusion was incorrect, the earnest attempt is necessary to project health. If you disagree, you probably want to short-sell Toyota stock.
- robertlagrant 6y ago
  What on earth is projecting health?
  - fernandogmo 6y ago
    I read it the same way at first but maybe they mean "necessary to the health of the project".
    - afarrell 6y ago
      Yes. By “project health”, I mean is “the health of the project”.
roca 6y ago
I was at Mozilla when we switched from 3-to-6-monthly releases to 6-weekly releases. It really was an enormous positive improvement. > you can close it off 5 months in and then stabilise for a month. This doesn't help. If a release happens every six months then regardless of what you do during the release cycle, you are faced with situations where someone has a work item just about ready to ship in release X, but not quite, and you face enormous pressure to ship it in release X rather than in release X+1 six months later. On the flip side if you do force it to slip to release X+1 then that's several months of users not having the benefit even though it's ready. If you're releasing every six weeks, there isn't any such pressure. Less work is shipped prematurely, less work is shipped later than necessary, and developers are less stressed.
- dragonelite 6y ago
  At the company I worked at right now we went from releasing every sprint at a specific release window. To lets release whenever we want because we have some blue-green support. And it has been a game changer if you ask me, Jira tickets don't pile up in the test lane, testers don't have to do one big regression tests at the end of the sprint just to sure. Sometimes even making them work overtime just to be sure. The code area that introduced new bugs is way smaller and the bugs have become easier to trace down.

ddevault 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. Only if Rust has an awful leadership team organizing those releases. Strong leadership and careful release planning nips this right in the bud. "Your feature was only 'finished' a week ago? No way in hell is it making the release. See you in six months." The other view is that shipping less frequently encourages features to be shipped fully baked and matured, with plenty of time for careful thought and attention given to their design and implementation.

steveklabnik 6y ago
The point is, you build a process that encourages the outcome you want. A six-week release cycle makes it easier to do the right thing. Even with the six week cycle, we do this, with const generics being the latest example. But it's much, much easier to say "hey it's just six more weeks" than "hey it's just three more years," not just on the folks making the decision, but on the folks doing the work, and on the folks excited to use the feature. > shipping less frequently encourages features to be shipped fully baked and matured, Right, but this is just a view. A significant part of the industry believes that shipping less frequently discourages this. We've found that shipping more frequently allows us to take our time and fully bake and mature features in Rust.

turminal 6y ago

> 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. Developing a compiler for a complex language is very different from developing a webapp.

GolDDranks 6y ago
It sure is, but do you have any substantial reason to say why that would invalidate the point they are saying, "each release only packs a small number of features"?