Production user research summary

I also don’t have too too many specifics, but I also got the impression that a number of production users were avoiding Cargo for the time being. From what I could tell, much of this stems from a “let’s build Rust exactly like C/C++” mindset. The model for building Rust code and then integrating into another application is different enough that it doesn’t seem to play well with existing build systems all the time.

That being said I’m also unaware of any precise concerns about integrating Cargo other than “that may not be trivial”

Perhaps we could automate this by making crater work on windows and then testing all the crates on and putting badges on each crate indicating which platforms and which versions of rust it builds with.


I’m interested in any news on a database abstraction API. I maintain some sqlite3 bindings and I’ve studied sfackler’s postgres bindings. I’m subscribed to and I’d be interested in a real-time brainstorming session.

(I guess I could add a link in the other direction…)

I’d appreciate links to tracked issues corresponding to other issues mentioned in this article so we can monitor progress.

Cross-posting my comment from reddit:

Thanks @brson for organizing this whole thing, as well as painstakingly re-reading and summarizing the minutes. I really enjoyed the calls!

From the point of view of the core team, it’s vital to build connections to people using Rust in diverse contexts and with diverse backgrounds. These perspectives help us keep in touch with pain points when using Rust differently than we do, and to stay grounded in real-world use-cases. That in turn helps focus our efforts to improve the language, tooling, documentation, and ecosystem.

We collect this feedback in a wide variety of ways, from keeping up with this subreddit and our discourse forums, to attending meetups and conferences, to visiting companies interested in Rust. In this particular case, we wanted to solicit feedback from a range of people trying out Rust in a more “production” environment, loosely defined. We wanted to hear about the challenges of using Rust in existing organizations, integrating with large existing products, and in on-ramping new engineers, in addition to the general pain points mentioned above. It was also a chance for users to get to know one another, since each video call had several different organizations represented.

For me personally, it was very beneficial to have several hours of "immersion," hearing directly about people’s experience putting Rust to work, to get a real sense of how things are feeling. It’s hard to get that data any other way.

By sharing this data publicly (the full transcripts are available in addition to the summary), we hope both to inform the broader community of the challenges for Rust in production today, and also to provide a kind of “experience report” for people considering adopting Rust in their own organization.

Finally, I want to emphasize that this is one set of data points among many that the core team pays attention to. We’ve also been talking about holding an open “town hall” kind of call, though the logistics there are much harder to manage. If you have further ideas about how to gather feedback in a high-bandwidth way, I’d love to hear them!

This is super interesting. Regarding the lack of error handling docs, I’d been meaning to translate @burntsushi’s epic error handling set into a series of rustbyexample examples but I haven’t gotten to it yet (aside from @steveklabnik planning to import them into the regular docs sometime).

Regarding crate library docs, it’s tricky. Even crates which seem to have good examples such as regex with extensive docs on the front page lack structure aside from the what the library provides with sub-headers. For example, every wikipedia page in existence has a table of contents but regex does not. For something complicated, it’s nice to get an overview but that’s tricky with the docs.

One thing that could be done is have library authors create dummy modules strictly for dividing up complex topics into simpler topics (I’ve never seen anyone do it though)? For regex it would be useful to be able to click and go directly to say “repetition” as opposed to say “capturing” sections.

Aside from that, browsing an unknown lib is tricky. The most relevant post I’ve seen regarding that is this reddit post (maybe it’d be useful to people). It also has listed an example of how someone might browse an unknown library (it basically is almost like clicking things at random until you get a feel for it. Hardly great I guess).

I’d be super interested in seeing how the lib docs might be streamlined for the future. Really useful stuff.

[EDIT] Not suggesting dummy docs should be used, though with better support (maybe from the doc generator), more structured docs might be easier.

1 Like

As a potential future Rust indie game developper I have encountered lots of problem with Rust that nobody raised here. Off the top of my head:

  • When I profile my game the SipHasher is always in the top 3 of the functions that eat the most CPU. Saying that it consumes a lot of CPU would be an understatement. It consumes a ton of CPU.
  • Lack of write-only slices (my frames per second would increase by around 50% if I was ok with passing around slices that cause segfaults if you read from them).
  • Lack of clean and easy JSON handling. Some tasks require you to be format-specific and can’t be done with a generic deserialization system.
  • Poor handling of unsized types (I have had to write this kind of code for example).
  • Really a lot of missing libraries. Not just two or three bindings to C libraries, but the whole ecosystem. In fact I have spent most of my time on this problem for the moment (glutin, glium, hlua, cpal, spine-rs, android-rs-glue, and some others).

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).

However in my opinion it’s a vicious circle. When evaluating Rust, gamedevers are probably going to notice a lot of these problems and stay away from it. And consequently you won’t find any gamedev production user that will tell you what’s missing from Rust.


teach to report on the channel/platform compatibity of crates.

I started an issue on the cargo project on something similar I will be happy to research and implement this.

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 for production builds+deployments.

It’s easy enough to mirror the 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 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:


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?


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)



1 Like

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

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

@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.

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.

Did you mean the same performance as -O1?

@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.

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.