How often does Rust change? | Hacker News Reader

How often does Rust change?

words.steveklabnik.com

128 pointssteveklabnik113 comments

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++.

Concepts already happened. In C++20 released earlier this year.

> 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?.

C++ pretty much didn't change between 1998 and 2011 though (2003 was mostly a bugfix and compatibility release). And these days it updates every 3 years (you forgot C++14 though it was a very minor release) which is a much slower pace than Rust's 6 weeks cycle.

Major C++ releases and Rust Editions are both on three year cycles.

AFAIK rust editions are not on any schedule currently, there's no guarantee that there'll be a Rust 2021 edition.

Yes. We have not technically committed to a Rust 2021 yet. We are going to decide this year.

I don't think the 6 weeks vs. 3 years tells the full story. C++ collects up a whole truck load of changes and waits up to 3 years then dumps all of them in one go. Whereas Rust releases them individually, waiting up to six weeks after they've done baking in the nightly compiler (though they've likely been in development for years before that).

That's not to say Rust is necessarily slower paced than C++ either, just that a raw number on release dates aren't helpful by themselves.

Yup. If you read the linked article, you’ll notice the release schedule was addressed by the author.

That an article about Rust changes talk about Rust's schedules has nothing to do with comparisons between C++ and Rust.

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.

Rust is a baby, it requires love and care. Go is a bartender, it does what you need it to but with little charm.

I sure wish Go moved faster. Took them long enough to get around to generic data types. There's still an awful lot of programming that's just not possible in the language still.

Perhaps that's by design, but it's frustrating.

> 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?

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.

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

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.

It's similar to Javascript in a way. If I want to code for the web, I can only use JS. Sure, there are extensions like TypeScript, or even other languages that compile to JS like Elm, but most people are gonna use JS.

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.

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

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.

Every edition will interoperate the same as 2015 and 2018 do, this is a hard constraint of editions.

We technically have not yet decided if there will be a Rust 2021. I think there should be, but it should be smaller than 2018.

> this is a hard constraint of editions.

That's pretty awesome! Should I assume this only applies if a "Rust 2.0" never happens, or is there a commitment to 2.0 never being a thing?

At this point, what would a 2.0 be exactly? I guess dropping 2015 as a supported source edition?

We have said there won't be a Rust 2.0. If course, in theory we could change our minds. Can't imagine a current scenario where it makes sense, though.

It would make sense if Rust 2.0 was smaller and less capable.

Every improvement added to rust makes it worse for me

This is where I'm at. There is no need to read every new release notes and change your code every 6 weeks to use all the new features. It's a self-imposed mental overhead, not one which the language forces you to deal with.

There's nothing wrong with simply reading the "edition guide" every couple of years and using the automated tooling to perform 90% of the minor adjustments that you otherwise would have had to perform manually.

"cargo fix --edition-idioms" will perform many such adjustments for you.

https://doc.rust-lang.org/edition-guide/editions/transitioni...

Wow, that's a super cool feature. Didn't know it existed.

The big challenge is in the open source libraries and code samples that most developers rely on every day. If the core syntax of the language changes faster than that corpus is updated it can make it difficult to learn and apply the language.

Yep! I have a line about this in the "future work" section; I think it's a really important question. I have not come up with a methodology to measure it though.

>> but it only really matters if you explicitly upgrade to 2018

This is OK for programmers who already know Rust. But for new programmers coming to the language, it presents a very difficult challenge.

To give one anecdote, I was trying out Rust a few days ago. Just baby steps. I wanted to read a file. But since the try! the macro syntax is changed, almost every example I could find on the Internet was broken. Took me almost an hour to figure out what was going on. (I have programmed professionally for more than 10 years in Java, JS, Objective-C, PHP, Python and Go) Lost the interest to pursue it further.

Another time, I thought I would read some small projects in Rust from Github to improve my understanding of Rust. I wanted to checkout "programs" and not libraries. So I went on exploring Rust projects on Github and tried out 2-3 smallish programs. But because of Rust version incompatibilities, I was not able to get them to build and run. Now I accept, if I had been dogged enough, maybe I could have found out the exact version of Rust required for the programs. But it was too much work for a weekend afternoon where I just wanted to learn something new in 2-3 hours.

Rust community and senior Rust programmers might not accept this, but the Rust ecosystem has instability issues from a NewBie perspective.

Edit: Sorry the problem I was facing about was related to writing a file and "unwrap" and "?" syntax. Not the try! macro syntax. (I think that surfaced some other time.) I just checked my example after posting this comment. But still keeping the comment here as it shows struggle a Rust noob faces while learning the language.

> I wanted to read a file.

It's probably too late to help now but I recommend the official documentation[0] and book[1]. They both have examples.

[0]: https://doc.rust-lang.org/std/fs/struct.File.html

[1]: https://doc.rust-lang.org/stable/book/ch12-02-reading-a-file...

I'm not saying your experience is invalid, but the first 5 google results I get for "read a file Rust" all return working code (I didn't look beyond the first 5).

