Draft of my Rust 2020 post

1 files changed, 196 insertions, 0 deletions

diff --git a/posts/rust-2020.mdwn b/posts/rust-2020.mdwn
new file mode 100644
index 0000000..2e8a37e
--- /dev/null
+++ b/posts/rust-2020.mdwn
@@ -0,0 +1,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.