36 ms·

He is complaining about fast 6 week release cycles for rustc, but actually things are petty stable atm. Most releases are just "x is also const now" or "we figu

He is complaining about fast 6 week release cycles for rustc, but actually things are petty stable atm. Most releases are just "x is also const now" or "we figured out how to relax type checks to allow this safe program to compile that was previously failing to past muster with the borrow checker". There hasn't been a big feature since async/await, and the noise around that is now in library user space - as was to be expected. There is a rust 2021 edition coming up, but that is also looking to be very modest with very few breaking changes. Like adding `TryFrom` to the standard prelude, and deprecating missing `dyn` keyword for trait objects.

kzrdude 6y ago
Const generics (minimal version) is coming in the next release.
eqvinox 6y ago
I would agree this post is putting the wagon before the horse — the release cadence doesn't really mean anything, the real question is what frequency do new things break your code at.
- cesaref 6y ago
  And how quickly do compiler/language bugs get fixed...
carlmr 6y ago
This "moving target" complaint comes up again and again. It's the classic elevator issue in reverse. If you want to make an elevator faster, put up mirrors so people look at themselves instead of their watch. Rust appears to change fast, because the changelogs are so detailed, but actually it's stable. Maybe we need to hide the detailed changelog and replace the main one with "minor bugfixes and constness updates".
- infogulch 6y ago
  No good deed goes unpunished. :(
- pdimitar 6y ago
  Please, never listen to people who complain about big changelogs! The transparency is hugely appreciated by many. It's just that the approving voices are usually silent while the disapproving ones are always loud. Don't let that mislead you. You are doing great.
foerbert 6y ago
>"we figured out how to relax type checks to allow this safe program to compile that was previously failing to past muster with the borrow checker" While perhaps not a large change in practice, this seems like the sort of thing that incurs a large cost when it comes to updating your mental model of how the compiler works, what it can and cannot do, and what options you have when it comes to implementing something.
- silveraxe93 6y ago
  https://xkcd.com/1172/ https://xkcd.com/1172/
- pdpi 6y ago
  The reaction to seeing code using these changes is "oh neat that works now". Every time I see changes like this in the change log, it actually simplifies my mental model, because the rules are the same but there are fewer exceptions.
- a_humean 6y ago
  I would suggest it does the exact opposite. Allowing more safe programs to compile if anything simplifies your mental model.
  - foerbert 6y ago
    The end result is a simpler model. The process of simplifying your model may not be cheap. It's like how you can get some weird set of complex rules and after a bit of time and practice you can just apply them without thinking much about it. However if you suddenly change those rules - even to make them simpler - you'll have to spend awhile readjusting. It doesn't make the changes bad, but it might explain why people trying to keep up with Rust feel it's changing more significantly than it actually is.
- mleonhard 6y ago
  My experience learning and using Rust over the last 9 months has included a lot of repeats of this: 1. Write some code that does something tricky with borrowed types 2. It won't compile. Search online for the error message. Find the Rust github issue about adding support for doing things that way. 3. Try to find or think up a different way to write the code. Go to 1. GP is referring to changes that make compilation succeed at step 1. These changes will save newbs from many hours of frustration. The cost of these changes is minimal. Actually they free up a lot of mental capacity currently used for workarounds. I'm really happy with Rust and the steady progress made by the core team. Rust stable is really excellent to work with.
Cthulhu_ 6y ago
I can understand it though; if you're on the ball (and you should be, because people have been burned by trying to update things after years of changes), every six weeks you'll get this ping, you need assess what changed and whether you need to take action. Contrast this to e.g. Go, which has a ~6 month update cycle, and most of the updates are boring. The main thing relevant to me personally for Go's recent 1.16 update is embedding files, and that's more of a "I can use it when I get to it" thing. Rarely does a Go update require action on my part, and since I started using it full time January last year, I've NEVER had to change any existing code. Neither required, nor because the language has solved something more clever. Granted, that could be considered a bad thing, and I wouldn't mind some additional features to reduce the amount of code I have to write and maintain, but still.
- zaarn 6y ago
  Tbh, for stable rust you don't need to do anything. Breaking changes to the stdlib or the compiler are incredibly rare (because the rust team tests against public crates to see if there is breakage). You will get broken code if you rely on nightly features or if you change edition. My nightly code breaks about once every few weeks but everytime one or two features begin moving into stable and it gets closer to being on pure stable rust, not requiring any unstable things anymore. So really, if you're writing rust to against stable rustc, you don't need to pay attention to much.
- DasIch 6y ago
  > [...]every six weeks you'll get this ping, you need assess what changed and whether you need to take action. Rust's stability guarantees mean that you don't need to take any action at all. Breaking changes (unless soundness is involved) only happen with editions and even when a new edition comes out and you update the compiler, you still don't need to do anything unless you explicitly change the configuration of the project to the new edition. The only thing you might want to do, if you use clippy (a linter that comes with the rust toolchain). Is to check whether it complains about your code due to new check. If that's the case, you get told what to change and why.
  - 6y ago

kzrdude 6y ago

Const generics (minimal version) is coming in the next release.

eqvinox 6y ago

I would agree this post is putting the wagon before the horse — the release cadence doesn't really mean anything, the real question is what frequency do new things break your code at.

cesaref 6y ago
And how quickly do compiler/language bugs get fixed...

carlmr 6y ago

This "moving target" complaint comes up again and again. It's the classic elevator issue in reverse. If you want to make an elevator faster, put up mirrors so people look at themselves instead of their watch. Rust appears to change fast, because the changelogs are so detailed, but actually it's stable. Maybe we need to hide the detailed changelog and replace the main one with "minor bugfixes and constness updates".

infogulch 6y ago
No good deed goes unpunished. :(
pdimitar 6y ago
Please, never listen to people who complain about big changelogs! The transparency is hugely appreciated by many. It's just that the approving voices are usually silent while the disapproving ones are always loud. Don't let that mislead you. You are doing great.

foerbert 6y ago

>"we figured out how to relax type checks to allow this safe program to compile that was previously failing to past muster with the borrow checker" While perhaps not a large change in practice, this seems like the sort of thing that incurs a large cost when it comes to updating your mental model of how the compiler works, what it can and cannot do, and what options you have when it comes to implementing something.

silveraxe93 6y ago
https://xkcd.com/1172/ https://xkcd.com/1172/
pdpi 6y ago
The reaction to seeing code using these changes is "oh neat that works now". Every time I see changes like this in the change log, it actually simplifies my mental model, because the rules are the same but there are fewer exceptions.
a_humean 6y ago
I would suggest it does the exact opposite. Allowing more safe programs to compile if anything simplifies your mental model.
- foerbert 6y ago
  The end result is a simpler model. The process of simplifying your model may not be cheap. It's like how you can get some weird set of complex rules and after a bit of time and practice you can just apply them without thinking much about it. However if you suddenly change those rules - even to make them simpler - you'll have to spend awhile readjusting. It doesn't make the changes bad, but it might explain why people trying to keep up with Rust feel it's changing more significantly than it actually is.
mleonhard 6y ago
My experience learning and using Rust over the last 9 months has included a lot of repeats of this: 1. Write some code that does something tricky with borrowed types 2. It won't compile. Search online for the error message. Find the Rust github issue about adding support for doing things that way. 3. Try to find or think up a different way to write the code. Go to 1. GP is referring to changes that make compilation succeed at step 1. These changes will save newbs from many hours of frustration. The cost of these changes is minimal. Actually they free up a lot of mental capacity currently used for workarounds. I'm really happy with Rust and the steady progress made by the core team. Rust stable is really excellent to work with.

Cthulhu_ 6y ago

I can understand it though; if you're on the ball (and you should be, because people have been burned by trying to update things after years of changes), every six weeks you'll get this ping, you need assess what changed and whether you need to take action. Contrast this to e.g. Go, which has a ~6 month update cycle, and most of the updates are boring. The main thing relevant to me personally for Go's recent 1.16 update is embedding files, and that's more of a "I can use it when I get to it" thing. Rarely does a Go update require action on my part, and since I started using it full time January last year, I've NEVER had to change any existing code. Neither required, nor because the language has solved something more clever. Granted, that could be considered a bad thing, and I wouldn't mind some additional features to reduce the amount of code I have to write and maintain, but still.

zaarn 6y ago
Tbh, for stable rust you don't need to do anything. Breaking changes to the stdlib or the compiler are incredibly rare (because the rust team tests against public crates to see if there is breakage). You will get broken code if you rely on nightly features or if you change edition. My nightly code breaks about once every few weeks but everytime one or two features begin moving into stable and it gets closer to being on pure stable rust, not requiring any unstable things anymore. So really, if you're writing rust to against stable rustc, you don't need to pay attention to much.
DasIch 6y ago
> [...]every six weeks you'll get this ping, you need assess what changed and whether you need to take action. Rust's stability guarantees mean that you don't need to take any action at all. Breaking changes (unless soundness is involved) only happen with editions and even when a new edition comes out and you update the compiler, you still don't need to do anything unless you explicitly change the configuration of the project to the new edition. The only thing you might want to do, if you use clippy (a linter that comes with the rust toolchain). Is to check whether it complains about your code due to new check. If that's the case, you get told what to change and why.
- 6y ago