7 ms·

How often does Rust change?

44 points by sdht0 6y ago

staktrace 6y ago
Note: this is from April 2020.
- gpm 6y ago
  Hasn't really changed much since though I think.
  - steveklabnik 6y ago
    Can’t really tell, I don’t know of anyone who has done the analysis since then. One thing that’s changed is I no longer write the release blog posts. (This author inconsistency is mentioned in the post)
neolog 6y ago
This essay is taking the language author's perspective, but IMO the user's perspective is different and more important. I think what people mean when they say the language changed isn't literally "the language changed". It's actually what the user is supposed to do changed: The idioms changed. The ecosystem changed. Code that I wrote two years ago still works but it looks foreign to new developers.
- brundolf 6y ago
  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.
  - lmkg 6y ago
    I think it matters more for reading and collaborating than for writing. If you don't keep up to date with idioms, and your "fluent dialect" is three years out of date, this won't impact your ability to write your own code. But it might pose a barrier if you try to read someone's blog post, or use APIs from recent libraries, or contribute to a newer project. Rust has the obvious seismic shifts like async, which are rare. But the community has a decent amount of "best practice churn" in some areas, like error handling, or async frameworks.
  - neolog 6y ago
    > I've never understood the need to keep code "up to date" with idioms. It helps with readability to have everything using the same idioms, and it helps with quality to have everything using the best idioms. > Most of the time idioms change incrementally Incremental changes stack up over time. > the seismic shifts I can think of a) have happened pretty much only once in a language's life, big changes happen much more often in new ecosystems > and b) were basically an admission that the original language design was bad and/or insufficient in some way. Yeah. If I'm considering whether to join a language, I want to know if they have so many unresolved problems that they're still fixing them all the time. Slowness is related to maturity.
- steveklabnik 6y ago
  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!
  - neolog 6y ago
    Packages are part of it. But also even if the packages don't change, the preferred idioms can change as the community figures stuff out.
    - steveklabnik 6y ago
      Yeah, it's all sort of the same genre of "stuff that's not, strictly speaking, the language."
- geofft 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - nyanpasu64 6y ago
    I haven't dealt with tables a lot, but I've seen a lot of sites based on absolute positioning and floats, rather than flexbox and grid. And there's been an explosion of modern (computer-based) musical notations recently... piano roll editors, MML, trackers, possibly 16-step sequencers as well...
- staticassertion 6y ago
  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.
hedora 6y ago
The main question for me is what the half life is for code I write. In c, with no dependencies, and -Werror disabled, it is likely decades. In python with lots of dependencies, it is probably weeks or months. Where does rust with lots of dependencies (since that seems to be what cargo encourages) sit on the spectrum?
- gameswithgo 6y ago
  I believe 100% of Rust code written since 1.0 should still work today.
  - steveklabnik 6y ago
    We have fixed some soundness holes that means some broken code accepted by older compilers will not compile today. There also have been some type inference changes that technically could break some code. While we are allowed to break things in this way, we want it to feel as if it were literally 100%, so we often will do things like “warn instead of fail to compile for a very long time” before making changes, or “discover that an inference change breaks the ecosystem too much so back it out until it won’t anymore.”
    - glandium 6y ago
      There's also a category of breakages that happen when libstd adds methods to types or traits. You get a unstable-name-collision warning for a while and then your code breaks. I'm not looking forward for code using Itertools::intersperse to break.
  - Waterluvian 6y ago
    I think this is true for Javascript and as a result old code still runs. I think that's great. But there's also an absolute minefield of bad features that don't get deprecated. Not that that's not addressable with tooling or feature limiting version flags.
    - smt88 6y ago
krono 6y ago
* Cries in Java - nay - ECMAScript version ES.Next Draft ECMA-262 *
- jhgb 6y ago
  *Laughs in ANSI Common Lisp*
  - crispyalmond 6y ago
    As much as I wish for another standard, I doubt we'll ever get one.
  - aidenn0 6y ago
    Common lisp does change though. Package local nicknames and named readtables being the two obvious language level changes.
- smt88 6y ago
  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.
  - krono 6y ago
    Sorry to hear that the joke wasn't well received. Your "get off my lawn you dirty Redditor" attack is not at all appreciated, and more harmful to this community than the odd sprinkle of this sort of clearly highly technical and in-depth humour. In hindsight I do agree that some more details could have been included for our friends who just need a little bit more context to connect the dots. Something I will keep in mind when possibly posting more content in the future. With English actually being only a tertiary language for me, it is actually sometimes difficult to convey the right tone in written text. Perhaps you could be a bit more considerate and less quick to assume in that regard.
Fiahil 6y ago
I think the best way to assess if the language has changed a lot, is to crowdsource changelog ratings from users directly. They (we?) are the most concerned about changes, and the best suited to tell if async/await is a bigger feature than const fns.
- steveklabnik 6y ago
  This could very easily suffer from gaming, and it’s unclear how many people would even bother to participate.
_wldu 6y ago
If my source code still builds, does change matter? In my personal opinion, it does not. However, if I have to change my source code when a new release comes out, then it's an issue.
ComputerGuru 6y ago
This needs a 2020 in the headline. Previously discussed at length.
geofft 6y ago
'steveklabnik - do you have the raw data still? I don't think I see it linked in the post, and it'd be interesting both for seeing what the major features are and for keeping the log up to date.
- steveklabnik 6y ago
  I’m not sure, but probably?

