
How often does Rust change? - steveklabnik
https://words.steveklabnik.com/how-often-does-rust-change
======
wffurr
It seems weird to think that Rust is changing too much. It's a young language
and has a lot of catching up to do to cover all the use cases it's intended
for and bring in all the niceties we expect out of modern multi-paradigm
programming languages: procedural, functional, and object-oriented techniques.

C++ is from 1985 and standardized in 1998, and it's still changing at a fast
clip: C++11, C++17, Concepts will be a big deal when they happen in C++2?.

Rust wasn't announced until 2010 and didn't ship 1.0 until 2015. It's only had
5 years to bake since 1.0, vs the 22 for C++.

~~~
mdasen
That's certainly reasonable, but I think it seems harder to keep up with when
people compare it to languages like Go (first appeared November 2009) and
Kotlin (first appeared July 2011). Those languages both seem really easy to
keep up with by comparison. Of course, both of those languages are going along
much more well trodden paths.

I think the "Rust is changing too much" feeling comes from people _really_
wanting to use Rust because it has a cool new way of managing memory and zero-
cost abstractions, but also feeling like it just keeps moving a little too
much on them. Languages like Go and Kotlin just aren't moving much on them.

I think that another part of that feeling comes from the fact that Rust has
two different pieces: a) the new way of dealing with memory and abstraction;
and b) the syntax, sugar, etc. If you're looking for "a", Rust is the only
game in town there. You can't just decide that you need the memory lifetimes
and zero-cost abstractions, but don't want to deal with the rest of Rust's
evolution.

This might be easier to illustrate by contrast. If I want a statically-typed,
garbage-collected language, I can choose Java, Kotlin, C#, Scala, Go,
TypeScript, etc. I feel like I have a lot of choice. If I want a dynamic
language, I can go with Python, Ruby, JS, PHP, etc. If I want a language that
doesn't need GC while not having memory leaks...I'm left with Rust. I can't
decide that I don't like the other parts of Rust or don't want to deal with
Rust's evolution. If Kotlin were evolving quickly and breaking lots of things,
I could just say "Kotlin is dumb and I'll just use Java or Scala or C# or Go".
I can't say "Rust is dumb and I'll use..."

When there aren't easy replacements, you're wedded to the decisions of the
community. The easier the replacements, the less loud your complaints will be
about a language. I think that Kotlin was pretty great for Java because it was
highly compatible with Java and gave Java breathing room to figure out how it
would evolve Java. Kotlin gave frustrated people a path; it gave Java
breathing room to figure out its evolution; and it gave Java the opportunity
to look at what worked well in Kotlin and figure out how it could apply that
in Java.

When we look at Go, there are often complaints because Go offers things
unavailable elsewhere: fast compile times and to a certain extent its
concurrency support. So if you really want fast compile times, you don't have
an alternative.

Rust is probably changing more than languages like Go and Kotlin which are
similar aged. There's a good reason for that: Rust's brief is a lot more novel
and expansive than those two languages. However, if you're sold on Rust's
memory management and zero-cost abstractions, it might be annoying that it
feels like more of a moving target than a language like Go or Kotlin - and you
have no alternative to fill that void.

~~~
RMPR
> If I want a language that doesn't need GC while not having memory
> leaks...I'm left with Rust.

I never used those languages, in fact I discovered them on previous HN posts,
but it seems to me that in this category you can also have Nim and Zig, no?

~~~
wffurr
Those are considered niche compared to Rust or C++. Rust has a large ecosystem
around it and at least one large sponsor (Mozilla) and used in production by
others like Cloudflare, Yelp, and npm.

I think Nim and Zig are both quite interesting and potentially very
productive, but they have a long way to catch up to Rust in terms of community
support.

~~~
master_korin
Not being corporate-driven is a feature, not a bug.

~~~
wffurr
Corporate sponsorship is just an example of the level of support that exists
for Rust. And it's Mozilla I'm talking about here, not your typical
corporation.

Certainly other languages were able to become widespread with large
communities and library ecosystems without being directly sponsored by a
corporation, such as Python or Ruby. I tend to think of those as associated
with an individual, Guido or Yukihiro, though I know in Guido van Rossum's
case he's worked for Google and Dropbox, though that was after Python was in
wide use at those companies.

