Recently, the Rust Core Team solicited blog posts on where Rust should be headed in 2019. Here’s mine.

Maturity life cycle

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 (Intel’s tick-tock, Android’s Kit Kat and Marshmallow being stable while Lollipop changed tons of stuff). 2018 has seen a lot of new features, so I think it’s time for a stabilization phase. In this I agree with Jonathan Turner, along with many others.

Rust language

I think for the most part, the Rust language is complete. There seems to be pretty strong consensus that we should land existing features in flight (the development stage): async/await, const generics, and getting Chalk landed (which will likely get us GAT). But beyond that, I don’t think we should be filling the pipeline with many more new features.

Change has a cost. As of 2018, we now have two excellent books, but both are slightly stale – the conventions for qualified paths are different, we now use dyn Trait, etc. The faster the rate of change, the worse these problems are for users.

There are a lot of things holding Rust back from wider success; I don’t think most of these are in the language itself.

Tooling

Rust tooling could be a lot better. I’ve experimented with RLS, but have always gone back to using a plain text editor and the commandline cycle. (In fairness, I haven’t tried it very recently). As a longer term effort, I think tooling could go a very long way to easing some of the pain around learning curve. I have some ideas (hopefully I’ll write them up in more detail) about a more forgiving language (which may or may not be realizable) that doesn’t make a sharp distinction between a value and a reference to it, allows use-after-move, etc. Basically, in this language, a string can be treated like a number. The language server accepts programs in this language and offers quick fixes to transform them into valid Rust.

Of course, RLS is only half of the experience, users interact with it through an editor. Work on xi-editor is going well, even though I’m mostly providing light guidance and support. The community, led by Colin Rofls, is stepping up to the plate, and I’m excited to see it improve, as well as start using it as my main editor. Language server support is getting there, and new features such as a general annotations mechanism, will make it much more complete in 2019.

Library ecosystem

Building out Rust’s library ecosystem is now where most of the work lies. Below I’ll talk about things I personally plan to work on.

One theme I’d like to lift up is “coherence,” which I believe is one of Rust’s core values, in addition to a technical feature of its trait system. A lot of what makes a “game engine” in C++ land is a curated collection of libraries that work together pretty well. But in Rust, a lot of this happens organically. Crates do tend to work together, and clever use of features like into makes things even better. A particularly striking example of the latter is mint, which makes multiple math crates interoperate, even when they use different conventions for defining vector types, etc.

SIMD

I believe SIMD libraries are still in the “research” phase. There are multiple wrapper libraries, each offering a different vision and different set of tradeoffs: simdeez, packed_simd, faster, and of course my own fearless_simd. The tradeoffs are not straightforward; some users will need all the raw performance they can get, and are willing to go extremes to use the best instructions for specific processors. Others will value portability and safety.

One of the tricky parts of SIMD is that more work needs to be done in the compiler, not least to land AVX-512 and non-x86 SIMD architectures. It’s also likely that some language changes are needed for wrapper libraries to provide the best experience; for example, inlining and cfg(target_feature = ...) interact poorly. This is another research question, in my opinion. Just how far can we go with no additional language support, and which features will lead to a dramatically better experience?

Audio

There are usable low-level audio crates, especially cpal. But there are performance problems (it doesn’t always use the real-time thread) and likely missing features. We need to figure out a good path, either improving cpal or developing a new crate that fixes specific problems. We’re exploring a bunch of possibilities, among other things taking a close look at C++ libraries such as RtAudio that solve these problems well.

For higher level audio synthesis, I have big plans for synthesize-rs. That won’t be for everybody, but I think will be a good basis for a wide range of synthesis techniques and audio effects. That feels like it’s currently somewhere between research and development phases.

To follow this work, check out the #synthesizer stream on our Zulip chat. I gave a talk in November, which I plan to rework into blog form soon (I have a fairly large queue of blog posts I intend to write, lately have been focused on other things).

GUI

Graphical user interfaces are a particular weak point for Rust right now, and I see the topic pop up quite a bit in Rust 2019 posts.

I personally feel we should consider Rust GUI in the “research” phase. There are a lot of alternative approaches, and there is not universal consensus on what’s actually going to be best. How much of the system’s infrastructure should be used for 2D graphics and other UI primitives, vs implementing the entire stack ourselves? Is deployment to web (through wasm) a requirement? Should the programming experience feel “Rust-native” or should we be adapting to the conventions of a mature object-oriented GUI toolkit? Does the Rust community have the bandwidth to create a new GUI toolkit, and even if so, is it worth it?

I’ve started Druid to provide the GUI for my synthesizer and game, but also as a research project on building GUI in Rust. It represents a particular vision, choosing answers to each of the questions above, and I believe it has significant advantages. But it’s a research prototype, it would be very silly for other projects to adopt it at this stage.

There are lots of other cool GUI projects out there too. I personally feel Azul is one of the most promising, as I think WebRender is a good basis for building GUI. Another very promising project is OrbTK, which originates from Redox but is cross platform, and is fairly advanced. There are also good things to be learned from Conrod, ggez, as well as wrappers for toolkits in other languages.

It’s not surprising that much of the activity on GUI in Rust has a focus on games, and I think that’s a good thing. It’s easier to innovate in the game space, and the reasons to use mature toolkits are less urgent. But if an excellent approach to GUI emerges, I think it will be useful for a broad range of applications. Also note that Druid started out as the GUI layer in the Windows front-end for xi-editor.

Markdown

The pulldown-cmark library is pretty widely used, including for rustdoc, but is a bit stale in some regards. It hasn’t kept up with evolution of the CommonMark spec. One reason it’s gotten kinda stuck is that I have an idea for a new parsing algorithm which is better than the old one, but haven’t filled in all the details. Lately, I’ve picked that work up again, and am looking forward to shipping it. When the new_algo branch is merged into master, I think it’ll also be a good place for community contributions to continue to improve it and add new features. I have in mind full GFM compatibility, math, and maybe a few more things along those lines.

Support this work on Patreon

I’m very excited about Rust, and look forward to spending a bunch of my time and energy on improving the ecosystem (mostly by writing libraries). That said, I have a lot of potential projects pulling on me, and working on Rust infrastructure doesn’t pay directly. Ideally I need to find a structure of working that’s sustainable, even though I can live off savings for a while. The best way to vote for me putting energy into Rust infrastructure specifically is through my Patreon. I’ll interpret support at $2 (or $19 if you’re feeling particularly generous) as a request to work on the items in this post.

Thanks to everyone and the Rust community for making the language a place I love.