44 points by sdht0 6y ago

staktrace 6y ago

Note: this is from April 2020.

gpm 6y ago
Hasn't really changed much since though I think.
- steveklabnik 6y ago
  Can’t really tell, I don’t know of anyone who has done the analysis since then. One thing that’s changed is I no longer write the release blog posts. (This author inconsistency is mentioned in the post)

neolog 6y ago

This essay is taking the language author's perspective, but IMO the user's perspective is different and more important. I think what people mean when they say the language changed isn't literally "the language changed". It's actually what the user is supposed to do changed: The idioms changed. The ecosystem changed. Code that I wrote two years ago still works but it looks foreign to new developers.

brundolf 6y ago
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.
- lmkg 6y ago
  I think it matters more for reading and collaborating than for writing. If you don't keep up to date with idioms, and your "fluent dialect" is three years out of date, this won't impact your ability to write your own code. But it might pose a barrier if you try to read someone's blog post, or use APIs from recent libraries, or contribute to a newer project. Rust has the obvious seismic shifts like async, which are rare. But the community has a decent amount of "best practice churn" in some areas, like error handling, or async frameworks.
- neolog 6y ago
  > I've never understood the need to keep code "up to date" with idioms. It helps with readability to have everything using the same idioms, and it helps with quality to have everything using the best idioms. > Most of the time idioms change incrementally Incremental changes stack up over time. > the seismic shifts I can think of a) have happened pretty much only once in a language's life, big changes happen much more often in new ecosystems > and b) were basically an admission that the original language design was bad and/or insufficient in some way. Yeah. If I'm considering whether to join a language, I want to know if they have so many unresolved problems that they're still fixing them all the time. Slowness is related to maturity.
steveklabnik 6y ago
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!
- neolog 6y ago
  Packages are part of it. But also even if the packages don't change, the preferred idioms can change as the community figures stuff out.
  - steveklabnik 6y ago
    Yeah, it's all sort of the same genre of "stuff that's not, strictly speaking, the language."
geofft 6y ago
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.
- deleted 6y ago
  [deleted]
- nyanpasu64 6y ago
  I haven't dealt with tables a lot, but I've seen a lot of sites based on absolute positioning and floats, rather than flexbox and grid. And there's been an explosion of modern (computer-based) musical notations recently... piano roll editors, MML, trackers, possibly 16-step sequencers as well...
staticassertion 6y ago
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.

hedora 6y ago

The main question for me is what the half life is for code I write. In c, with no dependencies, and -Werror disabled, it is likely decades. In python with lots of dependencies, it is probably weeks or months. Where does rust with lots of dependencies (since that seems to be what cargo encourages) sit on the spectrum?

gameswithgo 6y ago
I believe 100% of Rust code written since 1.0 should still work today.
- steveklabnik 6y ago
  We have fixed some soundness holes that means some broken code accepted by older compilers will not compile today. There also have been some type inference changes that technically could break some code. While we are allowed to break things in this way, we want it to feel as if it were literally 100%, so we often will do things like “warn instead of fail to compile for a very long time” before making changes, or “discover that an inference change breaks the ecosystem too much so back it out until it won’t anymore.”
  - glandium 6y ago
    There's also a category of breakages that happen when libstd adds methods to types or traits. You get a unstable-name-collision warning for a while and then your code breaks. I'm not looking forward for code using Itertools::intersperse to break.
- Waterluvian 6y ago
  I think this is true for Javascript and as a result old code still runs. I think that's great. But there's also an absolute minefield of bad features that don't get deprecated. Not that that's not addressable with tooling or feature limiting version flags.
  - smt88 6y ago

krono 6y ago

* Cries in Java - nay - ECMAScript version ES.Next Draft ECMA-262 *

jhgb 6y ago
*Laughs in ANSI Common Lisp*
- crispyalmond 6y ago
  As much as I wish for another standard, I doubt we'll ever get one.
- aidenn0 6y ago
  Common lisp does change though. Package local nicknames and named readtables being the two obvious language level changes.
smt88 6y ago
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.
- krono 6y ago
  Sorry to hear that the joke wasn't well received. Your "get off my lawn you dirty Redditor" attack is not at all appreciated, and more harmful to this community than the odd sprinkle of this sort of clearly highly technical and in-depth humour. In hindsight I do agree that some more details could have been included for our friends who just need a little bit more context to connect the dots. Something I will keep in mind when possibly posting more content in the future. With English actually being only a tertiary language for me, it is actually sometimes difficult to convey the right tone in written text. Perhaps you could be a bit more considerate and less quick to assume in that regard.

Fiahil 6y ago

I think the best way to assess if the language has changed a lot, is to crowdsource changelog ratings from users directly. They (we?) are the most concerned about changes, and the best suited to tell if async/await is a bigger feature than const fns.

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

_wldu 6y ago

If my source code still builds, does change matter? In my personal opinion, it does not. However, if I have to change my source code when a new release comes out, then it's an issue.

ComputerGuru 6y ago

This needs a 2020 in the headline. Previously discussed at length.

geofft 6y ago

'steveklabnik - do you have the raw data still? I don't think I see it linked in the post, and it'd be interesting both for seeing what the major features are and for keeping the log up to date.

steveklabnik 6y ago
I’m not sure, but probably?