Stream: project leads (public)

Topic: Rust Survey 2020


XAMPPRocky (Aug 21 2020 at 17:15, on Zulip):

Hey everyone, we were discussing what potential questions and structure for the rust survey for 2020 (in #t-community/rust-survey-2020) and we wanted to ask people a couple of questions.

Josh Triplett (Aug 21 2020 at 17:42, on Zulip):

@XAMPPRocky We've seen mentions in past surveys, and around the community, of compile time as a notable factor in people's usage of Rust. I'd like to add 1-2 questions to get more information about that. Namely, "how many logical CPUs does the primary system you compile Rust on have", and some measure of "how much time do you typically spend waiting on Rust code to compile".

Josh Triplett (Aug 21 2020 at 17:42, on Zulip):

I think the answers would be useful in prioritizing various kinds of performance optimizations.

Josh Triplett (Aug 21 2020 at 17:43, on Zulip):

I also have both a personal and professional interest in the answers.

Josh Triplett (Aug 21 2020 at 17:44, on Zulip):

I've also seen, many times, discussions about minimum supported Rust versions in a theoretical sense, but often such discussions don't feature anyone who personally uses an older Rust version than the latest stable, or latest-minus-one at most (since people don't upgrade instantly).

Josh Triplett (Aug 21 2020 at 17:45, on Zulip):

We have numbers from last year that 3.1% use a previous stable release. Could we ask specifically "what leads you to use a release older than the latest or latest-but-one stable release"?

Pietro Albini (Aug 21 2020 at 17:52, on Zulip):

I'm kinda wondering if there is a correlation between using rust more and complaining less about compilation time

Pietro Albini (Aug 21 2020 at 17:52, on Zulip):

mostly because I'm getting less and less annoyed by it, but I'm not sure if it's because the compiler is getting workflow-changing faster or I'm just getting used to the slow compilation cycle :smiley:

Josh Triplett (Aug 21 2020 at 17:57, on Zulip):

I mean, I'd rather use Rust than anything else, even if it takes many times longer to compile. But I still don't want to wait on compiles. :)

Joshua Nelson (Aug 21 2020 at 21:55, on Zulip):

Josh Triplett said:

We have numbers from last year that 3.1% use a previous stable release. Could we ask specifically "what leads you to use a release older than the latest or latest-but-one stable release"?

the reason we use an old version of rust at work is because it's packaged in the debian repositories

Joshua Nelson (Aug 21 2020 at 21:55, on Zulip):

and rustup doesn't support multi-user setups https://github.com/rust-lang/rustup/issues/313#issuecomment-658802973

Joshua Nelson (Aug 21 2020 at 21:57, on Zulip):

Pietro Albini said:

I'm kinda wondering if there is a correlation between using rust more and complaining less about compilation time

I definitely think the people who are most annoyed by the times give up and leave rust sooner

Joshua Nelson (Aug 21 2020 at 21:57, on Zulip):

personally the compile times are really frustrating to me even after a year in rust

Josh Triplett (Aug 21 2020 at 22:37, on Zulip):

Joshua Nelson said:

Josh Triplett said:

We have numbers from last year that 3.1% use a previous stable release. Could we ask specifically "what leads you to use a release older than the latest or latest-but-one stable release"?

the reason we use an old version of rust at work is because it's packaged in the debian repositories

Do you use the version from Debian stable, or the version from latest Debian testing/unstable?

Josh Triplett (Aug 21 2020 at 22:39, on Zulip):

Joshua Nelson said:

and rustup doesn't support multi-user setups https://github.com/rust-lang/rustup/issues/313#issuecomment-658802973

From the discussion on that issue, it sounds like as long as you don't have any rust-toolchain files and you never change the default, a shared read-only setup would work fine. (Not ideal, obviously.)

Josh Triplett (Aug 21 2020 at 22:39, on Zulip):

Joshua Nelson said:

personally the compile times are really frustrating to me even after a year in rust

Good to know.

Lokathor (Aug 21 2020 at 23:11, on Zulip):

I very deeply care about both minimum rust version tracking and also compile time. Unfortunately, I can't always get my minimum rust version down to 1.34.

Josh Triplett (Aug 21 2020 at 23:13, on Zulip):

@Lokathor What motivates the former for you?

Lokathor (Aug 21 2020 at 23:16, on Zulip):

I consider it a general requirement for good semver practices. Unless a crate specifically only works on Nightly or something weird, it should select a minimum rust version (that's checked in CI), and stick to it. And a minimum rust version bump should be a semver break.

Joshua Nelson (Aug 21 2020 at 23:24, on Zulip):

Josh Triplett said:

Joshua Nelson said:

Josh Triplett said:

We have numbers from last year that 3.1% use a previous stable release. Could we ask specifically "what leads you to use a release older than the latest or latest-but-one stable release"?

the reason we use an old version of rust at work is because it's packaged in the debian repositories

Do you use the version from Debian stable, or the version from latest Debian testing/unstable?

Debian stable, but some of our machines are still on debian 9, so we'll have to switch to testing if bindgen starts requiring 1.40 like they've mentioned

Joshua Nelson (Aug 21 2020 at 23:25, on Zulip):

that isn't a giant deal though as long as it shares the version of rust across all users

Josh Triplett (Aug 21 2020 at 23:41, on Zulip):

Lokathor said:

I consider it a general requirement for good semver practices. Unless a crate specifically only works on Nightly or something weird, it should select a minimum rust version (that's checked in CI), and stick to it. And a minimum rust version bump should be a semver break.

I'd disagree with that last point ("latest-minus-one stable" is also a reasonable policy).

Josh Triplett (Aug 21 2020 at 23:42, on Zulip):

@Lokathor But in any case, I'm less concerned with why you want to track MSRV, and more concerned with the specific use case for needing an older version of Rust.

Lokathor (Aug 21 2020 at 23:49, on Zulip):

I would dispute "latest minus 1" or any rolling minimum version because cargo update being able to drag you forward into a version your compiler can't even build is clearly bad. So until cargo is fixed, no rolling minimum versions.

As to the why, I know of two use cases:

XAMPPRocky (Aug 21 2020 at 23:52, on Zulip):

FWIW compile times have never been an issue for me. I think something that is hard to quantify about Rust which is how much time you save by having most of your errors being caught at compile time versus chasing them down at run-time. I find the latter much more stressful and difficult to debug. Improving compile times is great but it's more like the icing on the cake. :smile:

Lokathor (Aug 21 2020 at 23:58, on Zulip):

I think we should also put a number on what's fast and what's slow. I, for example, consider slower than 10 seconds for a clean build to be a potentially bad sign, and slower than 5 seconds for an incremental build to also be a bad sign. But I also mostly work on very base crates that don't pull in deps, and i'm sure a lot of others live in some other scale.

I know that any time i update my stuff installed via "cargo install" there's 50 - 400 deps in each thing and it really is "go get a coffee" time scales.

Josh Triplett (Aug 22 2020 at 02:37, on Zulip):

@XAMPPRocky I absolutely agree that I'd rather a long compile that actually catches everything.

BatmanAoD (Kyle Strand) (Aug 22 2020 at 18:12, on Zulip):

Josh Triplett said:

XAMPPRocky I absolutely agree that I'd rather a long compile that actually catches everything.

I think there's actually a value proposition for both <fast compile, minimal checking> and <slow compile, strong checking>. I'm very opposed to the general JavaScript-y principle of "keep running whenever possible" in code that's actually deployed to users, but I think there's potential benefit for a "prototype" compiler mode (in any language, not just Rust) that does its best to run your code despite its issues. This is somewhat like the difference "release" and "debug" compile modes, except I'd want it to be maximally permissive. Ideally, it would actually be somewhat interactive: if you could fix code errors while the prototype is running (somewhat like the live-debugging mode of some IDEs), that could be an excellent way to understand the meaning of certain errors before trying to correct them.

BatmanAoD (Kyle Strand) (Aug 22 2020 at 18:12, on Zulip):

I think especially with lifetime errors, this approach could be helpful for understanding what's alive when.

BatmanAoD (Kyle Strand) (Aug 22 2020 at 18:14, on Zulip):

I think the cargo check concept of <fast but strong checking, no compile> is a really good idea for iteration, but it's probably most beneficial to people who have a somewhat "abstract" approach to programming, generally thinking of software in terms of the source code semantics rather than in terms of runtime behavior.

Joshua Nelson (Aug 22 2020 at 18:18, on Zulip):

fix code errors while the prototype is running

that sounds really amazing :smiley: I've heard rumors of a REPL based on MIRI, maybe that could fit the 'keep running' interactive model?

BatmanAoD (Kyle Strand) (Aug 22 2020 at 18:19, on Zulip):

One danger of adding a "minimal checking" mode to Rust is obviously that it could encourage people to release software compiled in that mode, which would be... very very bad for obvious reasons. I think that if Rust had something like what I'm describing, it absolutely should not have a way to turn off the "interactive" aspect.

BatmanAoD (Kyle Strand) (Aug 22 2020 at 18:20, on Zulip):

@Joshua Nelson Yeah, this is an idea I've had kicking around in my head for a long time, but unfortunately I haven't really even fleshed it out, let alone try to build such a thing.

XAMPPRocky (Aug 22 2020 at 18:21, on Zulip):

Could we split this compile time discussion into a new topic?

BatmanAoD (Kyle Strand) (Aug 22 2020 at 18:21, on Zulip):

I do wonder how close MIRI is to that model already, though.

BatmanAoD (Kyle Strand) (Aug 22 2020 at 18:21, on Zulip):

Yeah, sorry, I meant for that to be a brief response to Josh and got carried away :embarrassed:

XAMPPRocky (Aug 22 2020 at 18:25, on Zulip):

I don't think it's a problem, more like a perfect example of why topics are useful. :smile:

Notification Bot (Aug 22 2020 at 18:31, on Zulip):

This topic was moved by simulacrum to #general > compile times

simulacrum (Aug 22 2020 at 18:31, on Zulip):

split, hopefully didn't remove too much

Last update: Jun 20 2021 at 00:00UTC