Rust was first announced in 2010 as an alternative to C/C++. As we mentioned in one of our blog articles, the systems language promises:
C++ control without all of the safety issues like segfaults, null pointers, buffer overflows, and many other security nightmares that C++ developers have to wrestle with. Its unique selling point is the checking system that yells out error messages on compilation time, which the aging C++ language does not do. Errors seem like a minor enhancement from the viewpoint of web developers, but for low-level programmers, being warned about improper memory allocation can mean the difference between broken code and production-ready code.
Today, Rust isn’t the only C++ alternative in town. According to 2019’s Stack Overflow survey, 8.8% of professional developers primarily used Go while only 3% percent primarily used Rust. Still, the Rust community is alive and well. This year, the team put out a call for blog posts to be written about the systems programming language. They got 73 posts in response. The theme of these posts spelled that the future of Rust would be one of stability and slow progress. Below are some examples of these posts taken from Rust’s GitHub age.
- Jonathan Turner, “The fallow year”
I believe not only that the processes and institutions of Rust need to be shored up, but that special attention should be paid to people. Ultimately, people are what drives the language forward, whether it be through design, implementation, or outreach. If no people want to work on Rust, or are blocked from working on Rust, the language will stagnate. …
This is not to say that there should not be any movement on improving features or process. Just that their effects and costs should be measured in people, as well as in technology.
- hwc, “Rust 2019: Go Slow”
In this post, I’ll refer to a highly simplified maturity life cycle with three stages: research, development, and polish. Different parts of the Rust ecosystem are at different levels of maturity. It’s important for effort to match the actual stage in the life cycle, ideally to push it to the next. For example, I consider the language to mostly be in the “polish” stage. Continuing to treat it as research would bring dependent types, virtual structs, etc., which would be interesting but disruptive. Conversely, we don’t know exactly what we want for GUI, so trying to drive that to a standardized solution too early will likely get us to a suboptimal place.
Many mature products have alternating releases focused on new features, then stabilization… 2018 has seen a lot of new features, so I think it’s time for a stabilization phase.
- Raph Levien, “My thoughts on Rust 2019”
If you’re familiar with the history of Rust you might be confused with a call to stabilization. After all, Rust 2015 (a.k.a 1.0) was all about stabilization and the team has actually done a pretty good job with achieving this goal. So what gives?
While Rust 2015 defined stabilization around language backward compatibility, it’s time for the language, the tooling, the ecosystem and the governance to stabilize. Each of these characterize stability in a different way.
- Ryan Levick, “Rust 2019: Stabilization”
The Rust project has been growing like a startup for the last several years. This has some good aspect – “hockeystick curves” – but it has some very bad aspects as well. If this project is going to have a chance of sustaining itself in the long term, we need to get real about dealing with the organizational debt we have accumulated. I think we have serious problems at every level of our organization that need to be addressed, and I’m going to enumerate them from my personal perspective.
- withoutboats, “Organizational Debt”
The rust team categorized stability or maturity into three categories:
- Governance: improving how the project is run
- Finish long-standing requests: closing out work we’ve started but never finished
- These requests include the Cargo team and custom registries; async/await, specialization, const generics, and generic associated types; and custom allocators
- Polish: improving the overall quality of the language and tooling
- Polishes include improving compiling times, improving wasm support, and improving specs
The importance of language maturity is crucial now because the current cost of using Rust is overcoming a learning curve. Making sure that the language is mature would mitigate the need to lose time fiddling with limited support. As one blogger mentioned, “…Rust 2021 should be about Rust’s maturity.” He went on to define what maturity is. ‘To me it means that for a programmer in 2022, Rust is a safe choice with many benefits, not a high-risk/high-reward choice. Choosing Rust for a project should be a competitive advantage (which I think it is today), but it should not require investment in libraries, training, or research.”