Stale links is something that plagues pretty much every language though. Hell python2 documentation still tends to be higher ranked in search results and that's a decade out of date. Then for frameworks or somethign like php you might find an answer that "works" but is so unidiotmatic or insecure in "current year" that you're almost better off having it fail.

In this way I'd say rust is far ahead of the pack. If you want to do something in "2 or 3 hours" you can go to the official documentation https://doc.rust-lang.org/book/ and be certain that things are up to date and work. This is also why random things on the internet tend to not be as well maintained, there's no need and that's not where new people are expected to go.

There's only so much a community can do when users like yourself go out of your way to avoid reading any official documentation (and then are left confused).

I think it's unfair you've been downvoted.

That is, I don't dis-believe your experience. It's just so, so so hard to reproduce these things, and it happens to every language to some degree. Measuring that degree is very hard, and also, Google personalizes results, so it's impossible to recreate.

I don't expect you to have this handy, but if you had data, that is, what posts you found, what you searched for, that would be helpful.

Most users do not report this experience, though I'm sure that's survivorship bias.

Thanks for replying Steve. I appreciate all of the work you do make rust accessible to new programmers.

Don't mind the downvotes as I just wrote from vague memory without properly verifying things.

I tried to look through my Google history to see how I landed into that specific problem. But was not able to find out how exactly I landed on that syntax issue about writing files. If it helps here is my chronological Google Search and visit history on that day about how I finally went from "try" macro to understanding how "?" operator is used in Rust.

* Searched for "try macro rust"

* Visited "std::try! - Rust"

* Visited "Learning to 'try!' things in Rust - Jonathan Turner"

* Searched for "rust expected expression, found reserved keyword `try`"

* Visited "Try keyword reservation breaks macro try - The Rust Programming ..."

* Searched for "rust try macro removed"

* Visited "Error Handling - The Rust Programming Language"

* Visited "How to use ? and catch in Rust? - Stack Overflow"

* Searched for "rust optional unwrapping"

* Visited "What is unwrap in Rust, and what is it used for? - Stack Overflow"

* Visited "Killing unwrap() • Dimitri Merejkowsky - dmerej.info"

* Searched for "rust ? operator"

* Visited "The ? operator for easier error handling - The Edition Guide"

Thanks so much! This is helpful.

That is very important. Because, personnally, I never rely on one source of information. Problem is, as illustrated, what a good source beside the official doc ?

Adding insult to injury, not that it is specific to Rust, there are so many bloggers out there that don't put a date and/or give version of the software they're talking about that you just can't know if the info is correct or obsolete.

If I can piggyback on this, as someone who's learning Rust right now:

One of my first trial programs in any language is a tcptraceroute, since it's a good mix of super-beginner tasks and one slightly advanced thing. I hit a problem in Rust right at the beginning: obviously I need to make a socket, but which crate do I use, "socket" or "socket2"? Socket doesn't build anymore, but it's still available as a crate and I have to include it as a dependency and "cargo build" my project to find out that it doesn't work. To make it more frustrating, the only other example of a Rust traceroute that I found uses socket, not socket2, so it doesn't build anymore, either.

I did figure it out, but it felt like an unnecessary speedbump.

Yeah this was my biggest fear with edition changes: You can fix live code, but you can't as easily fix existing programmers' mental models, and you can't update all existing online resources.

OpenGL has this issue and it sucks, and i did bring this up during the edition discussions but it didn't stack up as well against arguments on the other side.

