1. 27

  2. 34

    I’m writing a lot of Rust, and have been for at least a year or two now. I find articles like this curious, because I also place a high value on stability and I feel like I have it in Rust. I’ve spent a lot of time in other ecosystems like Node, and a bit in Python and Scala; I don’t expect any of the software I wrote in those languages will still work today without serious refactoring or even just rewriting. In contrast, I feel the software I’ve written in Rust will continue to compile and operate for years.

    I don’t follow every new feature that comes out, and I know there’s a lot of surface area in libraries and language concepts that I don’t have stored in my head. It doesn’t really feel like that’s bad, though. The async/await stuff is a huge positive change, because raw Futures were, charitably, inscrutable. Many other changes have just been small improvements to toolchain performance, or quality of life features, or improved orthogonality, or whatever else. It’s been rare that I’ve needed to ingest and retain every little new detail in order to keep making working software.

    My position is kind of the negative space, though, that surrounds whatever drives people to write these articles – it’s hard to think of a way to turn it into an explicit, positive article myself. I’d basically just be saying: It all seems like it’s going pretty well to me.

    1. 15

      The thing that struck me the most was “when will it end?” And that’s true. I feel like I’m always playing catch up.

      Sure the Edition mechanism helps but, like TFA said, documentation rapidly gets out of sync. No Rust book in print, to my knowledge, discusses async/await. Blog posts from six months ago will show ways of doing things that might no longer be idiomatic.

      Rust needs to slow down, and stop adding features for a bit. I love the language and I’m doing work in it, but there is truth to this article, IMHO.

      (And it’s important to note that, even if the Rust community doesn’t think that’s the case, this is the view of a seemingly large number of people new to Rust. It’s a complaint that I’ve seen made, and made myself, in several places. True or not, it’s definitely the perception for some people.)

      1. 6

        I honestly don’t know why they print paper books about most digital tech. Unless it’s philosophy or history it will be out of date by the time it prints. We invented web pages and blogging for a reason…

        1. 3

          documentation rapidly gets out of sync

          In the 6 years since 1.0 you’d need to reprint books twice: for the 2018 edition (simplified modules, deprecated try!()) and for async. The rest was minor, and didn’t change how average Rust looks like.

          I don’t think that’s worse than PHP or C#. Technical books have short shelf-life.

          1. 2

            Rust was probably in flux also when you started to learn it. Why weren’t you scared off back then?

            I think languages like Standard ML, Go, Ada or Scheme has an advantage over Rust when it comes to standardization, book availability and language stability.

            1. 9

              I think languages like Standard ML, Go, Ada or Scheme has an advantage over Rust when it comes to standardization, book availability and language stability.

              Notably, all of those languages (except Go, and I’m not sure it belongs on this list – Kernighan’s Go book is already wildly out of date on a number of things, and has been for a couple of years at this point) have a reputation as being somewhat lacking significant industry traction, and (deserving or not) represent something of a career niche and risk of a dead-end.

              To a certain extent, I think there’s a cultural (generational?) divide here – if you’re coming from C, where things have barely changed in 30 years and have left known, deprecated footguns in place for longer than I’ve been alive, the pace of Rust no doubt seems psychotic.

              Coming from Ruby, or JS, or C#, (or Clojure, or Scala or Swift or…) the pace of change in Rust seems absolutely sedate (and in C, downright sclerotic).

              I’m not claiming that either camp is “right”; there’s something to be said for stability, but there’s also something to be said for cleaning up the footguns and not facing an endless influx of new developers reading 30 year old texts and freshly committing the exact same mistakes as their ancestors. Languages that change too fast bleed users who can’t keep up with the ride. Languages that ossify equally seem to face a loss of users and industry attention when the problems become evident and there’s no coordinated response to solving them.

              Ultimately, for better or for worse I suspect it’s not realistic to expect that a modern language can “stop”. I think the expectation set by the post-1990s wave of languages for the post-1990s set of developers is that languages and ecosystems will continually evolve to meet new needs. I’m skeptical that we’ll ever see another language put out an ISO or ANSI standard and then simply remain static for the following decade. Not even C++ is governed that way anymore.

              We’ve all, I think, underestimated the extent to which the perceived stability of the major 70s-early 80s languages (C, Ada, Standard ML et al) was as much an artifact of the technological limitations that made communicating and distributing changes to languages a slow, high-friction process, as it was any kind of response to a wide-spread demand for languages to “stay put” on the part of users. Internet-born languages never had those limitations baked into their assumptions, and their users seem to universally expect a level of responsiveness on par with what the internet makes possible.

              1. 2


                Clojure adds features at a very slow rate, currently maybe slower than C on a year by year basis.

                1. 1

                  Clojure was created in 2007. Clojure has certainly added more feature and changed more radically, 2007-2021, than C has during that time period (C has had only one feature-adding standard released in that period, C11, and that was overall fairly minor. C17 added no new features).

                  I suppose you could be arguing that all change in C’s 40+ year life, amortized over 2007-2021 is greater than Clojure’s to date, but that doesn’t strike me as an interesting or useful analysis and really misses the point of my remarks.

                  1. 1

                    How about you do a fair comparison and compare the current rate of clojure changes with the rate of C changes 14 years after it was created.

                    1. 1

                      By all means, feel free to do whatever feels “fair” to you. But this is so pedantically irrelevant to my point that I have no interest in continuing the discussion.

              2. 3

                I’m learning it and I’m still bothered by the rate of change. Just because I don’t like how often it changes (regardless of the size of the changes) doesn’t mean I don’t want to learn it. :)

              3. 1

                I take your point. What specific changes would you recommend?

              4. 11

                Compared to 15 years ago it does feel like we are undergoing a “Cambrian explosion” in both new languages and new features in existing languages entering the mainstream. Back in the day there didn’t seem to be much room for more than a few languages in commercial spaces; everything else was academic, niche, or hobby-only.

                I do think there’s significantly more pressure on software teams today to deliver working software faster and at a larger scale and more securely. So everyone’s cramming in features to address any real or perceived scalability and expressibility shortcomings.

                1. 9

                  Ya - I’ve built a sizable released product using Rust and have generally been slow to adopt new features. I’m not opposed to them but I just don’t pursue most of them.

                  Basically the ones we do integrate are the result of lints or compiler warnings.

                  1. 4

                    In contrast, I feel the software I’ve written in Rust will continue to compile and operate for years.

                    A minor point, but there is a difference between code compiling and code being considered idiomatic. C++ has always tried to maintain backwards compatibility while making significant changes in C++11,14 & 17. As a result, you can almost certainly still compile C++ code from decades ago with a current compiler. However, C++ developers talk of “modern C++” and “legacy C++” as though they are two different languages. If you want people to work on your “legacy” C++ code base, you may find that they are unwilling because they prefer reading and writing “modern” C++, or you might end up modernising your code base, in which case the end result isn’t that different to what it would be if the more recent compiler had forced you to update it.

                    There is also a slight burden placed on C++ developers. If you worked with C++ in the nineties and haven’t been eagerly keeping up with the recent developments, you probably can’t just walk into a job working on modern C++ (although you can probably find a job maintaining some legacy code that no-one else wants to touch any more).

                    It’s possible that rust could see a similar effect if it keeps evolving rapidly while maintaining backward compatibility.

                    1. 1

                      I think Rust’s biggest problem is that it doesn’t have a story for deprecations and removals, which is in my experience a difference between mature languages and ones like Rust.

                      async/await is certainly another item, where it’s not clear whether the complexity was worth the cost.

                    2. 22
                      1. 14

                        The article is one starting point for discussion, but I don’t find it convincing.

                        1. It doesn’t help that the author doesn’t explain what they mean by sustainability. Sustainability for whom?

                        2. The concept of stability is muddled:

                        A programming language is a platform. You can’t build a thriving ecosystem on top of an unstable platform.

                        What does the author mean by stability here? They seem to be referring to the rate of change, without distinguishing backwards compatibility from new features. In my experience, Rust’s versioning and feature gating are solid.

                        1. Based on my experience with Rust, I’ve found changes and new features to be discussed in considerable detail. I don’t get the impression that things are rushed.

                        2. Generally, the argument that 6-week development cycles are the biggest risk is weak:

                        Unfortunately, there is one thing that makes me anxious about its future: the 6-week development cycles. It’s one of the causes of an unhealthy problem: features bloat. It’s also the cause, in my opinion, of another problem: the immaturity of the ecosystem.

                        I’m unconvinced. Development cycle length does not have to be coupled to deciding what features to add. If it is, in practice, let’s look at those connections and see what levers can be adjusted.

                        1. 5

                          Seconding point #4: I’m under the impression that shorter development cycles reduce feature bloat because it takes away the pressure to squeeze half-finished work into a big release. Devs can take their time to polish or sit on a new feature when they only have to wait six weeks for their next chance to release.

                        2. 9

                          I agree Rust’s pace of changes can feel overwhelming and you may feel like a hamster in his wheel. For what it’s worth, as one of top 100 contributors to Rust repository (Rust’s contributor base is incredibly wide: top 100 requires more than 150 commits), my recommendation is not to try to write idiomatic Rust. Idiomatic Rust is fast-paced, but Rust is not. In fact, Rust mostly didn’t change for 5 years since 1.0.

                          I still have my personal projects with Rust edition set in 2015, even if 2018 edition is out and 2021 edition is in preparation. By habit, I still write Rust code as if NLL and match ergonomics are not yet implemented. That’s okay. You can do that too. Nobody will (okay, nobody should) blame you. In fact, enormous engineering resource is spent to enable you to do this! It is design intent of Rust for you to do this. Just think about it: it’s no worse than using C++14 even if C++17 is long out and C++20 is just out. C++14 (even C++11) is modern C++. In most respects, Rust 2015 edition is more “C++-modern” than C++20. Don’t blame yourself. You don’t need to write idiomatic Rust.

                          1. 1

                            I think that’s basically my approach too. I compile my code against Rust 1.13.0 on the CI, while developing on the current version. That means I get a compiler twice as fast, but with the guarantee that it keeps working on existing versions.

                          2. 7

                            The Rustacean Station podcast goes through the changelog for each release. They typically contain quality-of-life improvements to the compiler and filling in “gaps” to existing APIs. For example, 1.48/49 stabilized the move_ref pattern which makes it easier to use values after matching on them, const-ified some functions in the standard library, and added future::ready() and future::pending(). The big feature was “intra-doc links,” which lets you write doc-comments that link to different parts of the code. ARM Linux was also added as a Tier-1 platform.

                            These changes should make it easier, not harder, to learn Rust. They also shouldn’t require drastically changing your existing code.

                            My biggest concern is the maintenance burden. I feel enough a part of the Rust community that I care about contributors I’ve never met. I worry about the increased interest from larger companies who may try to accelerate development of features they want without sufficient consideration for the effort it takes to build or maintain those same features, and how they may affect unrelated parts of the ecosystem. Fortunately, it seems as if the Rust leadership also shares these concerns. I know they’ve spoken about people being burned out trying to ship the 2018 edition and want to ensure that doesn’t happen for the next one. They recently announced a new rule that (IIRC) no more than 2 people from the same company can be a part of a single working group. So I’m hopeful.

                            OK, let me take off my contributor/backseat driving hat for a second. As a user of Rust, over the last year I have been happy with all the changes I’ve seen. I actually just updated my (~4000 LOC) project a month or two ago after not touching it for 6 months and it took me two hours to get it to Rust nightly. I was not surprised.

                            1. 5

                              “Programming in Rust today is entirely different than what was programming in Rust 1.5 years ago (mainly due to async-await hitting stable).”

                              Well I don’t know about that

                              1. 3

                                Yes, this is what confuses me about this mindset. From my point of view, things have felt “paused” for a while, especially in regards to audience-facing async. But maybe that’s just the weird pandemic time-skew.

                                1. 2

                                  Well, Tokio 1.0 is out 2020-12, for some time there were lots of churn updating to Tokio 1.0. It has been a “pause” only if you focus on the language itself.