How often does Rust change?

I've never understood the need to keep code "up to date" with idioms. Most of the time idioms change incrementally; the seismic shifts I can think of a) have happened pretty much only once in a language's life, and b) were basically an admission that the original language design was bad and/or insufficient in some way.

Whereas to me it seems like Rust's idiom changes have mostly been around using some new language feature to make certain cases a bit cleaner; that's about it. They've all been very cohesive and in line with the overarching philosophy, so I don't really see why the old way would look foreign to new developers.

I tried to get at this with this paragraph:

> This analysis doesn’t get into something that I think is a huge deal: the ecosystem vs the language itself. I only track the Rust distribution itself here, but most Rust programmers use many, many ecosystem libraries. When people talk about churn in Rust, do they really mean the ecosystem, not the language? In some sense, doing so is correct: Rust having a small standard library means that you have to use external packages a lot. If those churn a lot, is it any better than churn in the language itself?

The reason I didn't pursue this more is that this is significantly harder to both quantify and get data for. As I said, it is a very important way to think about this problem though!

Are there any languages that are good at this? I feel like I would not enjoy deeply working with old C++ (e.g. auto_ptr), old Java (e.g., no lambdas), old Python (e.g., string formatting with %), and so forth - if I were making more than maintenance changes I'd modernize the syntax. sh hasn't changed much, but old shell scripts are usually buggy and would benefit from, say, bash arrays and the ability to assume that bash is installed. Old Perl is the most likely to be subject to the "write-only code" epithet, old HTML using tables and images for layout is certainly foreign, and I hear PHP today looks nothing like it looked back in the early '00s.

I think the only languages that don't look foreign are languages that are basically no longer developed because they basically don't have new developers / new projects at all. Fortran is a good example - the language hasn't changed much since 1990, but a new developer wanting to call existing routines in Fortran (like BLAS/LAPACK) would generally use a younger and more featureful language like Python (via NumPy), R, Julia, or even MATLAB. The same class of users who would have directly used Fortran some 20-40 years ago are writing their own code in an entirely different and foreign language today.

Part of the problem is that programming language design is still a very young field. Compare with musical notation, for instance. Music written a hundred years ago is perfectly readable to modern musicians; music written over about five hundred years ago in plainchant notation is learnable (a reader of modern music can pick it up in well under an hour of study, but won't be able to read it cold); music written over about a thousand years ago, is pretty unreadable without training. Meanwhile, programming languages date from the 1950s, and various language features are very new (syntactic async/await first appeared about a decade ago, for instance, and even the Liskov substitution principle is only about 26 years old). There are clear reasons to prefer the incrementally improved notations for both music and software - neither Guido d'Arezzo nor Guido van Rossum got everything right on the first try, even though their original notations are readable to practitioners today - it's just that we've already figured out musical notation we're happy with and there haven't been significant incremental improvements in music hundreds of years.

Yeah but that mostly hasn't really happened either. I've been using Rust since just before 1.0. In the first year, there was churn constantly - it used to be that, for a good experience with json, you needed nightly. It was insane.

A few key features landed and things more or less stabilized in the language - I don't recall anything super meaningful where I was like "ah nice, time to update my code". We got some helpers like `impl Trait`, but there was 0 reason to go back into most codebases to use it.

More recently the major change was with async/await. At this point, sure, you may want to go back to old code using old futures and update? So that's one major change in my entire time using Rust where I'd say "yeah, go back, bring stuff up to speed if you can".

I guess there's the new anonymous lifetime stuff, which I don't really think was that important to add tbh.

Most churn is in libraries, unsurprisingly. Tokio only just hit 1.0, but that does mean that from here on out we can expect much less churn there.

idk otherwise, nothing sticks out to me as a major idiom change. I don't think Rust code 2-3 years ago will be particularly foreign at all, again with the exception for when people used to use 'raw' Futures.

I believe 100% of Rust code written since 1.0 should still work today.

In languages with static analysis, there is often a false tradeoff between long-lived code and security.

For Python (and JavaScript and most modern languages), security updates are mixed up with API changes. In some cases, security updates require breaking old code.

If the language has great static analysis, you get a handy guide of everywhere your code needs to change. For example, I have a C# code base that's now 5 years old and has survived through several major C# and .NET updates, and it was never more than 2-3 hours of work to just click and fix the compiler errors (JetBrains automates a lot of it, too).

Rust sounds like it has that benefit as well. The compiler is so good that broken code is easy to find and fix.

As someone who's last gig was working on a 10-15 year old Python hell-base, I sure do wish half of the code died every few "weeks or months".

> In c, with no dependencies, and -Werror disabled, it is likely decades.

How might C code like this eventually fail, assuming future C standards remain backwards-compatible? Perhaps because C code is likely to contain (currently benign) undefined behaviour, which future compilers may take advantage of?

Hasn't really changed much since though I think.

This could very easily suffer from gaming, and it’s unclear how many people would even bother to participate.

I’m not sure, but probably?

*Laughs in ANSI Common Lisp*

I believe these types of comment memes are rare on HN because they obscure what might be an interesting point with an unoriginal, unfunny joke. I understand what it means because I've seen it on reddit, but a lot of people here don't use reddit.

I hope that you'll consider just writing out your point in plain language in the future, especially for people are not "in on" the joke or don't speak English as a first language.