Hey, team.

During the week of July 13 members of the Rust core and community teams sat down over four meetings with a number of individuals using Rust in corporate and startup environments. The intent was to establish relationships, gather requirements, and otherwise solicit feedback to inform the project roadmap.

These were amazing calls, and we were very thankful (and kind of astonished) that so many people made the so much time for us.

I’ve tried to frontload this with the most pertinent information, but the takeaway I think is: we’re doing well, our early adopters are happy with the product and happy to be a part of what we’re doing, they need some high priority improvements but none of them are surprises.

This is a summary of the minutes taken in these original etherpads:

The organizations represented here include MaidSafe and Ironworks, both writing security-oriented code; tessel.io, who are creating a SBC kit with first-class Rust support; 12Sided, who are doing high performance distributed computing; Chef, who are experimenting with Rust for new tooling; Tilde, who produce a Rails monitor called Skylight that uses Rust for performance, and sandstorm.io and terminal.com, both making cloud platforms and not using Rust significantly (yet!), but employ prominent Rustaceans.

The rest of this document is divided between a prose summary and bulleted notes.

Summary

One of the areas we talked about extensively is the onboarding experience. A summary might be: things are not bad, but there’s a lot to learn, and the docs still don’t go deep enough in places, especially for experienced C++ programmers. One person mentioned that there’s a lot to slog through before you can do anything interesting.

There were no tales of developers hating Rust, and it sounds like many are receptive. Some spoke of coworkers who work in C++ that are skeptical of Rust’s benefits, and MaidSafe mentioned that one of their C++ contractors elected not to make the transition and left the project (MaidSafe was fine with this outcome).

Peter from MaidSafe did tell a heartening tale about how switching to Rust had opened development of their core system to the larger audience of web programmers in the project who otherwise wouldn’t have touched the C++ codebase.

Documentation-wise, it’s clear there’s still much to do. We need more docs for C++ users, more examples for high-level things (e.g. requesting data from a URL), more instruction on Rust idioms. The proliferation of outdated docs continues to hamper Googlability.

When it comes to barriers to adoption, this quote from Seth Falcon at Chef summarizes pretty well the phase we’re in:

Talking with others and we’ve got another project where the prototyping is happening in Rust but they expressed reasonable concerns about pushing forward into production (e.g. it may be rewritten in something else). Are we ready to stand up and build a team with enough rust expertise? We now have a handful of engineers who can read/write basic rust, but it’s a big gap from having confidence knowing how to structure a larger project and not get lost. Want to end up with a system where you don’t hate yourself 5 months in. Not clear what the good patterns and good practice are, unsure whether they exist. Organizationally those are some of our blockers which make using rust for a larger project intimidating.

There’s a lot of trepidation about the newness of Rust. We’ll overcome this with time and success stories.

Although everybody has their favorite warts they want fixed, more language features are notably not a major concern, with a few exceptions: catch_panic needs to be stable for embedding Rust to be viable, and is the only thing preventing Skylight from being on stable; we’ve also talked to a customer that is developing a process-sandboxed server app that should just crash on panic, and we don’t have a stable way to do that yet (though there is a panic handlers RFC in discussion).

Other minor features were mentioned. The subtle interaction between trait objects and OIBITS continues to frustrate (this is the problem that leads to situations where e.g. some custom error type fails to implement Send and ruins the downstream fun because nobody’s encapsulated errors can fulfill the Error trait (or something like that)). It’s a big pain for the types of I/O dominant programs like Iron that reem works on.

On libraries, everybody wants one async thing or another and a DB abstraction layer. The unclear serialization story between rustc-serialize and serde needs to be resolved sooner or later.

While tessel supports running Rust, that support is not so robust yet and they need bindings to standard parts of the Linux driver stack: USB, SD flash, ALSA/PortAudio, L4V2, Bluetooth. Contributors wanted I’m sure.

Nobody complained about debuggers. Debugging may not be as vital to Rust as it is to C++, yet.

It’s no surprise that lots of people lament compiler speed (though not everybody). 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. Several people mentioned the long time needed to compile the compiler itself. I found this a bit surprising since our users shouldn’t ever need to compile the compiler (of course some of these users also contribute to Rust). Hopefully as we get better platform support this will not matter.

We asked everybody what IDE’s they preferred and there were no obvious winners, and a lot of people not needing a full-blown IDE but preferring SumblimeText or Atom. Early adopters are a hearty crew and don’t require such niceties.

There are a lot of other minor tooling issues: real-time code reformatting was requested; Racer is still too slow to be practical; the lack of backtraces in errors makes debugging large code bases difficult. With the spotty Windows support, it would be very beneficial to know which crates work on Windows.

Cross-compiling needs to be more friendly - people shouldn’t have to build the compiler themselves to cross-compile. We heard a lot of enthusiasm for being able to compile std via Cargo, which would go a long way to fixing the problem (note this isn’t currently in the near term plans). Deploying to Android and iOS is entirely a manual figure-it-out-for-yourself affair right now.

Tessel’s device is running MIPS, and Rust is miraculously working fine there. They also have a tantalizing ARM co-processor that they don’t compile Rust for. There was a suggestion that Rust is still not suitable for microcontrollers because static allocation and initialization is so limited. Cross-compiling embedded code can’t be done on stable until #[no_std] lands.

While everybody was happy to sit in two hour meetings with us this one time there was a lot less enthusiasm for making this a regular thing, nor did anybody make any strong requests for additional support channels. So right now I expect us not to, e.g., add new forums or mailing lists, but to follow up perhaps once a quarter with similar touch-base meetings, perhaps with slightly different format and new participants. Manish also suggested that the community team is a good contact point for production users, which I agree with.

