Hacker News Reader

Comment by a_humean | Hacker News Reader

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.

View on HN

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".

No good deed goes unpunished. :(

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.

>"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.

https://xkcd.com/1172/

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.

I would suggest it does the exact opposite. Allowing more safe programs to compile if anything simplifies your mental model.

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.

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.

I understand that. And I still think these changes might be particularly expensive ones.

Trying to keep track of what workarounds you do and do not need to use is hard. Removing workarounds is good, but still an expensive step. Applying a large set of rules can be quite easy after an adaptation period, but changing those rules remains hard. Even if the new rules are simpler.

I'm not saying Rust shouldn't be making these changes. I'm just saying I think this might be part of the reason why you hear comments about how hard it is to keep up with Rust.

> 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

Why?

If you simply do NOT update your model won't that work just fine? You would continue to avoid certain constructs that used to bother the borrow checker; your code would work fine, and the compiler wouldn't complain exactly as it used to.

I agree you don't strictly need to update your mental model, but that doesn't make the update itself less expensive.

I'd guess most people using Rust and checking the changelogs are people who are interested in keeping up with Rust. They are likely to update their mental model because they wish to.

And as a result, they often have to deal with these 'expensive' updates which makes it feel like it is difficult to keep up with Rust.

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.

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.

> [...]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.

Type inference isn't covered by the stability guarantees either, and breaks occasionally.

The key is that even with places with some wiggle room, like type inference, we take care to try and break as little as possible, sometimes not accepting changes we technically are allowed to, sometimes by adding warnings and waiting a long time... that said, you're right that breakage does sometimes happen here, though we work hard to minimize it, and we don't get tons of complaints that this stuff breaks people's code often.

In the places I worked with Rust it's usually excellently understood that upgrading the compiler must be accompanied by a `clippy` session and a careful review of any and all compiler warnings so IMO compiler upgrade is a non-issue even if there are the very occasional breakages (which I never encountered).

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.

And how quickly do compiler/language bugs get fixed...

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

Reply on news.ycombinator.com