diff options
author | Daniel Silverstone <dsilvers@digital-scurf.org> | 2019-11-25 21:59:55 +0000 |
---|---|---|
committer | Daniel Silverstone <dsilvers@digital-scurf.org> | 2019-11-25 21:59:55 +0000 |
commit | 69a62470c311dcb9068c4fa9ac4cc54ddc50764b (patch) | |
tree | 95afa06ebb176b0177e9fb07a582c3ffddda796f | |
parent | 7bd1d6b86773cc987c10f67b2500fc22392d3746 (diff) | |
download | blog-69a62470c311dcb9068c4fa9ac4cc54ddc50764b.tar.bz2 |
Draft of my Rust 2020 post
-rw-r--r-- | posts/rust-2020.mdwn | 196 |
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. |