Whereas with Rust I think "Mozilla" not "Steve Klabnik", because it was
corporate-sponsored from the beginning and worked on by a team.

And if you want your favorite language to grow into its potential, you need
funding, and corporations have a lot of funding to put into things like
potentially productive new languages.

------
tayo42
Some thoughts on my short experience with rust for anyone that cares. Probably
a yearish ago?(Futures weren't solid yet) I didn't read the original blog
post, just the head line and skimmed comments. Though i read this one

I think this post alludes to my issue, the language it self i don't think
changes at an unreasonable rate, the ecosystem felt like a problem. There's so
much changing, what's the "right" way, the right library, expected syntax
seemed overwhelming. maybe this doesn't change a lot, but it is compounded by
the new user experience. Other things are out dated resources around the
internet. The other thing I think that makes this seem worse is I think the a
lot of the community is online and hobbyist work, and the speed communities
change on line is just fast, information moves fast, blink and you'll miss
something.

I do remember feeling excited about rust, but it felt like there was always
something new learn, something around the corner, something better coming then
a new feature would come out, i gotta learn that, what is going on in nightly.
Supposedly editions fixed that, but even that I gotta go figure out what an
edition is and what its implications are.

I haven't gone back to rust, at this point I feel like i need to relearn it to
write anything worthwhile. Just basic stuff like how projects are laid out. I
have a commit in the rust compiler, but i cant tell you the right way to
organize a new project because at some point it changed. To much to keep in my
head.

~~~
iknowstuff
You are absolutely right, futures were infamous for having a lot of churn and
being really difficult to work with. Rust was very speedy but unergonomic for
web stuff. This is why the past year was spent on async/await which
dramatically changed it all and now writing web servers is really simple:

[https://github.com/seanmonstar/warp](https://github.com/seanmonstar/warp)

------
chungy
For those that assert Rust changes too much, I would submit the simple
question "Why?" to them. "Too much" seems to imply that the language breaks
their code too often to make it worthwhile writing software, though this has
been a thing Rust explicitly avoids since 1.0 happened. Rust 2018 took some
liberties at breaking old code, but it only really matters if you explicitly
upgrade to 2018, at which point you've already committed yourself to making
potentially-significant changes. I imagine a future "big change" like Rust
2021 or whatever would do the same; I likewise hope that all N editions can
interoperate no matter how many N editions exist.

> However, maybe there’s a better way to surface “these are big changes” vs
> “this is a small thing,” or something like that. I’m not sure.

It might be as hard, or even harder, to quantify this than even deciding what
gets put into the release notes. What might be a big change for one person is
absolutely insignificant for another, and vice-versa.

~~~
rrobukef
I gave up during the switch to the 2018 edition. Today, I still write 2015
code because I couldn't bother to decipher how paths and `extern crate` had
changed. The documentation on the differences was too sparse to relearn it
(maybe there was enough documentation to start for scratch, I don't know). It
was also a busy time with NLL (those changes were simple).

Since then the 2015 edition hasn't stopped either: warnings popped up to use
`dyn`, warnings that deprecated `std` functions, new feature gates added and
old feature gates were removed. Libraries weren't spared: The minor releases
of `rand` are so incompatible that they needs upgrade guides themselves.

For 2018 I may learn it 'sometime', every change further delays. There's
Futures, there's async now. I don't have time to decipher the types since I
don't need it. However there was and is so much discussion that I'm already
tired.

~~~
Ar-Curunir
> new feature gates added and old feature gates were removed

This is only a problem on nightly, which is a toolchain which explicitly makes
no stability guarantees and is intended for experimentation?

> For 2018 I may learn it 'sometime', every change further delays. There's
> Futures, there's async now.

You don't have to interact with things that you don't use, though. For example
I've been on Rust 2018 since day one, and I still haven't needed to learn
about futures.

~~~
worik
Reading code matters too. Languages are not just written

~~~
jjnoakes
Sure, but when reading code you didn't write, you have a whole list of things
you need to spend extra time on - the style, the way functions are broken up,
how data types are organized... if you come across one or two new language
features in use as well, stopping to learn enough about them to reason about
the code is not a big deal (to me at least).

------
as-j
This is amazing, and great. "Does a language change too much" is very much use
dependent, and it's great to have the data.

For me, an embedded systems developer, this is an order of magnitude too much.
Rust is so appealing for my use case in many ways, but I need an environment
that a team can easily work in for years. My current code base is 10 years
old. Our base system dates from 2017, and it took until 2018 for us to update
to that. We were going to do a late 2019 base update, but sadly the project
was delayed for other reasons. Our application side updates monthly, a much
smaller OTA DFU. (over the air device firmware update)

You can compare it Lua:

[https://www.lua.org/versions.html](https://www.lua.org/versions.html)

The community is much smaller but it's interesting to see even at it's
comparatively glacial release schedule there's a large split between 5.1/5.3.

Why do a rapidly evolving language, stdlib, etc matter?

1\. We're going to be year(s) behind. I need everyone to learn and be
proficient at the languages we use. They need good consistent doc and manual
for our version. And not complain that we're on 1.31.0 but this great feature
is in 1.33.1.

2\. Moving base languages is support, not direct project improvement. While we
standstill moving the base system/language/tooling forward our customer
releases a new feature.

3\. People are always going to google "how to do silly thing" and get code
snippets. Heck I do this all the time with Python. =) It's really nice for
this be somewhat consistent/right.

Sigh, as an embedded dev I'm so torn on Rust.

~~~
steveklabnik
Have you heard of the Sealed Rust work?

~~~
as-j
Nope?

This?

[https://ferrous-systems.com/blog/2019-06-05-sealed-rust-
the-...](https://ferrous-systems.com/blog/2019-06-05-sealed-rust-the-
pitch.html)

Do you have a short version recap in 1 or 2 sentences? Plus any
liensing/costs/etc/etc?

~~~
steveklabnik
Yep!

The short recap is: some folks are trying to get a subset of the language
certified. They run an entire consultancy that does a lot of embedded Rust
work. I am hoping that this will help to alleviate the issues you're talking
about; we'll see how it goes!

~~~
as-j
That's awesome thanks! I look forward to it.

------
BiteCode_dev
I hear exactly the same about Python.

Some complains it's moving too fast.

Some that's it's an old language that's stuck in the past.

The balance between stability and keeping up with modernity is hard to reach,
and people will never be happy.

~~~
mplanchard
Comparison with python actually helps to put Rust in a positive light.
Compared to the Python 2/3 debacle, Rust managed to introduce a major new
version with lots of new language features (edition) while making it: a)
entirely opt-in, b) easy to update to with automated tooling, and c)
compatible with previous versions.