Customer priorities and next steps

With what we’ve heard from customers, it feels like we’re in a pretty good place, but there are some pressing issues. These are things that are potential ‘deal-breakers’ for some of our favorite users if things don’t improve quickly.

catch_panic - Tilde needs it for embedding. Others do too.

- Tilde needs it for embedding. Others do too. panic -> abort / custom panic. We’ve heard from a customer (not on these calls) that must have the process abort instead of unwinding before they can deploy.

-> / custom panic. We’ve heard from a customer (not on these calls) that must have the process abort instead of unwinding before they can deploy. #[no_std] . This is keeping embedded developers off stable.

. This is keeping embedded developers off stable. compiler performance

Fortunately, catch_panic and #[no_std] are all but done. We need to not let the panic/abort issue slip by though.

Here are other ideas for non-critical areas we may push on to improve the overall Rust experience based on this feedback.

docs. There’s not a single big thing here, but it seems like there’s still a lot of low-hanging fruit that can elevate the user experience. Several pain points were pointed out. (Personally, I think a community-led effort to bolster non-std API docs would have a huge impact.)

better cross-compile experience. Several people mentioned that things could be a lot better.

backtrace-capturing errors. Is there anything we can do here?

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

I’ll set myself a reminder to follow up with another round of outreach in a few months.

Notes

The rest of this is just an outline of notes along several topics: onboarding / docs, platform support / cross-compile, tooling, libraries, language

Onboarding and docs

Meetups seem to be valuble (skade)

Too much to learn initially before being able to do real work Makes it hard to teach skade has a training project: https://github.com/skade/rust-in-an-hour Niko, Felix, and Steve also have training materials

Mutability story with Cell is clarified pretty late in the learning process.

High-level examples are hard to find (e.g. get data from URL)

Searchable documentation on crates.io

Testing documentation is hard to find

Non-systems audiences tessel.io introduces Rust to node devs

Concerns about hiring problems

Hard to know what ideomatic Rust is

Not enough docs for C++ users (per reem)

Rustdoc side bar is mostly useless

Finding all methods on a type is hard

Outdated docs on the web continue to suck. One suggestion to develop a culture of tagging Rust versions on blog posts.

Cross-compiling and platform support

Many people want easier cross-compilation Building the cross compiler and libs is too unfriendly

tessel.io is using MIPS (mipsel-unknown-linux-gnu)

Unavailability of Cargo is a problem on smaller platforms (FreeBSD). Bootstrapping Cargo dependencies on new platforms is hard

Lots of enthusiasm for being able to cross-compile std via Cargo https://github.com/japaric/std-with-cargo

Plan to distribute std bins for more platforms via online installer seems well-recieved

Microcontrollers Tessel’s device has a coprocessor Rust could concievably target (ARM Cortex M0) Need static allocation, for which Rust’s libraries are not designed. (I think we’re pretty happy with the story here - when needed this can be solved in libs ontop of libcore). Need Cargo to support #[no_std]. Might need various custom linking behaviors (targets specs may be sufficient)

Cargo should give guidance when cross toolchains are not configured correctly

Tooling

Compile time could be better of course, but no major complaints

Several people complained about the compile times of the compiler itself though (Not sure how real a concern this is for the greater audience)

Real-time reformatting

Racer still too slow. Is there work we can do here to improve things in the short term?

Tracking down error locations continues to be difficult because no backtraces, etc.

12sided is using makefiles, not Cargo

More votes to pass arbitrary flags to rustc

Cargo should tell you whether crates work on windows

Library deployment on android and iOS

Need nicer JNI integration on Android, Cocoa bindings

Need better deployment to Android via Cargo (matt -Ironworks)

Error suggestions are often incorrect

No clear IDE winners, IDEs personal choice at all orgs talked to

Lots using emacs/vim/sublime/atom, not IDEs

Acknowledge that IDE’s are valuable

Libraries

tessel kits run Linux and a good experience requires access to peripherals: USB SD flash audio (alsa/portaudio) video (l4v2) Bluetooth LE (what stack?)

DB abstraction (lots of demand for this recently)

More curation - yes rust-lang crates maintained by libs team

Lots of people want async I/O, async/await, green threading, async things ethusiasm for building on mio

Seth expressed desire for more cross-platform conveniences, e.g. recursive copy (ala Ruby/Python).

Unclear serialization story between rustc-serialize/serde

Problems with protobuf lib not working (needs a proto compiler? not sure)

Language

Reem is dissatisfied with the interaction of trait objects with oibits.

Reem wants more introspection (why?)

Fixed-size arrays cumbersome because lack of type-level ints

Non-lexical lifetimes

Future production user support efforts

Enthusiasm for regular meetings is minimal - too much time commitment

Manish suggests using the community list as a ‘switchboard’ for production support

Seth is interested in providing feedback on upcoming features

Several people expressed needed a more reliable way to stay on top of the roadmap. Between TWIR and subteam reports we’re still not surfacing the right info well enough. Maybe a feature dashboard.

FFI

Kevin (tessel) laments that wrapping bindings in safe code takes lots of boilerplate. Not clear how to address this.

Seth (chef) also mentioned FFI boilerplate and offered this example: https://github.com/chef/delivery-cli/blob/master/src/delivery/getpass/mod.rs

Kevin has at least used bindgen

Interop with untagged unions continues to be painful

Other topics