I'm self taught and "google things until it works" is a key aspect of how i learn, and i'm disappointed to see this workflow somewhat broken in Rust. Over time, it will heal (it's much harder to find stuff that uses `try!` now), but it's still annoying.

It changes so fast that once you learn it, and then download a dependency, then look inside it to fix a bug, you discover that there's whole new syntaxes you never saw before. Or you want to use a dependency but can't because it uses nightly and you don't. Or it uses a different flavor of async io than your http client does, or, or, or etc.

Rust is a toy for elite home code poets. And what beautiful things they craft! Those of us who are paid to program don't have the luxury of playing with it on work time.

Mozilla, Dropbox, Google, Microsoft, Buoyant and a lot of other companies empirically disagree that “Rust is toy for elite home code poets”.

Amazon also has a substantial VM system in production. It looks like we can probably start adding Apple to that list as well.

Ooohh what is Apple doing with Rust?

https://mobile.twitter.com/benwilliamson/status/124011360637...

Ooohh that’s so cool!

"you discover that there's whole new syntaxes you never saw before"

That is the problem I have too.

Can you please not do programming language flamewar on HN? It has destroyed other forums in the past and we don't want that to happen here.

https://news.ycombinator.com/newsguidelines.html

> For those that assert Rust changes too much, I would submit the simple question "Why?" to them.

There was a blog post a couple days ago that made the complaint. Not linking because even the author felt it was too easily misread. From my understanding, the crux of the complaint was that it is hard to "keep up" with Rust. I think the idea is similar to the complaints made here about Javascript frameworks and friends. This is where the current blog post comes in, trying to quantify things to see how much justification there is to the complaint.

Personally, I don't think Rust is changing too much but it can easily be perceived that way and we can do stuff to help that perception.

One goal of Editions was to provide a rolled up release announcement to catch everyone up. The current blog post calls out how feature announcements are different between releases and editions. So I feel there is something we can be doing better about Editions. Maybe we should always schedule them, even if there are divides where code breaks. This would build trust in the wider community that if they don't need something specific, they can watch the Edition releases from a distance.

Another thought I had is that we can do a better job classifying changes. The current post talks about major, medium, and minor. My framing is from C++: pervasive vs library features. Right or wrong, some complain about complex C++ features and it gets excused as a feature the average developer can ignore because it is more targeted at the type of people who write boost libraries. We can be a lot clearer in the Rust community with what role a feature fills. Is it for a niche? What niche? How do we let people know if they should care or not?

So to be clear, I wanted to write this post for a long time. That post did spur me to finally write this, but it is not intended to be a “rebuttal.” I don’t think you can rebut subjective experience.

This is an attempt to figure out why that experience was had. I suspect that library and ecosystem breakage contributes to this feeling much more than the core distribution, so this is the first step towards that. I don’t yet have a methodology to quantify ecosystem breakage...

It could be an artifact of my interest areas, but all of the code I've worked on in rust and their dependent libs only work on rust nightly. The rust feature areas that I run into are

- Function/closure serde - Futures/Async - WASM

I'd be curious if part of the instability complaint is related to a problem of averages, the "average" program shouldn't be experiencing much change - but the average developer spends most of their time writing a non-average program, and will run into a stability issue related to some library/language feature.

> "Why?"

Because the rate of change exceeds the community's rate of making good decisions.

Letting things bake for 2-3 times longer would lead to better designs.

Do you have specific things in mind? I think stuff bakes a lot longer than you may think, but that’s just a hunch! It also might mean we think of “baked” in a different way.

Stuff bakes in nightly for ages, often to the frustration of people like me that want to use cutting-edge features like more expressive `const fn`s =P

Most significant changes to the language "baked" for more than a year, usually 2+ years.

Oh boy. The author of this post gave a speech about Rust’s journey to async/await: https://m.youtube.com/watch?v=lJ3NC-R3gSI

I highly recommend you skim it. It will show you how meticulous the core team is and how long it took to arrive at this incredible, best in class design.

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.

> 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.

Reading code matters too. Languages are not just written

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).

And one day, tokio or some other Future-library will be needed as a solution and I'll need to read a state-of-the-art codebase with all the newest features.

> I couldn't bother to decipher how paths and `extern crate` had changed.

I don't know if you're looking for this, or if it will help, but here's the way I think of it:

In 2015, `use` paths are relative to the root module of the crate, and `extern crate` adds dependencies as items there.

In 2018, `use` paths are relative to one level above the root module of the crate, or "the root listing of all crates".

That's it- if you think of them like file paths, the edition basically just did `mv /your_crate/{all extern crates} /`, or alternatively `mv /{all your items} /crate/`.

The "2018 edition guide" covers this fairly well.

https://doc.rust-lang.org/edition-guide/rust-2018/module-sys...

I feel your pain.

People are mossing the point, and instead of seeing that learning a moving target is a PITA they are "helping" you with solutions to your problems...

I love Rust. I hope to get a chance to use it professionally. But I expect my C coding skills are more valuable for now, so it will remain a hobby....

It doesn't help that the Reference still hasn't been updated to describe how 'use' paths work nowadays (for well over a year now).

Are you sure? Is there a bug? As far as I know, https://doc.rust-lang.org/stable/reference/paths.html is correct, though I haven't been doing a ton of reference work.

