The beginning of making Rustup concurrent

The beginning of making Rustup concurrent

Rustup is the official toolchain installer and version manager for the Rust programming language. As of now, the implementation of Rustup, processes operations sequentially, downloading components one at a time and performing both extractions and installations, in order. As one may quickly realize, this approach does not fully leverage the capabilities of modern hardware, particularly on systems with multi-core processors and high-bandwidth connections (common case for CI environments). A potential solution is to introduce concurrency into the implementation, enabling parallel processing of these tasks to better utilize system resources, leading to a more performant Rustup.

This is the purpose of my Google Summer of code (GSoC). In the summer of 2025, mentored by rami3l, which I am profusely grateful, I am tackling the task of speeding up Rustup’s current implementation.

A hands-on onboarding process

To make my onboarding process more dynamic, I have decided to tackle an open issue. Although one may consider this a trivial issue, it was a great starting point, allowing me to ease my way inside the Rust community. Interacting with the community to see my patch upstreamed was a great experience as I got to know more about the review process and what do I need to pay attention in my next patches.

While tackling this issue we have come to realize that the problem was not exclusively related to rustup show, but also influenced rustup components list and rustup target list. As such, I have worked on creating another PR to follow up on the prior work and not leave any loose ends.

Plans for the near future

After submitting this patches, it is time to close the chapter of what was a nice community bonding period, and start to get familiar with the concurrent part of the codebase and beginning to make Rustup concurrent. To do this, I will now focus my attention on a old issue, hoping to see my first performance gains.