summaryrefslogtreecommitdiff
path: root/posts/rust-2020.mdwn
blob: 2e8a37ecdd31f6e8982eeee97e210aad34b0ad51 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
[[!meta title="Rust 2020"]]
[[!meta author="Daniel Silverstone"]]
[[!meta date="2019-11-26 20:00:00"]]
[[!tag draft]]

As in recent years, there was a [call for posts][rust2020] 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.

[rust2020]: https://blog.rust-lang.org/2019/10/29/A-call-for-blogs-2020.html

---

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][aoc2016] in it,
completed that, and then promptly did nothing with Rust except read blogs and
reddit for a year.  Then I went and did [Advent of Code 2017][aoc2017] in Rust
and reminded myself of why I enjoyed the language.  This time I decided I'd do
something useful in it and wrote a testing tool which I have used since.  I
wrote bits and bobs through 2018, but still failed to do anything major with
Rust until once again, December rolled around and I did [Advent of Code
2018][aoc2018] in Rust, learning an awful 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.

[aoc2016]: https://adventofcode.com/2016
[aoc2017]: https://adventofcode.com/2017
[aoc2018]: https://adventofcode.com/2018

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][pull1578], I then filed others, and on the 18th
Of December 2018, [my PR to update rustup to the 2018 edition][pull1583] was
merged and thus began my time as a `rustup` contributor.

[pull1578]: https://github.com/rust-lang/rustup/pull/1578
[pull1583]: https://github.com/rust-lang/rustup/pull/1583

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
helping on `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
welcome.

---

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…

### Getting Rust

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 `rls`
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,
despite `rustup` being there.

[Debian]: https://www.debian.org/
[NixOS]: https://nixos.org/
[Arch Linux]: https://www.archlinux.org/

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.

### Trust ergonomics

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 `curl |
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][boatsrfc] which is still in progress.  However we need to
extend that to the Rust toolchains, and to the installer (`rustup`) itself
too, in order to be more usable to more people.

[boatsrfc]: https://github.com/withoutboats/rfcs/blob/816968dd5f692dc128fa1b87e64cddbf3485fc7c/text/0000-signing-registry-commits.md

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
follow the `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 [`rand`][], [`syn`][],
[`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, `syn` is already in its `1.0`
series and yet via various pathways, `rustup` ends up depending on `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.

[`rand`]: https://crates.io/crates/rand
[`syn`]: https://crates.io/crates/syn
[`quote`]: https://crates.io/crates/quote

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
responsible for `rustup` and it's quite possibly the most `UNIX`y part of
the Rust ecosystem, and yet is pretty much mandatory for every Windows user.

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.

### Shared libraries

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.