The bug is https://github.com/rust-lang/reference/issues/487

I'm not quite sure how it got to be that way, as the policy is that reference documentation is supposed to be written (if not actually in place) by the time a feature is stabilised.

(I know you know this, because you wrote that policy.)

Thanks! I wonder if it's been updated and the issue has not been closed, but I will take a look this week.

Someone else wrote it actually! But, we ended up relaxing it recently, due to build system concerns. Polyrepos are hard :/

It has not been updated. use-declarations.md was updated three days ago to replace incorrect text with a note saying «Note: This section is incomplete» though.

I understand why build system trouble meant the policy was changed from "the documentation must be in place" to "the documentation must be written". I do not understand why anything prevents the stabilisation process including a checklist item confirming that the documentation has been at least drafted.

I only glanced at it but saw a "differences from rust 2015" section and that would indicate to me that it got updated somehow. Regardless, I'll look into it for real, so we'll get it sorted either way.

> I do not understand why anything prevents the stabilisation process including a checklist item confirming that the documentation has been at least drafted.

Nothing really, but we have bigger designs for the RFC process ("staged RFCs") that would introduce this, and so I haven't pushed for it in the meantime as its own separate thing.

It was updated for the half-way-house 2018-edition changes in Rust 1.31 (in December 2018). It wasn't updated for the further changes ("uniform paths") made six weeks later in Rust 1.32.

> 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.

That exact same thing happened to me. When the 2018 edition came along and made a bunch of changes that seemed, from my perspective, arbitrary and unnecessary, I couldn't really be bothered to keep up anymore and lost a lot of enthusiasm for the future of language and the team in charge.

I also think the addition of async is interesting and I may have to bite the bullet and really learn 2018. Although I hate the postfix `.await` keyword that looks like member access. The recent `try` block discussion seems to be adding additional sugar that increases the learning curve for dubious gains. Would that the goal of minimalism of the standard library also applied to the language itself.

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

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.

Have you heard of the Sealed Rust work?

Nope?

This?

https://ferrous-systems.com/blog/2019-06-05-sealed-rust-the-...

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

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!

That's awesome thanks! I look forward to it.

https://github.com/ferrous-systems/sealed-rust

Awesome

> 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.

    rustup doc

gives the standard documentation (book and API) for whatever version is currently active. You should be able to install and default to any version of the toolchain you want e.g. `rustup default 1.31.0` and you're done

> And not complain that we're on 1.31.0 but this great feature is in 1.33.1.

Surely that has nothing do do with Rust's evolution, and happens on every language which is not literally dead? Even on languages with a relatively slow release schedule this happens.

You mention Python, that's what we use at $dayjob, we're currently on 3.5 compatibility. Some colleagues would like to use f-strings, or walrus, or dataclasses, and they can't and that's life.

On 2 you've got a point, but it does depend on the dev and how fast a language is moving. I tend to find, or feel this push on newer languages to always being pushed forward.

We're on python 3.7, 3.5 and 2.7, yay! :) Don't use it on embedded systems though, version just depends on who's backend, mfgtest, etc, we're dealing with.

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.

You have a point.

But also remember that happy people are silent. No one goes on a Twitter rant about THINGS ARE PRETTY OK!!!

There are plenty of happy Python people.

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.

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.

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.

> 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.

> ... 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.

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..., that was categorized as one.

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).

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.

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.

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.

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

Who uses cobol?

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.

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.

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.

Those are not completely different things. I know it’s only 5 years, and while I know it has occurred, I personally have never had a breakage in my Rust codebases due to undefined behavior.

That is a stronger guarantee being made by Rust than C or C++ have made.

>> 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.

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.

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.

> That is not very common with Rust.

I never say it is. You guys are quite on defensive stance :)

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

By and large, this has not happened to rust.

This:

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

Has sort-of happened in that soundness fixes are allowed to break BC.

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.

> With Javascript being the exception

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

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.

My personal take is that 2 is the same across both languages. C++ has actually made some more aggressive removals than Rust ever has.

Note that none of this analysis analyzes breaking-ness of changes, so I’m not sure how you got this from the post.

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.

> 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.

This is unfair. If you're going to qualify C++'s breaking changes as "slight specific manageable caveats", then you need to do the same for Rust. "Rust changes are backwards-compatible with slight specific manageable caveats" is a perfectly reasonable description of Rust's language changes.

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.

You have examples for that?

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.

Citations please. I've picked up projects from 2 years ago, and barring soundness bugs, I've never encountered issues.

Reply on news.ycombinator.com