As in recent years, there was a call for posts about Rust in 2020. I've been sitting on my response for quite a few weeks because every time I try to write this, I think of other things I want to say, or a new "theme" I want to propose for Rust in 2020.
First, some history about myself in the Rust community -- I started learning Rust a few years ago, had a go at Advent Of Code 2016 in it, completed that, wrote a testing tool in Rust, and then promptly did nothing with Rust except read blogs and reddit for a year. Then I went and did Advent of Code 2017 in Rust and reminded myself of why I enjoyed the language. This time I decided I'd do more with Rust and started playing around. I wrote bits and bobs through 2018, but still failed to do anything major until once again, December rolled around and I did Advent of Code 2018 in Rust, learning an awful lot about procedural macros and other useful things. This was the time of the 2018 Rust edition which also spurred me on to do more useful stuff.
While I was enjoying the fun coding through December, I sat down and decided
how I wanted 2019 to play out. I was very aware that I was failing a number of
open source communities I was part of, and so I resolved (a) to be a net
positive influence on any community I remained active in, and (b) to
specifically work to be part of the wider Rust community because I wanted to
give back to a community which had been welcoming to me and given me so much
joy in coding. I went looking for ways to contribute, did a small patch to the
panic wording as per an open issue, and then looked at the developer tools
surrounding Rust. I noted that
rustup needed some TLC and so I ended up
filing my first PR on rustup, I then filed others, and on the 18th
Of December 2018, my PR to update rustup to the 2018 edition was
merged and thus began my time as a
Fast-forward to mid-January 2019 and the Rustup working group is established
and I was invited to be a member of that. Zoom on to mid-May and I'm asked to
take on the mantle of leading the working group, and from there I ended up also
rustdoc and various other bits and bobs. I've ended up quite
involved in an exciting and interesting community which has always made me feel
With that potted history given, I hope that you can appreciate where I'm coming from when I say that the one word which keeps coming up when I think about what the Rust community needs to look toward next, the "buzzword" for Rust 2020 that I'd propose, is "Inclusivity". Interestingly I don't mean in terms of being inclusive and welcoming to LGBT people, or women, or any number of other "minority" or "marginal" groups which online communities often find themselves needing to work to include; because Rust already is exceedingly welcoming to such groups -- I've never had so much as a misplaced blink when I say "my husband" in a Rust setting, and that has been so nice. What I mean is that in order to be more widely used, the Rust community needs to look toward ensuring that it can be included into other things.
I'll list the major topic areas I'm thinking of, from most-likely to least-likely to get somewhere concrete in the coming year. At least from my perspective. I'd love to be proven wrong about some of the later items…
As a Debian developer I have long enjoyed the stability and reliability of
the Debian operating system, the software supplied by it, and the trust I feel
I can place in it as a software distribution point. Recently Debian started to
include Rust in releases, and that is incredibly important I feel. However the
Rust community expects things like
rustup to "just work" and that means that
if someone is using a Debian provided toolchain, and ask how to get
working then the instruction
rustup component add rls simply won't work
properly for them. This gets even more interesting when you look at NixOS,
or any Arch Linux derivative, because they distribute
rustup but it
cannot update it self, so other behaviours the community expects don't work,
rustup being there.
Getting the Rust toolchain in the first place is a critical part of the flow of getting someone into Rust, and making that possible in a way which fits into our target user's worldview and meets their expectations for acquisition of tooling is critical to reducing the onboarding friction. So my first point of inclusivity is, amusingly, on me to spearhead and work out how to make it happen; though I'd welcome anyone wanting to make suggestions on how to make it work nicely.
One thing which holds a lot of people back from Rust is being able to acquire
it in a manner they already feel they can trust. This follows on from the
point above because trust has to start somewhere, and people already trust the
operating system they're running, at least to some extent. When you say that
the recommended method for acquiring Rust toolchains starts with a
bash people have recoiled in horror. I think that the Rust project needs to
start to come up with ways to improve the level of trust people can put in the
tooling they acquire. Some of this has begun already, with a proposal to sign
the crates index which is still in progress. However we need to
extend that to the Rust toolchains, and to the installer (
too, in order to be more usable to more people.
This kind of thing is something I am actively interested in, and I hope to be
able to announce something in the new year at some point. Those of you who
rustup issues will have seen me discussing OpenPGP signatures on
toolchains, and that will certainly form part of an infrastructure which people
outside of the project can build trust upon. Maybe one day we'll get Debian to
sign something which Debian users can use to trust a
rustup that they
downloaded in the
curl | bash method which we know to be one of the most
accepted of "current" approaches to getting non-distro-packaged software.
Reliable, deduplicated, dependencies
One criticism which is levelled at the crates ecosystem an awful lot in my
earshot, and which I doubt anyone would really argue with, is that it feels
very immature -- the preponderance of
0.x version numbers for "primary"
crates is something that has been worked on, but is still a huge problem. In
part this is because the community is so confident with the semantic versioning
we all take care of, but also because there's an amount of release anxiety
manifesting. What's worse than this though is the way that we end up with
sets of incompatible dependency chains on many of these "primary" crates. It
is not uncommon to end up with multiple version of
quote, or others in your dependency tree. Not all of
that is the fault of the authors of those libraries either, but because other
crates are not yet up-to-date with changes in them. For example,
already in its
1.0 series and yet via various pathways,
rustup ends up
0.15 as well.
In order to be more includible into distributions such as Debian, it's critical that the Rust community as a whole looks to address this kind of thing. It seems odd to say that "gardening" your library's dependencies can be a way to lead to being more includible into other things, to enhance "inclusivity" as I'm choosing to define it for this post, but it is indeed one pathway.
An end-goal of this is that a majority of tools ought to be buildable with a unified singular set of library crate versions if they are going to be usefully included into a distribution.
Making Windows feel Tier One
The Windows platform is considered Tier One by the Rust project. This means
that we care, as a project, that Rust and the developer tools all work nicely
on the platform. Yet it's abundantly clear that the majority of the tools
developers use either a Linux or MacOS X system. As such, concerns that
Windows brings due to its non-POSIX nature are often either considered
unimportant or simply ignored. I am very guilty of this myself. I am
rustup and it's quite possibly the most
UNIXy part of
the Rust ecosystem, and yet is pretty much mandatory for every Windows user.
Another example of this is the
rust-docs component which contains tens
of thousands of small files which causes Windows based anti-virus systems
significant indigestion. We ended up adding a "minimal" profile to
so that Windows users could skip installing the docs, but that's not great as
a long-term solution.
As Rust tries to get included into more companies, this friction is going to be more and more important to resolve. A huge number of companies expect their developers to use Windows desktops, even when they're working on Linux hosted software, and making sure that's first-class will be really important as the number of users who have to use Rust (rather than those who choose to) increases.
I'm sure there are things we can do here, but I'm really going to need help to find ways to make this happen, I'm not a Windows person, but I'm very open to finding ways to improve matters on that platform.
This is something I'm not sure that we can do anything particularly concrete on
in the coming year, but is part of Rust's story which really needs a lot of
thought. It's incredibly hard to provide a shared object which can be
versioned at all similarly to how
SONAME versioning currently works, due to
the complexity of the types, and the instability of Rust's ABI. However at
least some thought needs to be put into how we might begin to resolve this as
it's yet another potential blocker to being included into distributions because
it makes the security story for Rust programs so different from other languages
which can and do make use of more traditional shared objects.
In summary, for me, for 2020, Rust's already very inclusive approach to its community needs to turn outward and look for ways to increase the chances that it can be included into other projects such as Linux distributions. I see this as increasing the inclusivity of the project by including into our worldview the particular needs of these other projects and communities and ensuring that by treating them as first-class consumers of Rust, we can become first-class members of their projects and communities as well.