Production user research summary

[gmjosack]

I’m currently working to make Rust production ready at work on top of cargo but there are some definite pain points. The main one I’m running up against is having build boxes without internet access. Even if they did we wouldn’t want to depend on crates.io for production builds+deployments.

It’s easy enough to mirror the crates.io-index repo and also have a mirror for the package files but the architecture adds some complication. The fact that the dl url has to be specified as part of the index’s config.json means that I have to keep an internal fork of the crates.io-index just to modify the config.json and worry about future merge conflicts if/when something in that file changes.

I would love to see the ability to override the index’s dl url from the .cargo/config as this would simplify basic mirroring. I haven’t had the need to override api yet so I can’t say if there’d be value in allowing an option to override the index for that as well but it might be useful to others.

Edit: Opened issue on the cargo repo here: https://github.com/rust-lang/cargo/issues/1923

[phildawes]

Thanks for doing this @brson, always good to get feedback.

Racer is still too slow to be practical

This surprises me (racer author). I would have thought the complaint would be ‘racer is not complete enough’ rather than performance. Performance on a completion on my linux laptop is ~100ms - i.e. the same sort of speed as intellij.

Maybe there’s some environment related performance issue I’m missing - e.g. perhaps racer is really slow on windows or when used with a particular editor or something. Did you get a feel on what their environment was like?

Thanks!

[skade]

Since I’m alone, do this on my spare time, and don’t raise any money from it, I don’t have enough weight to be in these meetings (it’s not a complaint, I don’t have any problem with this).

I think this is a misconception. “production users” in this case was meant in the sense of “people that build projects with the intention of releasing things using Rust”. It’s very loosely defined. I wasn’t involved in the planning, but to my impression, the group of people present was more defined by people the core team knew were using Rust in such a fashion/intention. Making money is also no criterion. It’s not meant as an exclusionary attribute. It’s just the meeting where advanced issues that might pop up in actual project use later are discussed, as opposed to meetings were problems with beginner teaching are discussed.

This won’t be the last of such meetings and your feedback is very valuable and welcome. Would you mind if I get you in touch with the core team?

Florian (Rust community team)

[tomaka]

This won’t be the last of such meetings and your feedback is very valuable and welcome. Would you mind if I get you in touch with the core team?

Sure!

[thijsc]

We’re working on multiple projects using Rust at https://appsignal.com, ping me at thijs at appsignal.com if you would like us to join next time.

[nikomatsakis]

We’ve heard some anecdotes that there is no mode to build Rust that is both reasonably fast to build (ala --opt-level=0) and also fast enough to run.

It’s worth mentioning that @alexcrichton did some experiments and found that -O1 with codegen-units had almost the same compile time as -O0 but almost the same performance as -O3. We should make this an easier option to choose, I think.

[tomaka]

It’s worth mentioning that @alexcrichton did some experiments and found that -O1 with codegen-units had almost the same compile time as -O0 but almost the same performance as -O3. We should make this an easier option to choose, I think.

The image library definitely runs much faster with -O3 than with -O1.

With the code I’m working on, loading the assets at runtime takes ~10.5 seconds with -O1 and ~1 second with -O3

[nikomatsakis]

@tomaka interesting. I didn’t mean to imply we should stop using -O3, however, just that for many users it may be a useful choice.

[excaliburHisSheath]

I can’t claim to have the same depth of experience as @tomaka, but I’m in the same spot of wanting to build and release games using Rust. If there’s anything I can do to contribute let me know.

[aturon]

-O1 with codegen-units had almost the same compile time as -O0 but almost the same performance as -O3

Did you mean the same performance as -O1?

[nikomatsakis]

@aturon no, I meant what I wrote. Keep in mind, this test was just cargo, afaik, so it’s unclear how representative it is.

[aturon]

@aturon no, I meant what I wrote. Keep in mind, this test was just cargo, afaik, so it’s unclear how representative it is.

FWIW, I just checked with @alexcrichton and he says it’s about 3-5x faster than -O0, which is still much slower than -O3.

[nikomatsakis]

FWIW, I just checked with @alexcrichton and he says it’s about 3-5x faster than -O0, which is still much slower than -O3.

OK, yes I misremembered. Here were the results @alexcrichton sent me :

• O0 - 1:01 build time, 1.5s runtime
• O1 - 1:09 build time, 0.5s runtime
• O3 - 2:13 build time, 0.17s runtime

still, much closer to -O3 than -O0.

[brson]

@tomaka Thank you for the feedback. The SipHasher issue is a persistent gotcha, and seemingly so easy to solve (both by having a weaker hash available and by improving our strong hash).

@achanda I’d love somebody to work on this! My present opinion is that Crater should expose information via API for crates.io to use, about both observed platform and channel compatibility. Crater seems the best option because the infrastructure is set up (though it’s a mess and doesn’t provide all the stuff we need) and will be maintained as long as I work on Rust. I’m interested in hearing other designs though.

@gmjosack Thank you for the feedback about Cargo. I totally agree this issue of running Cargo independently from crates.io (and the network at all) are major blockers for a lot of use cases (including Gecko’s). Personally, I think it’s important enough that it should be on my shortlist of ‘showstoppers’ that need attention soon. cc @larsberg @alexcrichton.

[larsberg]

The Cargo-specific issues I can find from Gecko (compiled from bugzilla threads and the Portland meeting notes):

• Desire to compile multiple toplevel static libs concurrently, but Cargo doesn’t support concurrent access.
• Want to unroll all of the dependency tree in-tree with manual upgrade / pick-up of those external deps (called “vendoring” in FFOS parlance). This doesn’t mesh well with Cargo’s desire to own the place where dependencies live unless you .cargo/config paths override them all.
• Absolutely totally unacceptable to go online “automatically” during a build. Should be an error if something needs to be updated/refreshed from the network.
• Artifact caching support & deterministic builds via it (though not required at day 1).

[nrc]

This (internet access for Cargo) is also a bit of a show-stopper for some universities which have restricted internet access (the student I’m supervising can’t use Cargo at uni, for example).

[achanda]

@brson @alexcrichton I will start another thread on the platforms/rustc version thing.

Re: prod users not using cargo, is this because there are no guides on running an internal version of the crates.io (or the index)? I’m not sure if that’s even possible. If not, we should consider expanding on it. I’m thinking something like the private docker registry.

[brson]

@thijsc Thanks for speaking up! I’m making a note to myself to include you next time we do something like this.

[gmjosack]

Re: prod users not using cargo, is this because there are no guides on running an internal version of the crates.io (or the index)? I’m not sure if that’s even possible. If not, we should consider expanding on it.

I have a draft of such a post that I need to finish up, though I’ve been busy with a “Hack Week” at work this week so haven’t been able to finish it. Hopefully should have a guide on setting up an internal mirror sometime this weekend.

[achanda]

Awesome! Looking forward to it.