Adoption rate of different Rust versions and editions

1

Hi all,

I'm considering if I should update my crates to require version 1.31 aka Rust 2018. That made me wonder if there is any statistics on the adoption rate of different Rust versions? That would in turn tell me how many users I would affect if I start requiring Rust 2018 as a baseline.

The Rust Survey 2018 asked people which version they used, and ~75% use the current stable version, with ~55% using the nightly version:

Does anybody know of any other statistics on this?

While crates.io publish download statistics for every crate, I don't think there are numbers published for the rustup downloads? If the downloads per rustup channel is tracked, could they be made available? I think it would be an interesting signal for crate owners.

3 Likes
2

Bare rustup download statistics would be kind of useless, since the most likely cases I know of for someone being on an old Rust version would be:

  • Users of distro packages like on Debian.
  • Users who bake some arbitrary version of Rust into a bigger package, like an AMI or a Docker image.
  • Users who are totally air-gapped and have to copy files through flash drives to get them onto their systems.

The first and last group are avoiding rustup entirely. The second group would invoke rustup once, during the build process, and then never touch it again.

5 Likes
3

According to my data collected for crates.rs there are:

  • 4005 crates requiring 2018 edition (either directly, or via any dependency)
  • 19674 crates using 2015 edition

So that's about 17% of crates (it's about the same if I exclude crates with very few downloads).

3 Likes
4

Interesting stat! However, if that includes dev-dependencies, please do try without, as those are not necessarily "infectious" in the same way.

5

60 e2015 crates have a e2018 dev dependency. There are 229 e2015 crates that have runtime or build-time required or default-enabled e2018 dependency.

2 Likes
6

Thanks @notriddle, that is an excellent point! I had imagined that it would be useful to see how the use of, say, Rust 1.23 drops off over time, but you're completely right that this doesn't tell us much about the number of times that version is used.

Wow, thanks for compiling these numbers. Do you also have a list available with the most downloaded crates that need Rust 2018?

7

Top 100 by recent downloads:

foreign-types, im-rc, datafrog, polonius-engine, cargo, cursive, askama_escape, fuchsia-cprng, futures-select-macro-preview, im, bimap, enum-map, specs, lsp-codec, ctr, shrev, sentry, gfx_glyph, sentry-types, arya, rustc_tools_util, x86_64, glyph_brush, glyph_brush_layout, specs-hierarchy, cargo-tarpaulin, fluent, cargo-deb, sized-chunks, cortex-m, rustfmt-nightly, yamux, cargo_toml, packed_simd, named_pipe, aligned, amq-protocol-codegen, amq-protocol, envy, dunce, rustsec, platforms, target-lexicon, model, enum-iterator, libp2p, libp2p-core, wasm-bindgen-cli-support, rocket_cors, amethyst_renderer, libp2p-core-derive, lapin-async, lapin-futures, libp2p-identify, libp2p-kad, gstreamer-audio, cargo-vendor, bitvec, cranelift-codegen, wasm-bindgen-cli, cranelift-entity, smart_open, amethyst, libp2p-ping, cranelift-frontend, read_input, cranelift-codegen-meta, libp2p-secio, cranelift-bforest, libp2p-ratelimit, libp2p-mplex, libp2p-uds, libp2p-tcp, libp2p-plaintext, libp2p-floodsub, libp2p-dns, cargo-audit, libp2p-yamux, libp2p-mdns, lambda_runtime_client, cranelift-wasm, wasm-bindgen-wasm-interpreter, cranelift-native, bootloader, wasm-bindgen-threads-xform, amethyst_assets, amethyst_input, amethyst_core, amethyst_audio, amethyst_ui, amethyst_utils, amethyst_animation, amethyst_controls, amethyst_locale, askama_derive, rw-stream-sink, sentry-actix, askama, parity-multiaddr, askama_shared

3 Likes
8

See also this recent Reddit thread about adopting new Rust versions:

1 Like
9

Awesome link in that thread:

1 Like
10

But perhaps a bit misleading…

Yes, rust itself is a couple of versions behind for arch, but rustup is current:

Also the git packages in the AUR are marked as massively dated, but the fact is, that the AUR doesn't bump the version on git (or any VCS) built packages, unless the actual build manifest needs to change.

But yes, it gives an estimate about what we have to expect to be available in the wild.

11

Good data, but it doesn't suggest what Rust versions people have.

Going by that data, I think you should feel entirely comfortable with using Rust 2018. 1.31 is not even the current stable version (1.33 is) and 75% said they use the current stable so numbers are likely even higher for 1.31. There's also the network effect of requiring later compiler versions. By doing so, you contribute towards a better language overall because if everyone gets super conservative, the language & library teams are doing work for no benefit.

3 Likes
12

Good data, but it doesn’t suggest what Rust versions people have.

Well, if we assume perfectly spherical cows, and that people install crates uniformly at random: average crate has 3.15 dependencies, which gives 44% chance of having to use e2018-capable compiler :slight_smile:

1 Like
13

@kornel Having to use a Rust 2018 capable compiler is not the same as being able to. In particular, someone can use 1.31 but only have Rust 2015 crates.

1 Like
14

Re Debian packages:

  • stable Rust releases are uploaded into "unstable" within a few days of release
  • they graduate to "testing" usually(*) after 2 weeks.
  • Debian "stable" is whatever was current at the time of that Debian release.

Most active developer environments run "testing", so the rust/cargo versions available through Debian packages will be about 2 weeks behind official Rust releases (plus whatever delay until the user runs apt-get upgrade again).

(*) "Usually". The rust toolchain is unusually difficult to get to work across all supported Debian architectures, especially considering the rapid pace of code churn. So semi-often there's a slight delay while a bug (or just a broken test) is fixed in an architecture that upstream Rust doesn't test.

2 Likes