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.
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
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
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
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
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.
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.
#[no_std]. This is keeping embedded developers off stable.
- compiler performance
#[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.
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
- Plan to distribute std bins for more platforms via online installer seems well-recieved
- 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
- 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
- tessel kits run Linux and a good experience requires access to peripherals:
- 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)
- 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.
- 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
- Testing - want to test README’s
- Release channels
- Lots still on nightly (skade, tessel, chef)
- Chef is using docopts_macros and regex_macros, both unstable
- Cross-compilers are stuck on nightly until support improves
- Not much interest in i18n/l20n yet