Rust stability in 2019


What if I replace the word stability with productivity.

Rustup is a nice thing, but in reality for a new user there is a lot of more subtle notions to acquire before becoming productive (like acknowledging that you need a stable toolchain to compile your code + a nightly one to lint / test / benchmark).

The second thing is the ecosystem fragmentation, having some users using nightly and other stable is maybe nice for hobbyists but not for world scale collaboration scenarios. From an external point of view it really looks like the python 2/3 problem.

Here again as a newcomer I feel that the rust ecosystem is fighting against my productivity.

Error handling is not even stabilized / a consensus in Rust (failure vs error_chain).

You can call it stagnation, but on the other hand it’s one of the reason that go is so successful compared to Rust: users have all access to the same set of stable and (almost) bug free features used by modern applications (HTTP, crypto, database, encoding, language parsing, templates, math… In stdlib), and develop frameworks arround this without being worried that their work will become obsolete in 12 weeks (because it will not). There are things far from perfect (error handling for example), but it works, it just works!

On the other hand, in rust the http library which seems to be the consensus (today, but what about in 18 weeks ?) Is 0.1.14. And it doesn’t even include a client and a server.

So if I want to create an HTTP application in rust today I should be okay with the fact that either I need to reinvent the wheel and recreate an HTTP stack (actix web) incompatible with the most popular one, either I should accept that maybe the popular one is buggy and I will need to upgrade all my code in 2 months because the fix will land in a release breaking the API.


I do not see “nightly” mentioned there. Are you perhaps misinterpreting the “stability” of each lint? The page says:

Each configuration option is either stable or unstable. Stable options can be used directly, while unstable options are opt-in. To enable unstable options, set unstable_features = true in rustfmt.toml or pass --unstable-features to rustfmt.

This is not related to which toolchain (stable/beta/nightly) you’re using.

I wasn’t aware of this feature, but looking into it, this is for access to the internals of the Rust test framework. As I said, the framework itself has been stable for quite some time and requires no special opt-in. Including unit tests and functional tests in your code, which can be run by cargo test, is trivial.

What are you using #![feature(test)] for, or planning to use it for?


#[bench] tests.

Since they’re not stable and not documented in the book, most people have never even heard of them. And it’s available as a crate, though the bencher crate is probably even less widely-known than the one built into rustc’s libtest, so not many people use it, either.


Ooops, sorry I totally missed this point and effectively misinterpreted the unstable word.

The feature(test) is required to run benchmarks and thus ensure non regression


To prove my point, look at the most popular rust programs on Github: they are all CLI apps because fs is in stdlib.

With a richer and stable stdlib Rust could become the perfect mix between go and Scala!

That is the stability thing in the title and IMHO what blocks broader adoption (and here Im not talking about Google/Mozilla/Amazon which have a lot of money but all the other enterprises with normally sized dev teams and want things to get done).


I don’t know of any mainstream language with a “consensus view” on error-handling, except maybe Python, where throwing exceptions on non-exceptional/non-fatal conditions, then catching them, is considered “Pythonic”.

This is fundamentally because Go serves a different purpose than Rust does. It was designed to be a fairly simple language with a robust runtime that focuses on making inter-process communication trivial. Rust is a fairly complex language with no runtime that focuses on giving the programmer a C- or C++ like level of control over the hardware, particularly in-memory data layouts and pointer-accesses.

That’s because the Crate ecosystem is highly modular (which I believe is generally a good thing, though the npm ecosystem has had some severe problems with over-reliance on small packages), and http is a pretty low-level crate. There are many higher-level crates that provide client/server code.

…since actix-web is a full-featured web framework, I assume you meant to put “(actix web)” after your comment about incompatibility? In any case, since actix-web itself relies on smaller crates, you don’t have to be incompatible with actix-web if you wish to create your own framework; you can just use the same dependency crates in your framework.

I’m sorry, but I don’t understand what this has to do with Rust or the ecosystem at all. “Maybe popular packages are buggy” is a problem with software in general.

However, your assumption that a bugfix would necessarily break an API is completely incorrect (again, in any language ecosystem, but particularly in one like Rust that tries to follow SemVer-like principles). Please look at the links above about SemVer.


Ah, okay, yes, I understand now that there is some benchmarking functionality built into the toolchain itself that you can’t access except in nightly. (I did not realize this before.)

But as noted above, there’s a crate that works on stable for benchmarking. It is pretty standard in systems programming languages (C, C++, Rust…) to do benchmarking without relying on the toolchain itself to provide the benchmarking capabilities.

