5 ms·
You're getting flak for this, but you have a point. I wouldn't say it changes very fast. If you look at the language features in the past two releases they're
by duckerude 4y ago
You're getting flak for this, but you have a point.
I wouldn't say it changes very fast. If you look at the language features in the past two releases they're all of the form "allow {existing feature} to do {thing you'd expect to be allowed}", and the library additions are minor.
But it changes often, every six weeks, where e.g. Python releases features only once a year. And it's common practice to install new releases as soon as they come out without waiting for distros to pick them up. That means software starts depending on new features in minor frivolous ways that nevertheless break the build for older Rust versions.
I make an effort to have my libraries support older Rust releases, but I have to go out of my way to check for compatibility. Not everybody does that, and it's unrealistic to expect everyone to—but with a different release schedule that would give fewer issues.
- mustache_kimono 4y ago> And it's common practice to install new releases as soon as they come out without waiting for distros to pick them up. That's the problem. It's not the release schedule that's the problem. The answer I've arrived at, right now, is to make the default version of the Ubuntu LTS release immediately prior to the latest, my default. Is that arbitrary? Yes. Might that change if some very cool Rust features are included in 1.64 -- like, if let chains? Yeah. So should the Rust community perhaps develop best practices on MSRV, at the very least notifying if a package deviates from MSRV norms? Maybe. Is this a big problem? Let's be real -- no, not really.
- tialaramex 4y agoWhat you'd expect, and what I think we see, is that over time the new features are less "must have" and so fewer programmers will chase the latest version. There's quite a gap between "Now arrays implement IntoIterator" (about a year ago, you can e.g. write for loops over an array) and "Termination is now stable" (May 2022, you can have custom exit code handling in your program) I'm sure a few people were excited about Termination, but practically everybody uses IntoIterator and arrays. So of course they would want that feature. As a Linux user I remember manually compiling 1.3.x back when odd numbered micro meant "Unstable" because 1.2 didn't have features I really cared about. Today I just run whatever kernel the OS installed. Are there important new Linux features in linux-next? Probably, maybe I will read about them in LWN and look forward to them, I'm definitely not going to bother compiling it by hand for any new feature I can imagine.
- mustache_kimono 4y agoThis also touches on a really important point -- all this takes place in a context. What is the context? One context -- sometimes there are exciting new features! Another context -- this issue is mostly about users who want to build your software from source (this isn't a problem for you, as such), but who don't want to download a new copy of the compiler to do that. Is this a large group of users, if you're not a library? I don't think so.
- bluejekyll 4y agoI have a policy that is to support at most three releases back. Requiring upgrades to support new software is normal. New APIs are released, new features that allow for simpler code or remove unneeded unsafe blocks. These are good things. People don’t need to install the latest software. If they want to install the latest software, then they will need to install the dependencies that support that software. That can be operating system versions, compiler versions, or other library dependencies. I really don’t understand this mentality of wanting to update one piece of software, but also not wanting to update any other software it might depend on.