#Rust2018

As part of #Rust2018, I thought I would try to writeup my own (current) perspective. I’ll try to keep things brief.

First and foremost, I think that this year we have to finish what we started and get the “Rust 2018” release out the door. We did good work in 2017: now we have to make sure the world knows it and can use it. This primarily means we have to do stabilization work, both for the recent features added in 2017 as well as some, ahem, longer-running topics, like SIMD. It also means keeping up our focus on tooling, like IDE support, rustfmt, and debugger integration.

Looking beyond the Rust 2018 release, we need to continue to improve Rust’s learning curve. This means language changes, yes, but also improvements in tooling, error messages, documentation, and teaching techniques. One simple but very important step: more documentation targeting intermediate-level Rust users.

I think we should focus on butter-smooth (and performant!) integration of Rust with other languages. Enabling incremental adoption is key.¹ This means projects like Helix but also working on bindgen and improving our core FFI capabilities.

Caution is warranted, but I think there is room for us to pursue a select set of advanced language features. I am thinking primarily of const generics, procedural macros, and generic associated types. Each of these can be a massive enabler. They also are fairly obvious generalizations of things that the compiler currently supports, so they don’t come at a huge complexity cost to the language.

It’s worth emphasizing also that we are not done when it comes to improving compiler performance. The incremental infrastructure is working and en route to a stable compiler near you, but we need to shoot for instantaneous build times after a small change (e.g., adding a println! to a function).

(To help with this, I think we should start a benchmarking group within the compiler team (and/or the infrastruture team). This group would be focused on establishing and analyzing important benchmarks for both compilation time and the performance of generated code. Among other things, this group would maintain and extend the perf.rust-lang.org site. I envision people in this group both helping to identify bottlenecks and, when it makes sense, working to fix them.)

I feel like we need to do more production user outreach. I would really like to get to the point where we have companies other than Mozilla paying people to work full-time on the Rust compiler and standard library, similar to how Buoyant has done such great work for tokio. I would also really like to be getting more regular feedback from production users on their needs and experiences.

I think we should try to gather some kind of limited telemetry, much like what Jonathan Turner discussed. I think it would be invaluable if we had input on typical compile times that people are experiencing or – even better – some insight into what errors they are getting, and maybe the edits made in response to those errors. This would obviously require opt-in and a careful attention to privacy!

Finally, I think there are ways we can offer a clearer path for contributors and in turn help grow our subteams. In general, I would like to see the subteams do a better job of defining the initiatives that they are working on – and, for each initiative, forming a working group dedicated to getting it done. These “active initiatives” would be readily visible, offering a clear way to simultaneously find out what’s going on in Rust land and how you can get involved. But really this is a bigger topic than I can summarize in a paragraph, so I will try to revisit it in a future blog post.

A specific call out

If you are someone who would consider using Rust in production, or advocating for your workplace to use Rust in production, I’d like to know how we could help. Are there specific features or workflows you need? Are there materials that would help you to sell Rust to your colleagues?

Footnotes