Again, this is not the goal of Rust. Both of those languages use pretty heavy runtimes and therefore are not “systems” languages in the same sense as C/C++/Rust. Additionally, the Rust team and community are being conservative with regard to the standard library and built-in toolchain features, which is largely because having a “kitchen sink” style standard library (like Java) makes it difficult to avoid making design decisions that we’ll regret in a few years (or decades) but which must be supported indefinitely (assuming, as we do, that we do not want to break compatibility).


In a very real sense, you’re completely right. This is a pretty awful state of affairs. And nobody can tell you when it’ll stop, because it’s not actually on a fixed schedule.

You’re not the only one who’s pointed this out, though you’re getting a bit of an unreceptive reaction because you’re implying that it’s a mistake when it’s actually kind of planned.

The core goal behind the “stability without stagnation” concept was built around three points:

  • The libraries, like HTTP, can’t be built if the language they’re built on is changing constantly. The language has to be stable, in that sense, before the libraries can be.

  • The library vendors are going to find pain-points in the language in the process of preparing their libraries.

  • This creates a circular dependency. The library vendors don’t want to build their libraries until after the language is frozen, the language designers don’t want to freeze the language until after the pain points have been fixed, and the pain points won’t be found until after the library vendors have used the language.

That’s pretty much why Rust 2018 exists; it fixed a number of language pain points that had been revealed in the process of making the libraries. Since the number of stable libraries will only ever grow, I’m sure it will be better next year, though I can’t really guarantee how many libraries or how much better.


“Productivity” carries much of its own baggage. :smiley: It’s hard for anyone to be truly productive with a language they are unfamiliar with. So you’ve learned Rust 2015, and you’re now productive in Rust 2015. That should not necessarily mean you are going to be immediately productive with Rust 2018.

In practice, there aren’t really any changes between the two editions that are even remotely close to a paradigm shift. I mean, the kind of learning curve that an OOP student might face when trying to learn a pure functional language, for example. The delta between Rust 2015 and 2018 is no where near as daunting. But I digress.

In theory, it is very possible that language evolution could approach that kind of an extreme change. And I argue it is a good thing. Even a requirement. Not unlike the reason we have to update our computer/phone hardware every 2~5 years. (And the interval is actually speeding up) Technology is advancing much more quickly now than it was in the 80’s and 90’s. So too it is with software.

I would not call Go stagnant. Quite the opposite, as you can see by following that ecosystem. They are even trying to address the dependency problem, at last: And of course, Go 2 is on the horizon, with lots of breaking changes forthcoming!

I see where you are coming from, but there are a ton of trees in this forest. And I feel like you are only focusing on just a few.


Points you make are generally accurate, but IMHO exaggerated, e.g.

Python’s 2/3 split is a serious 10-year ecosystem-wide interoperability problem. OTOH only few Rust crates use nightly features. Nightly is compatible with stable, and as features get stabilized, crates that used to require nightly become available on stable (two years ago I’ve worked on a project that used many nightly features. Last year the project moved to stable).

There is consensus in Rust around using the Result type. The multitude of crates just provide different ways of building on top of it, with extra features if you want them. Rust is about control — maybe you want your errors to take only 1 byte, or maybe you want your errors with full stack traces and captured variables.

Things becoming obsolete in “12 weeks” is a gross exaggeration. There is some churn in 3rd party crates, but it’s on scale of years. And things become obsolete, because we’re able to find much better solutions instead of being stuck with an immortal one in stdlib, e.g. rustc-serialize was first, but serde ended up being much better.

Rand is an interesting example, because it turns out that correct, flexible and fast random number generation is much much harder to do than it seems. The rand crate is on its 6th version. It’s much more refined than if the v1 was set in stone in the stdlib. That is some churn, but: older versions still work and you can keep using them, even if your dependencies use some other version.


after setting up rustfmt

 can't set `indent_style = Block`, unstable features are only available in nightly channel.

Acknowledged so, who is in charge to say No to new features in favor of stability ?


Hmmm, rustfmt is part of Rust’s stable release and you don’t need nightly toolchain to use its core functionality. It has some of its own features that are experimental/unfinished/don’t have consensus, so it wants to limit their usage.

What would you expect from it? Is the problem that rustfmt is still being developed? Is the problem that rustfmt exposes unfinished features to users? Or just that it’s unclear that “nightly” in Rust’s ecosystem is treated more like “beta-testing”?