Compare this to Python 3, which cannot load Python 2 libraries, cannot be
converted automatically, and is now effectively required with the sunsetting
of Python 2 in January of this year. Python has a lot of strengths, and I
think 3 is way better than 2, but the transition was very painful.

Meanwhile, I have a crate I wrote a while back for 2015 nightly, and it took
me less than an hour to get it up and running for 2018 stable. But I didn’t
have to! Everyone using 2018 (nightly) could still use the crate even if I
hadn’t converted it.

------
rattray
Subject matter aside, it's always wonderful to see thought leaders analyze
their prior public claims and reach a conclusion that their hypothesis was
wrong. Hats off.

------
infogulch
Something that Steve touched on but didn't dive into is that there's a
difference between measuring facts, like the number of changes in a period of
time, and measuring the cognitive impact of those changes. I'm sorry in
advance for how rambly this post is.

`const fn` is a nice example, because it's a large number, but the cognitive
impact could be neatly summarized for the general rust userbase by "neat, but
I don't really care". The cognitive impact is directly proportional to how
easily we can abstract the changes into a coherent story. Does it matter that
there were exactly 138 "this fn is now const" changes in 1.33? No, because you
already forgot that there were actually only 125. What's the actual difference
between 13 extra `const fn` changes and a list of 13 other completely
independent changes? 13 arbitrary library changes sound like a lot when
they're not neatly bounded by a pre-existing frame of reference. In this case,
"this fn is now const" * X where X is 'a big number' doesn't change in
cognitive impact when X is replaced with X * 1.1.

