Hacker News Reader

Comment by huntie | Hacker News Reader

I agree that most crates will upgrade, but there are some very prominent crates which maintain compatibility with old rust versions. An example is the regex crate which works on rust 1.20+.

View on HN

To be clear, rust 2015 code compiles just fine on new compilers, and will indefinitely. That’s a key part of it! Nothing should change with regards to these crates; they already weren’t using new features anyway, in order to maintain that compatibility.

Sure, I understand that. But if I've only ever used Rust 2018 and I go to submit a PR to the regex crate, I now need to be aware of any differences between the two versions.

It might not be a big deal, but a few weeks ago I started a new project that was going to reuse code from an existing project. The new project defaulted to 2018 (nightly compiler) and I got a bunch of errors with my module imports. It was just frustrating because it felt like it was a breaking change and one of the reasons I started using Rust is the promise of no breaking changes.

That’s fair!

These kinds of changes are generally on par with other “never break” languages like Java and C++. Java 1.4 feels very different than Java 10.

It’s tough!

Is this not the situation when any new feature is added to a language?

If you want to use Rust 2015, just do so?

I fail to see how Rust editions could be much smoother managed. Or should they never fix anything in the language?

Reply on news.ycombinator.com