Hacker News Reader

Comment by Cthulhu_ | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com