Goals and Directions for Rust in 2019

This is my response to the call for 2019 roadmap blog posts proposing goals and directions for 2019 and future editions. See also Read Rust, where I’ve collected all the #Rust2019 posts.

2018 was a very busy year for the Rust project. A new edition was released, progress on stabilising Rust’s asynchronous I/O story was made, a new website was launched, and so much more! In 2019 I’d like to see the language and wider crates community become more sustainable, address some common gothca’s that newcomers experience, and promote more platforms/architectures to tier 1 status.

2018 Retrospective

Before diving into 2019 goals I think it’s worth tracking how the project went on my ideas from last year:

1. Become a better option for building network daemons and HTTP micro-services.
2. Continue to improve the discoverability and approachability of crates and Rust’s web presence in general.
3. Gain wider, more diverse tier-1 platform support (especially on servers).
4. Start delivering on the prospect of safer system components, with fewer security holes.

Network Services

A lot of progress was made on Futures async/await in 2018. The keywords were reserved in the 2018 edition but are not yet usable on a stable release. Are we async yet? shows there’s still some work to do. Hyper saw more major changes to keep up with the Futures work and added HTTP/2 support!

Improve Rust’s Web Presence

The Rust web presence was improved with the release of the new website and blog. The rest of the ecosystem remains much the same. Content from crates.io is still largely invisible to non-Google search engines such as DuckDuckGo (my primary web search tool), and Bing. The Rust Cookbook remains in the nursery.

Platform Support

Tier 1 platform support remains unchanged from last year. There were a number Tier 2 additions/promotions.

System Components and Increased Safety

The oxidisation of librsvg continued in 2018 to the point where almost all the public API is done in terms of Rust. I’m not aware of many other projects following this path at the moment:

Rust 2019

In 2019 I’d like to see the Rust community focus on three areas:

1. Sustainable development
2. Make is easier for newcomers to write fast code / don’t surprise people
3. More portability

Sustainable Development

Recently Murphy Randle and Jared Forsyth were discussing the event-stream compromise on the Reason Town podcast. Jared commented:

The problems of having infrastructure that’s based on unpaid labour that has a high degree of burnout.

— Reason Town podcast episiode 13 @ 19:29

This is a pretty succinct summary of the problem with our industry. Rust hasn’t shied away from tackling hard problems before and taking on the sustainability of open source doesn’t feel out of the question. There’s evidence that many of the folks deeply involved with the Rust project are already feeling the pressure and we don’t want to lose them to burnout. Such as these posts:

• Organizational Debt by withoutboats
• Thoughts on Rust in 2019 by Steve Klabnik
• Rust in 2019: Focus on sustainability by Niko Matsakis

Part of this revolves around culture. The Rust community generally values quality, correctness, performance, and treating each other with respect. I think it would be possible to make it normal to contribute financially, or other means (equipment, education) to Rust language and crate developers (where people are in a position to do so). A simple first step might be allowing for a donate badge, akin to CI badges to be added to crate meta data and have this shown on the Crate page.

Michael Gattozzi covered some similar thoughts in his, Rust in 2019: The next year and edition, post.

Naïve Code Is Fast Code

People hear that Rust is fast and lean, they try it out converting something from a language they already know and are surprised to find that it’s slower and/or a much larger binary.

There are many many many many examples of this in the Rust Reddit. Things that frequently seem to trip newcomers up are:

1. Not compiling with --release
2. Stdio locking
3. Binary size

It would be good to apply the principle of least surprise here. I think the current defaults are inspired by the behaviours expected from C/C++ developers, Rust’s original target audience. However the Rust audience is now much wider than that. With that in mind it might worth reevaluating some of these things in terms of the current audience. These need not require API changes, perhaps they could be clippy lints. Perhaps they could be slight changes to language. For example, cargo currently says:

Finished dev [unoptimized + debuginfo] target(s) in 0.11s

Perhaps a second line could be added that says:

Compile with --release for an optimized build

to help guide people.

More Tier 1 Platforms

This one is inherited from last year. I do all my server hosting with FreeBSD and up until recently used it as my desktop OS as well. It’s not uncommon to uncover portability bugs or assumptions when using such a platform. Portability is type of diversity of software. It makes it stronger and useful to more people.

Rust is already appealing to people because of its portability. I was recently talking to a veteran developer at the Melbourne Rust meetup’s hack night about what got them into Rust. It was the combination of modern language features, native binary and portability that drew them to Rust.

To this end I’d like to see more platforms and CPU architectures promoted to tier 1 status. Up until recently one thing that made this difficult was the lack of hosted CI services with support for anything other than Linux, macOS, and Windows. Recently two options have become available that make it possible to test on other systems, such as FreeBSD. There is Cirrus CI which includes a FreeBSD image in their hosted option, as well as the ability to create custom images. Secondly there is sr.ht, a completely open source (but hosted) option that supports a variety of Linux distributions, and FreeBSD, with more planned.

Pietro Albini suggested in his post that the Rust infrastructure team is already planning to start the discussion on CI options. I think this would be a perfect opportunity to integrate more platforms into the CI infrastructure:

One of the biggest one is switching away from Travis CI for the compiler repository. In the past year we had countless issues with them (both small and big), and that’s not acceptable when we’re paying (a lot) for it. The infra team is already planning to start the discussion on where we should migrate in the coming weeks, and we’ll involve the whole community in the discussion when it happens.

Conclusion

After an intense 2018 it sounds like the Rust project needs to focus on making the project sustainable over time. I’d love to see some improvements to address issues newcomers often experience and push more platforms to tier 1 status. Rust is still very exciting to me. I can’t wait to see what 2019 brings!

For more great #Rust2019 posts check out readrust.net.