I think that Kubernetes release notes are another interesting example. There's
typically a huge number of changes due to the distributed nature of the
project's development. The vast vast majority of the changes would have little
to no effect on _your_ k8s deployment, but there may be _some_ nugget in there
that does have a big impact on you. The problem is that that nugget is
different for everyone.

So it seems like the key to communicating change may be to present the change
_in conjunction with_ a carefully selected frame of reference that enables the
audience to easily conceptualize the bounds of the effects of the change in
relation to their own experience, before being inundated with the details of
the change that would only be useful to people occupying a different frame of
reference. The problem is that everyone's experience is different and the
impact a change will have will greatly depend on who's reading.

Maybe release posts need old school newspaper-like front pages where changes
are scoped and summarized, and details are hidden unless the user wants more.
Or maybe there should be multiple posts from the perspective of different user
personas. But these ideas aren't cheap to implement, and the problem seems to
approach something like "the fundamental difficulty of communication" which is
way beyond my scope of understanding.

~~~
Rusky
> The cognitive impact is directly proportional to how easily we can abstract
> the changes into a coherent story.

Exactly! This is how language and API changes are usually _designed_ , and
announcing them the same way is a great idea.

------
uluyol
> ... but soundness fixes happened so little it wasn’t worth talking about.
> There were 7 in those 42 releases.

Are there any similar statistics for other languages? To me this seems high.
It's not common that a program that compiles in other languages becomes
illegal in a later release.

I mean I understand why the Rust developers make this choice—the language aims
to provide strong static guarantees, but I hope they appreciate that users
don't like when their programs break after a compiler upgrade.

~~~
steveklabnik
Some of them didn't break any more, they were always broken. Or, some of them
were purely additive. We added mitigations against
[https://blog.qualys.com/securitylabs/2017/06/19/the-stack-
cl...](https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash), that
was categorized as one.

------
ComputerGuru
I’m happy with the changes to rust and their pacing but I want to point out
that merely asserting “you don’t have to use these features if you don’t want
to” is disingenuous and particularly so for open source contributors (Steve
did NOT say this but it was a common refrain in the discussion that Steve is
contributing to). It threw me for a loop the first time that I saw the spread
operator in an assignment in a project I was filing a PR for, and I thought I
was on top of all the features.

Some changes that stand out to me: the try macro being deprecated was huge,
and though the ? Operator is a thousand times nicer, that was a rather radical
shift to the ecosystem where you could smell code from yesterday a mile way; I
seem to remember try blocks were stabilized then removed but I seem to be
mistaken on that count; async of course is a huge change and it absolutely
does force you to use it since it’s a contagious language feature in pretty
much all languages (I’m very disappointed with tokio on this count and have a
feature I’ll probably file a PR for to help reduce this); the change allowing
reusing the same variable name inside a match binding as the variable being
assigned to was hugely beneficial but quickly broke backwards compatibility
because of how nice it was to give up. I think the changes to std::error are
also worth mentioning, they might be backwards compatible but they completely
obviated an entire generation of crates and coding styles (I for one do not
lament the death of quick error and co).

I feel a better metric for this might be to study the min rustc version to
compile libraries, i.e. community adoption of new or breaking changes. If you
take the releases from the top 250 crates in the past few years and see how
many rustc versions back from whatever was stable at the time of release could
compiled the release, that might give you a more data-oriented result.

Also, I think some of the real frustration might be from “core” crate
breakage, such as the transition from tokio 0.1 to 0.3 and the ensuing mess or
examples like gfx-rs that hundreds of other popular crates built on to get
OpenGL support before they completely deprecated it and pivoted altogether
such that not all are those crates left based on a dead-ended project but
OpenGL users are all SOL (“just a little while longer!”) as the community-
adopted alternative is wgpu which requires Vulcan/Metal/DirectX until the
promised OpenGL support lands there.

I’m not complaining; NIH people generally get off easy with community
deprecation of popular crates ;) and OSS developers are absolutely not
beholden to anyone. But I imagine for developers plugged into the ecosystem,
changes to extremely popular crates and changes to the language or standard
library might result in a general annoyance that doesn’t distinguish between
the two (and that’s also fair since the reason rust has a small standard
library is so people use crates which can be more easily replaced or
deprecated).