The core team, and some of the teams under them, are responsible for the language proper.

What they cannot do is stop people from writing crates. Things like http that you mentioned are not actually a part of the Rust language organization. Rustfmt and clippy also started outside of the official Rust organization, and were blessed by the core team and put on the release trains well after 1.0.


I think the problem is more the feeling that the whole ecosystem is a beta because the basic tools/crates require nightly (I acknowledge it’s not accurate as we’ve seen with bench, but it’s true for rustfmt or rocket which is used to market Rust as production ready for the web: while being sold as a 1.0.

I think I have all the responses I need.

Now a last word for Rust core team members, as a Rust newcomer with a fresh eye and with production / productivity requirements, please don’t be a new Haskell (, same feelings, better words, 1 year ago).


Since many of the 2019 roadmap submissions echo some of what you state, this topic is a bit of a discussion on the general idea of going slower. My take on this matter is: don’t worry, at the very least, the core team and others can’t afford to go at the same pace as the last three years. They’ll either die from exhaustion or start making serious mistakes, and they know this. From

At the same time, I’ve also noticed a lot of exhaustion. I know I feel it – and a lot of people I talk to seem to feel the same way. It’s great that so much is going on in the Rust world, but we need to get better at scaling our processes up and processing it effectively.

This one should also help describe what to expect in the short term:

The same thing is stated there:

slow down with the syntax. We would like to see a slowdown in language evolution. We have been training colleagues who have been working in C for over 25 years, and they are having a hard time learning and effectively using all the new features"

But, what I tell myself is
a) have faith, Rust got this far by excellent teamwork and world-class decisions, I think it will continue with that, even if the future needs to look a bit different from the past. Helping to personally contribute to this will ensure that this stays true.

b) I feel Rust is a much more complicated language to get right than Go, @BatmanAoD stated something similar, and as an electronic engineer, I see Rust as the FIRST attempt to really displace C/C++. Look at this ranking:

It will simply take more patience and hard work to get Rust to displace C/C++ in those tables. What will never ever replace it? Go, Pony, Scala, Haskell, blabla. In that sense, Rust has no competition. I will stick with Rust, even if it makes many mistakes (which it won’t), because I can’t use Go for what I want to do, it’s either Rust, or C/C++ for me, literally nothing else is technically capable enough while being productive. For those with similar technical requirements as me, the bar is, in fact, set quite low.

I’d like Rust to compete with Go on networking, as that will flow over to higher productivity in my use cases (probably), but it will take more work than any other ‘new’ language to achieve that, even if it is just because of the massive scope of uses that Rust encompasses. Unfortunately, Rust is larger in scope and more technically constrained due to allowing for its memory handling. Therefore, expect things to take longer to gain traction than elsewhere. The flip side is that the payof will be higher… it can replace C++ without any competition: it’s a race of one with the only requirement to not fall off the racetrack.

TWiR quote of the week

I’ve been following the RISC-V development closely. RISC-V is in many ways positioned similar to Rust; it learns from decades of experience, has a great foundation to start of from, but also needs to change to stay very much up-to-date, while it needs to ensure decades-long compatibility.

Page nine of the resent “state of the Union” presentation gives the steps:

Define need 2. Gather inputs, hold mee?ngs, whiteboard-­‐level design arguments, finish stable draS 3.Build implement?on according to draS 4.Build software for implementa?on 5. Evaluate, iterate from step 2 (maybe many ?times) 6.Community agrees to push for ra?fica?on 7.Ra?fica?on 8.Deployment / Compliance tes?ng 9.Replacement

The only way is to experiment with features, build software with it, and then stabilise (ratify) that which works. The experimentation+building parts need to happen, with the possible lack at present in Rust that accepted changes aren’t reversed that often (not stabilised/removed from nightly).

The vector spec version 0.1 in RISC-V was absolutely torpedoed after it failed to gain consenses. Many people were sad, because 0.1 polymorphism is a beaut, but, such is life.


Why not Pony? It’s compiled and has no managed runtime.


Because my perception of it is that it’s not meeting its design goals. I could be wrong, but Pony is an example of over-promising and under-delivering at the moment. Rust does not have that problem, Rust’s core is as good as it claims to be for the most part.


This is starting to drift off-topic. The OP says they’re done, and now you’ve switched from whether Rust is stable to trying to prop it up by comparing it to other languages.

closed #54

This topic was automatically closed after 33 hours. New replies are no longer allowed.