Rust and 2020

This is my answer to this year’s Call for blogs and contains my view of what would most benefit Rust to be invested in during the next year.

In general I tend to be conservative about adding things to the language and want to push as much „downstream“ ‒ it’s better to add something to the standard library (or core, if applicable) than directly into the language ‒ a new function is better than new keyword or operator. A new crate is better than a lot of new stuff in the standard library. My view here reflects that.

Balancing efforts

Recently, async/await landed as a MVP. That is a great feature to have. However, I feel like this took a lot of effort and large part of the time people had for improving Rust, to the extend of pushing other things to the background. It definitely made sense for the MVP, as the feature is both important and was long awaited.

But now it’s here, I think the priority of follow-up work on async/await might get a bit lower (as the gain is also a bit lower) and let other features have their chance too. I don’t argue for completely setting the async story aside, but giving it smaller percentage of the available resources would IMO make sense. After all, not all workloads need async (I’d even say it’s the reverse, that most don’t and even in applications that do need async most of the code is synchronous anyway).

Flushing the pipelines

I work with Rust for several years. The language is great, the tooling is superb, but I have one growing uneasy feeling too. There are several features that are almost ready, but not there yet. They are in this state for a long time.

I remember const generics was something that was talked about when I started with Rust, more than 3 years ago. It would really be useful, but it still can’t be used on stable.

As another example, almost than 2 years ago I’ve played with these f32x2 SIMD vector types. I don’t remember what the name of the crate was back then, since these appeared in several since then. I’ve played with faster some time later. I was really impressed by how much difference it could make and how easy it was to use and was looking for yet another killer feature of Rust (it would basically make Rust the only language where SIMD was accessible to mortals). It looked to be just around the corder back then.

Two years later, I’m still looking forward, but with somewhat less hope it’ll happen soon. I understand there are still things to design. How will the methods to do a horizontal sum on a vector be named? How will the language support having the same function compiled for different CPU capabilities and choose at runtime? Nevertheless, there’s an obvious MVP for such vectors. It’s clear what the operator + on these do and even without dynamic dispatch the compiler can generate code using just the instructions available for the whole platform. Is sse2 the common denominator of the whole x86_64? I could still supply compilation parameters to enable others for the whole program in case I have a fleet of compute servers all with the same CPUs. And even without any vector instructions, the compiler would still have more knowledge about the structure of the program and more room to optimize. Or at least the code would be forward-compatible and ready.

I think I could find more examples. But my intention is not to complain. My intention here is to point out we don’t need new ideas what to add to the language. There are many in the pipeline, with a lot work already done. Furthermore, we as the users already tasted how useful these are and at least I will always prefer to get a feature I’ve already tried on nightly than get a promise of some vague idea of a different one. It would be nice if new features could enter the beginning of the pipeline only if there was enough resources to see it through. Besides, adding new features makes the language even more complex then it is now, which is another argument why not putting things into the beginning of the pipeline might be a good idea.

Libraries

Rust is not just the language. Any language is only useful if it has useful libraries and with Rust’s lean standard library one has to rely on bunch of others. There’s certainly a lot of stuff to choose from on crates.io.

But I also have somewhat uneasy feeling about the ecosystem. I know it’s hard thing to ask for, having better and better maintained libraries, especially because most of these are outside of the control of the core Rust project (I’m not specifically talking about the core team itself, I’m using it in a looser sense). I’m not sure what specific actions I’d want to propose here except maybe to shift some amount of resources away from the rust-lang/rust repository itself to the libraries around it or to some kind of help or guidance work for the ecosystem.

To clarify what I mean about the uneasy feeling. If I look at the libraries I use, a lot of them ‒ including some that should be considered kind of core libraries for most purposes ‒ is in their 0.X versions. Rust itself is stable for 4 years, yet the crates for logging (log) or random number generation (rand) are not. I know the crates are of a very high quality and my code won’t break by itself because I can always stick to the older version so from technical point of view this doesn’t really matter. But a crate going to 1.0 is some kind of declaration, a message being sent out, that the crate is ready to be used. I believe these crates are ready to be used, but newcomers may get a different feeling.

I know I’m guilty of the 0x-titis as well with the crates I maintain. I hope to make at least some of them 1.0 over the next year. On the other hand, none of my crates is that important to the ecosystem. I believe other maintainers should consider doing so too. But maybe it would push the effort forward if the important crates (often maintained by „The Rust Project Developers“) led by example here? There was also the API guidelines effort which somehow lost its steam since it was initiated. Or maybe there’s some other thing that could be done to make more crates 1.0.

The other part of my uneasy feeling is about unmaintained crates. Let’s do an experiment. Pick a project that is not really small, something that has a month of development on it at least. But not rustc itself or Firefox. Go over the dependency tree and see how many of the crates there had the last release more than a year ago and the git repository has open pull requests the maintainer didn’t act on in any way in at least 3 months. My guess is you’ll find more than one and that you’ll be surprised about it, because that crate looks just great and so nice to use or the name looks so important that it possibly couldn’t be unmaintained. If you look for crates that have just one maintainer (who might lose interest or change jobs or get kids or whatever) the numbers will definitely be even higher.

I won’t pick any specific crates here. For one reason, I’m pretty sure each of us has a different set of favourite unmaintained crates. For another, I don’t want to shame the maintainers. I believe they did a great job and should be thanked for what they did, because they most probably invested their free time and now we have the great crates they wrote. The fact they no longer can invest the time is probably not their fault and even if it was, we don’t have any right to their free time.

Nevertheless, the problem exists. There are orphaned crates (or semi-orphaned, I’ve seen some maintainers to awaken after a time of inactivity) and it would be a pity to lose them. I don’t know how to help here, but it would be great if there was some kind of community-wide discussion what to do with it. I know there were some attempts to initiate such discussion, but I’m afraid they lost traction. Maybe, if they were backed up somehow semi-officially by one of the Teams, the discussion would have a better visibility, but I don’t know.

On the other hand, handing maintainer rights to just anyone who asks for them doesn’t sound right either, there’s the matter of trust and maybe some kind of reluctance to give up the exclusive control of the crate (yes, I’m talking from my own point of view here). Besides, does it ever happen someone comes and says they’d like to help you maintain your crate?

Closing thoughts

Sometimes I tend to sound a bit pessimistic. I’m afraid this might have happened here. However I don’t mean to. I want to point out potential problems as I see them before they turn into big problems.

Even with these problems I do believe Rust has a good future, it is heading in the right direction and even with some small problems there’s enough advantages to the language that they just plain out outweigh them. But the good parts don’t need fixing 😇 and the blog post should be about things I think would be the best place to invest resources improving.