~~~
baby
That something pro-generic people in Golang tend to miss: once you enable a
feature it means everyone is going to try to use it. And this has
consequences. And people should ponder more often on why Golang is so clean to
read.

~~~
hyperman1
Beware. Exactly the same thing is true for COBOL: Easy to read, very low
abstraction, but you need tons of repetitive code for anything. A language
that is too simple brings its own trouble.

~~~
baby
sure, but Golang seems well accepted and widely used in a multitude of
different tasks, so it seems to have found the right balance I would say.

~~~
hyperman1
That is unfortunately exactly as true for Cobol as for Golang.

~~~
baby
Who uses cobol?

------
znpy
Meh. When considering a language for a project one should also consider its
maturity.

Stuff like C/C++ basically won't ever change*. Code that you write today will
probably compile in ten years. If you're writing in C++17, there will probably
be a C++17-mode in 2030, as there are C-99 and C-89 modes today.

Otherwise, if you want the newest shiny language, you shouldn't complain when
it changes.

But it's nothing new really: there's no free lunch.

~~~
bluejekyll
Rust has made, and so far kept, this same promise.

But also you’re wrong about C/C++, new versions of those compilers often
uncover dormant undefined behavior when the compiler slightly changes behavior
in certain areas.

~~~
adev_
That's two different things.

If your program does not compile anymore because it was relying on undefined
behaviour, it was wrong from the beginning and deserved it.

It is completely different of old sane codebase not compiling anymore due to
syntactic sugar change in the language.

~~~
dralley
>> It is completely different of old sane codebase not compiling anymore due
to syntactic sugar change in the language.

That is not very common with Rust.

If you just download some project off of Github (or using some dependency)
from 2015, it is very very likely to "just work" even with a new compiler, due
to how editions work.

A more likely way to encounter issues is by pasting some code from
Stackoverflow into a Rust project that is using a different edition. Yes, that
can happen, but it's not anywhere close to as big of a problem.

~~~
shepmaster
And even then, I try to update any SO questions and answers that are still
useful to the latest edition, as it’s more likely someone who doesn’t know
about editions will be playing around with 2018.

~~~
FridgeSeal
I see your work around Stack Overflow a lot and I’d like to thank you for
that: your answers and contributions have helped me significantly, multiple
times.

------
ldng
Nobody is "in the thick" as Rust core dev or aficionados are.

There is a reason commercially backed language have a mush slower release pace
and big release. It is easier to write doc for and prepare _formations_ ,
_classes_ and _certifications_

For better or worse, in corporate/industrial landscape those are kings. If
Rust does not understand that it might stay in the hobbyist category.

With Javascript being the exception. Unless I am completely wrong and it is
the new norm.

~~~
ethelward
> With Javascript being the exception

And Python. And Ruby. And C++. And Kotlin. And Swift.

------
einpoklum
Answer:

1\. Quite often.

2\. With some breakage of existing programs.

... and this is a fundamental paradigm difference between Rust and C++, for
which the answers are:

1\. Every 3 years.

2\. Changes are backwards-compatible [1]

\-----

[1] There are slight specific manageable caveats. Example: The repurposing of
the `auto` keyword.

~~~
namibj
Stable Rust has never broken a crate. If you specify a different edition _for
your own_ crate, you can still use dependencies of both older and newer
versions.

C++ won't let you just (seamlessly) use a C++98 library in a C++20 project, or
vice-versa.

~~~
steveklabnik
> Stable Rust has never broken a crate.

This is too strong. We _have_ made some soundness fixes that have broken
crates. (We spread the change out with warnings for a long time before
actually breaking) We _have_ changed type inference in ways that one or two
crates needed to add an annotation.

The vast majority of the time this is correct though.

------
jeffrallen
A more relevant experiment would be to take Rust code released 6, 12, 18 and
24 months ago, and try to use it, in particular try to read messages in forums
and stack overflow and try to use/fix that code. You'd find it was impossible,
because Rust changes so fast that nothing written about it survives 6 months
without becoming inaccurate. Which is why I threw up my hands and gave up.

~~~
bluejekyll
I’ve been working with Rust for over five years now. This does not relate to
my experience.

New things come and they make things easier, but anything from 6-24 months
ago, still works in the identical fashion as it did at that point.

