Hacker News Reader

Comment by simonask | Hacker News Reader

> Rust actually causes far more code churn - there's virtually a monthly cycle of some Rust compiler update requiring changes to existing code.

This is really surprising to me. Which changes have you had to deal with here? The only one I can think of is the major Edition 2024 upgrade, which changed the `#[no_mangle]` attribute to `#[unsafe(no_mangle)]`. But the old syntax still compiles just fine with the newest compiler using Edition 2021.

View on HN

I guess it's because we use clippy to lint all the Rust code, combined with always pulling the latest Rust compiler (from Fedora Rawhide). But it's a real thing, there's a lot of churn.

The good thing is clippy / rustc has very good diagnostics and usually tells you "do X to fix this".

I wish OCaml had more helpful error messages like these, right now it feels like I’m on my own solving some of the more inscrutable errors.

I think what clippy needs the most is a way to say, "make all clippy warnings as errors, but only for warnings up to Rust 1.80". And then devs can update that number whenever they want, as opposed to whenever new updates come in.

Or tie it to the current edition, or the current MSRV if defined.

I think it’s pretty unfair to characterize new, helpful lints as “breaking changes”.

There’s plenty of options to not have to deal with that (unless you want to of course).

I am surprised by this too. I wonder what OP is writing in Rust that requires monthly changes?

A recent one I had was needing to include lifetimes to having to atleast specify the anon lifetime with the underscore. I forget what the actual circumstance was.

Reply on news.ycombinator.com