Rust 2019: Laying the groundwork for an amazing future
This year another call for community blog posts on the future directions for Rust is up. This post re-iterates some of the points I mentioned last year (including simply copying some parts of the text), while re-stating the issues in the context of Rust 2019.
A summary is that I think that the two most important themes is community management and support for awesome libraries. The why, how, and what is discussed below.
Themes to focus on
If we are to set up a list of themes to focus on, this means that we need to prioritize what is important. As a natural consequence of this, we also need to decide what not to do. A to do list that includes everything is meaningless, since it gives us no guidance at all.
Leadership fatigue
Rust is radically open for participation, and this is a wonderful thing in many cases. However, this year it has become increasingly obvious that the Rust leadership is starting to feel the effects of managing a radically open project while still delivering features and growing the community. Without making all the hard work of the people leading the Rust development sustainable, nothing will happen.
No application is written in isolation
A language may be the best possible language for writing a program in, but the amount of code any one developer or team is capable of writing is limited. To produce something larger, relying on libraries is a must.
The experience of using a (set of) libraries to implement an application is often what we think of when describing the experience of using a language. Rust has, through the crate eco-system, a very good infrastructure for accessing and using existing libraries. Many of these libraries are of very good quality, and some are real joys to use. Expanding the number of high-quality libraries is of course important, but more important is to consider what kind of libraries are possible to write!
Laying the groundwork for an amazing future
If the issues in community management can be solved, and support for true best-in-class libraries is available, I think that that will be the groundwork for an amazing future for Rust.
What to prioritize
Given leadership fatigue and the goal of having powerful/elegant/ergonomic libraries, what should we actually prioritize?
Community
I don’t have any good insights into what is required to effectively managing large open communities, so I will just say that the blog posts by boats, Niko Matsakis, Florian Gilcher and many others from prominent Rust personalities are required reading.
Libraries
Getting back to the more technical side does not mean that things are clear-cut and easy. Saying that we should focus on libraries is one thing, but what does it actually mean?
Similar to my post for Rust 2018, it is important to consider what kinds of libraries there are. Please see the linked section for my thoughts on the interesting types of libraries to consider.
The main point is that the libraries categorized and listed in the above post (and many many others) are the kind of libraries that enable a Rust programmer to write large and interesting applications. To find out what to prioritize, it is important to look for what such libraries need from the language.
Specific examples on things to prioritize
The following is a short list that I think captures many of the for libraries transformative changes for Rust. That the list is “short” in no way means that it represents little work, or even that it is feasible to make all this happen in the scope of Rust 2019 (but hopefully in the scope of a supposed Rust 2021 edition).
Improved support for generic types
Generic types (and the monomorphization that is typically used) is very important for making Rust code that is both safe and fast. However, it is obvious that there are some cases where library authors really want to take the design the last mile, and there are features that are missing.
The three main things that will enable new and exciting possibilities for designing libraries in my opinion are generic associated types, specialization, and const generics. All three are large, complicated, and intricate problems to solve for a sound and usable design and for making it possible to implement correctly. Solving these issues requires a lot of effort, but I think will ultimately be worth it.
Asynchronous code
The potential for writing small, robust, and memory-efficient network services in Rust is inspiring. With great support for asynchronous code as a stable first-class feature of the language, I think Rust will get a lot more attention and find many more use-cases.
The Rust 2018 edition brought us async and await as keywords, and
the design for the new Futures and Tokio eco-systems is continually
evolving. Getting the designs finished and shipped is clearly a lot of
work, but I really hope that we will be enable to write asynchronous
code in stable Rust this year.
Macros almost there, but not quite
As of the Rust 2018 edition, the support for macros is much better than it was a year ago. Stable procedural macros and importing macros through use statements is a wonderful improvement. However, there are still a few parts that are needed to make a library such as Rocket work on stable, including macro hygiene and diagnostics. The point here is not to do this just to enable Rocket to work on stable, but to enable all the other libraries that could be written in the future.
Bindgen, FFI, and build system integrations
Not all libraries can or should be rewritten in Rust. To be able to perform all the important tasks than an application needs, it is often very important to bind to a library written in another language. Bindgen is a great start for creating bindings to C-libraries, and there is some support for C++.
Unfortunately, it is still not an easy task to create a -sys-crate
that interfaces to a library, and even less so if the library needs to
be installed. Should the library be built form source (downloaded or
vendored in), installed from a package manager, assumed to exists on
the system, and so on are all questions that need to have better
answers. Hour-long builds of a C++ dependency that could just as
easily be installed from pre-built binaries are not nice, especially
if many different Rust applications use the same dependency.
Making progress on this is hard, especially as it relates to so many moving parts and all platforms at the same time.
Things that I’m willing to not prioritize
As said previously, an important part of prioritization is a willingness to not make some things that we may all want a top priority. Given prioritizing the community and features required for libraries, many features that are focused on other qualities should not be the top priority. So what kind of things would not be a top priority?
- Documentation
- Compilation speed
- IDE integrations
- Cross compilation and WebAssembly
- Speed features such as inline assembler and SIMD
- Your favourite absolutely necessary super-duper-critical feature!
All of these are of course critically important. I need documentation to be able to work, I hate to wait on the compiler to finish, and I always use an IDE for coding (the IntelliJ Rust plug-in just keeps getting better and better). Cross compiling to all the platforms makes Rust a strong contender in many new areas, and access to low-level features such as assembly and SIMD gives Rust an edge in speed.
What I’m trying to say is that not having these as the top priority does not mean that I think that work on that should stop or that it is unimportant. It just means that I don’t think they should get prioritized above a functioning community and laying the groundwork for awesome libraries.
About me and Rust
While you can read more about me on the about page, I thought I’d mention some of my Rust background. I
started following the Rust project loosely around the time it was
first announced, back when
there was still discussion on using typestate to encode properties. I
never wrote any Rust until much later though, around the time 1.0 was
released. When 1.13 was released I started actually learning and
writing Rust more seriously. The main reason was that the ? operator
was stabilized, enabling me to write code that handles errors sanely
(especially when compared to Go). When 1.16 was released and both
Serde and Diesel started working on stable, I felt that the future was
bright for Rust and started to use Rust even more. I have several
small personal projects in Rust, and hope to write more in 2019.