To help the Rust language continue scaling across domains and usage levels, the Rust Vision Doc group recommends enumerating the design goals for evolving the language while also improving the crates package system.

These suggestions were made in a December 19 blog post titled, “What do people love about Rust?” The group made the following specific recommendations:

• Enumerate and describe Rust design goals and integrate them into processes, helping to ensure these are observed by future language designers and the broader ecosystem.
• Double down on extensibility, introducing the ability for crates to influence the development experience and the compilation pipeline.
• Help users to navigate the crates.io ecosystem and enable smoother interop.

In seeking to explain developers’ strong loyalty to Rust, the vision doc group found that, based on interviews of Rust users, developers love Rust for its balance of virtues including reliability, efficiency, low-level control, supportive tooling, and extensibility. Additionally, one of the most powerful aspects of Rust cited by developers is the way that its type system allows modeling aspects of the application domain. This prevents bugs and makes it easier to get started with Rust, the Rust vision doc group said.

The group said that each of these attributes was necessary for versatility across domains. However, when taken too far, or when other attributes are missing, they can become an obstacle, the group noted. One example cited was Rust’s powerful type system, which allows modeling the application domain and prevents bugs but sometimes feels more complex than the problem itself. Another example cited was async Rust, which has fueled a huge jump in using Rust to build network systems but feels “altogether more difficult” than sync Rust. A third obstacle, the group said, was the wealth of crates on crates.io, which are a key enabler but also offer a “tyrrany of choice” that becomes overwhelming. Ways are needed to help users navigate the crates.io ecosystem.

The group recommended creating an RFC that defines the goals sought as work is done on Rust. The RFC should cover the experience of using Rust in total (language, tools, and libraries). “This RFC could be authored by the proposed User Research team, though it’s not clear who should accept it—perhaps the User Research team itself, or perhaps the leadership council,” the group said.