If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing. At the end of the day, it's what the software does that's important.

> If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing

That's not a responsible metric. 30 year old software was written against 30 year old APIs vulnerable to known attack vectors, and with 30 year old notions about security. The belief that this software is suitable for modern use is absurd IMO.

And if the types of programs you're talking about are small UNIX-like utilities, well then they're small and easily updated aren't they?

More often than not, brand-spanking-new software is written against 30-year-old APIs.

Lots of software we use day-to-day is old. For example, a couple years ago I fixed a 20-year-old bug in netcat, which itself hadn't been updated since the mid 90s. After I fixed the bug, I didn't need to fish out an old compiler or any compatibility libraries; I just compiled it with the latest GCC and glibc, and carried on with my day.

Don't get me wrong, I like Rust a lot and I'm excited that there's finally a real contender for the systems programming throne after all these years. I'm just less enthused about the prospect of refactoring my codebase once every few months to stay current. This is something that I think will level out with time, though. C itself was almost 20 years old before it was standardized, after all. I don't think it will take Rust that long, and I look forward to the day my copy of the Rust standard arrives on my doorstep.

> More often than not, brand-spanking-new software is written against 30-year-old APIs.

Let's assume this is true, brand-spanking new software will be written against 30 year old APIs that have survived 30 years of attacks and audits, but will avoid the ones that have proven vulnerable.

> I'm just less enthused about the prospect of refactoring my codebase once every few months to stay current.

The perception that you need to do this is false. You might feel pressured to refactor simply because of new syntactic improvements that make code clearer (like switching try!() macro to infix ?), but that pressure is a fiction. There's no real need to do it.

> After I fixed the bug, I didn't need to fish out an old compiler or any compatibility libraries; I just compiled it with the latest GCC and glibc, and carried on with my day.

Could you show me an example where post-1.0 you wouldn't be able to do this with Rust?

If the software does what you want includes all of those criteria. If you find that there are deficiencies in any of those areas, that would qualify as a reason to make changes, weighed against the cost of doing so.

> If the software does what you want includes all of those criteria.

Except most people don't consider those as criteria at all. The only criteria considered are "does it run and produce the output I want".

And the plan is that you'll be able to do the same with Rust; the more rapid release strategy doesn't affect that at all.

What the rapid releases do affect is the rate at which new releases of libraries stop working on older compilers, which absolutely has to do with ignoring progress.