Hacker News Reader

Comment by steveklabnik | Hacker News Reader

Hey folks, this is the first release after I wrote https://words.steveklabnik.com/how-often-does-rust-change. We haven't changed any real policy here, but the bit saying

> This release is fairly minor. There are no new major features. We have some new stabilized APIs, some compiler performance improvements, and a small macro-related feature. See the detailed release notes to learn about other changes not covered by this post.

is an attempt by me to maybe address this. We've historically said similar-ish things, but I'm trying to be a bit more blunt about the magnitude of changes. Any feedback on this would be useful!

View on HN

I think the key thing people worry about with regard to "churn" is "OMG, do I have to update my code again?". Explicitly calling out that this release doesn't really have any changes like that is good. I also think that's why the ecosystem change is in fact a big deal. People seem to feel pressured to keep up. Meanwhile I'm still not really sure what the consensus is, if any, on which error handling library we're supposed to use... Anyway, it might also be worth calling out somewhere that no, you don't have to follow the ecosystem and the hip idioms super closely if you just want to get some work done (and to the extent that's not true, making it so).

Thanks :)

The current error handling consensus seems to be "anyhow for applications, either no crate or thiserror for libraries." Obviously this is not uniform, but the discussion + download counts point to this, imho.

To clarify for others: "anyhow" and "thiserror" are not placeholder names in that sentence. They refer to:

https://github.com/dtolnay/anyhow https://github.com/dtolnay/thiserror

Just to be clear, you never HAVE to update your code. Rust 1.0 code still works just fine.

The consensus with error handling is that the limitations of std error trait have now been sufficiently fixed so as to be usable without anything more. But you can use a crate (like `thiserror`) to reduce boilerplate if you really want to.

> Just to be clear, you never HAVE to update your code. Rust 1.0 code still works just fine.

You have to update your dependencies though because every now and then, changes lead to breaking builds. I have a codebase from 2015, last touched in 2016, and many dependencies failed to compile, some because of changes in the language (those changes are only done to fix bugs but they still cause churn to users), others because the openssl wrapper doesn't support newer natively installed versions of openssl. It took me roughly an hour to fix all the issues and it's only a few hundred lines.

Admittedly this is much much less effort than staying up with whatever the currently hyped error handling library is. And C++ projects often need effort to work on newer compilers as well because they invoke UB and the optimizer changed and led to segfaults. Seen it with my own eyes.

Tbh I found OpenSSL to be its own world of pain. And that was from using it in C. ;)

Most (all?) of this "dang we need to brake something because we made some stupid design mistake wrt. soundness" kind of braking changes should be done by now I think.

So I think that when in 2024 someone build a code base from 2020 this shouldn't be a problem.

Also sadly currently rust has not yet completely escaped from the C/C++ UB optimization hell ;-). There are some bugs caused by the interaction of Rust and LLVM UB optimizations. Like there was a problem with some float casts being UB (but should not have been).

But we are getting there.

>Like there was a problem with some float casts being UB (but should not have been).

And one of those is just about to get fixed, it looks like =]

https://github.com/rust-lang/rust/pull/71269

I've already tested my lewton project with this change, and not the tiniest bit of a slowdown.

For someone new to Rust. What past changes in the language broke the dependencies you used? Were they using the nightly branch?

I ran into two issues, one in rustc-serialize broken by https://github.com/rust-lang/rust/issues/35203 (fixable by cargo update -p rustc-serialize) and one in url broken by the move to NLL on the 2015 edition. The second is an important bugfix in the language, but it still broke my build :). Not sure how I fixed it but it's now fixed as well. Additional changes were required due to openssl.

My own code has compiled just fine except for a ton of warnings (most about try! -> ? change) and the needed API updates of dependencies (2 changed lines).

Most of the effort I spent on actually updating as little as possible. If you update everything you fix all issues resolvable by updates but you also have to adjust to every API change :).

e: this is wrong

Dependencies can set lints to deny. When lints change, they might not compile anymore.

(I think denying lints is a bad idea, just like -Werror)

Doesn't cargo's behavior of capping lints prevent this?

Yes, you're right. I thought I had seen this in dependencies, but I must have been compiling something directly.

Also isn't the point of tools like Rustup is that you don't need to make sure your code is constantly up-to-date with respect to the compiler? Like you can keep using rustc 1.0 on code written for Rust 1.0, right?

Maybe we need another number like 1.42.2? I have no idea if this can be relevant for languages.

We already have minor releases, but they are exclusively for critical bugfixes. Everything else either rides the train (up to 12 weeks) or gets backported to beta (up to 6 weeks before hitting stable).

Thank you. I wonder how long this will hold though? I would not like to see it get to a point where the language is fine but people aren't really sure what else to do and just make changes for the hell of it.

In other words I think there needs to be a long term standardisation plan to keep the language stable, but for now this is a good step.

> I would not like to see it get to a point where the language is fine but people aren't really sure what else to do and just make changes for the hell of it.

We never make changes for the hell of it.

But also, all changes are purely additive at this point. The language is stable. It has been for years.

In that case I think keeping up very small additive changes is good, thanks for clearing up

To expand on Steve's point, code written in 1.0 style should continue to work indefinitely, modulo soundness fixes, lints and plain old bugs.

You should only need to update at your own pace or because your dependencies force you to, and they shouldn't do so often if they care about supporting as many users as possible.

Big changes, like async/await sugar or impl Trait or the ? operator are uncommon and they either make your code that much nicer to read or allow new constructs that were previously impossible.

Reply on news.ycombinator.com