Swatinem Blog Resume

Rust 2021

Quality, frictionless tooling

— 7 min

# TLDR

’Tis the planning season for Rust 2021 already, and as suggested, I will start with a very short list of bullet points:

# A Big Thank You!

I have actually already written about my wishlist for Rust tooling a few month ago, and like always, things have changed, and I have learned a lot.

Let me start off that I am super happy where Rust and the ecosystem are moving. rust-analyzer has been a major success and is a great productivity booster! It is also test-driving chalk, which is supposed to become the new trait solver in Rust hopefully soon. It is already working amazingly well in my IDE, as I can get type hints and hover information in cases where the main Rust compiler still wants me to manually type-annotate things.

Also, another project that I am super excited about and that gets a lot less publicity than it deserves is precise source-based code coverage support built into the compiler. I only know about this because I regularly scan through the list of PRs to the compiler. This definitely needs more marketing around it! And of course a way to easily use it. From all PRs I have seen, I would have no idea how to actually use it and maybe even combine it with codecov, etc.

Another great thing that I see was recently stabilized is intra-doc links. I am super excited about this, and am already starting to use them, as they have been available on docs.rs for quite some time.

# Where Rust needs to improve

The pain points I have right now are mostly related to tooling, and also related to having bigger more complex projects, possibly workspaces consisting of multiple crates.

I think the experience of creating and maintaining a small, simple Rust project is amazing right now. But things start to get annoying as soon as the project starts to grow.

I read that a lot of people are still complaining about long compile times. It is actually a very complex problem, and when looking into more detail, it is not really the speed of the Rust compiler that is at fault here. For me, local development, especially with rust-analyzer has been a pleasure. Things only start to fall apart when a small change means that all the interdependent crates in my workspace have to be updated, or the problem is the final linking step that is taking forever. Or the problem is not even my own machine, but rather CI that is super slow because of tons of possibly duplicated dependencies, and bad caching.

# Improving CI

Speaking of CI, my team and I have been migrating a few workspaces to GitHub Actions recently, and while we do like it in general, there are a few rough edges that should be smoother. Not all are strictly Rust problems, some are also GHA.

The primary goal of CI in my opinion is to both be as fast as possible, and as thorough as possible, while also being efficient and easy to use. Which is the first tradeoff that a developer needs to choose from. Do I want to fail fast, or rather have all the failures visible? When we fan out wide, we get a ton of different status reports, which IMO is a UI concern to begin with; but that also means more overhead. While the wall-time might be smaller, the machine-time is increased, because the common steps of checkout, toolchain, etc are run by every job.

Right now, setting up a CI pipeline is too cumbersome. There is too many decisions a developer has to do, and way too much copy-paste going on in the CI definition itself. I wish a lot of these things would just be done out of the box.

One of the big problems for CI right now, especially for big projects is caching. Caching is not free! If cargo creates a big target folder, persisting and restoring that cache can already take a considerable amount of CI time. This problem gets a lot worse because cargo does not auto-clean that cache. There are some open issues about that, but nothing much has happened in years. A lot of projects have custom solutions to deal with this, and it does not really scale. Also, should one disable incremental compilation on CI? I don’t know. I would like if there would be a simple out of the box solution that covers 90% of the usecases.

# Workspaces and Features

A bit related to CI is features. Lets start off by saying that I dislike having feature flags in the first place. They are just a pain to work with, and a pain to test, both locally and on CI. What I would like to see is official support for something like --feature-powerset of cargo-hack. Just make sure that every permutation of features works.

I saw some time ago that cargo is working on something called Features 2.0, which I hope will solve some of the pain points that I have. But so far I didn’t have the time or motivation to actually read up on what the proposed changes there are.

Another thing that I mentioned in my earlier blog post was some quality of life improvements related to workspaces. I think as a minimum, I would like to see an atomic cargo publish --all and maybe a tool to deal with versioning. As an ex-JS developer, there were a ton of tools available, but unfortunately, I was not really satisfied with any of them. I have the feeling that the Rust community as a whole creates a lot more high-quality tools, and I am hopeful that will also be the case here.

# In Closing

I do feel Rust is headed in the right direction, but there is a lot of polishing still to do. Not necessarily with the language itself, but with the tools and ecosystem around it. And its not really specific to Rust either. In a lot of ecosystems, I feel like the tasks that are not coding related are often a lot more complex than they need to be. Rust, both as a language and as an ecosystem has proved that it can solve complex problems in a nice and high quality way. I’m looking forward to seeing these problems solved as well.