Recently, we completed a survey of commercial users of Rust. In total, fourteen companies responded to our outreach and told us their stories of using Rust in production. In this article, we’ll dig into those stories and take a look and some of the unique challenges of using Rust in a variety of software stacks. We’re hoping it helps fill out a more complete picture of how Rust is being used, so we can better plan Rust’s future.
Size of investment
Each of the 14 companies that responded is using Rust in their products, though the amount of investment varies dramatically. On one end of the spectrum is one company that only has 1000 lines of code in Rust. At the other end are companies betting the farm on Rust, with all of their core libraries or all of their backend code written in Rust.
Areas of interest
One might suspect that companies using Rust would be heavily focused on a few areas, but we instead found that companies using Rust are a diverse group. Areas of interest included:
- network security testing
- software failure detection
- mobile and web middleware
- job searching
- shared hosting
- performance monitoring
- energy efficiency and sustainability
- machine learning
- artificial intelligence
- audio/video transcoding
- embedded systems
The commercial users help to underscore that Rust is very much a tool for general-purpose development where performance and safety matters.
Why Rust?
We’ll let the responses speak for themselves:
“Rust has the opportunity to provide a similar level of abstraction (as C#) in our code but without the weight and cost of the .NET framework and Garbage Collector while increasing our confidence in the safety of our code.”
“I don’t want to be shipping code with as many vulnerabilities as lines of code.”
“Rust has been awesome. Zero segfaults, data races and undefined behavior so far.”
“After some experiments with Rust… the tech team decided to deploy it on production as it was working fine in terms of speed and reliability, our main concerns.”
“Our codebase used to be completely in C++11/14 until the beginning of 2015. At that point it the intellectual overhead of keeping undefined behaviour at bay became very high, and specially being open source, there was huge amount of template meta-programming which made code complex for newcomers (we are open-source) and the benefits started dwindling compared to maintenance overhead. That was when we entirely migrated to Rust.”
Commercial users of Rust were a diverse mix of technology stacks as well. Rust was being run in production alongside C#, Java, Ruby, C++, even Fortran. Some companies used Rust in their front-end application, while others preferred deploying it in the backend.
Pain points
Just as we did with the community survey, we also opened up the floor for each commercial user to tell us about the pain points that were specific to their business usage of Rust. As you might expect, there’s overlap between the needs of commercial users and the broader Rust community.
Library support
Commercial users leverage the open source community to be able to build a product quickly. The growing number of powerful crates in crates.io help facilitate this, and commercial users take full-advantage of what is available. Still, there are gaps in the quality and functionality of the crates available, which businesses must either fill in or accept a product without those features.
Commercial users were quick to praise the cargo tool as one of the powerful features of Rust, but just as quickly pointed out the relative immaturity of the crates ecosystem. There were no common set of missing features, each commercial user had a specific list of crates that needed more features and a stable API.
There is palpable excitement about the recent efforts in async I/O among commercial users who are building servers with Rust. Specifically, they mentioned a growing need to have high-performance HTTP and HTTP/2 servers, and more generally, a high performance framework for async I/O.
Related to the above point about more full-featured library support, there were also requests around being able to connect to more sources like MongoDB, Apache Kafka, and SMTP and have access to their full feature set.
Improving FFI
Better FFI was also a common theme. In total, five companies, across current users and potential users, asked for better C++ interop. This was an especially hot topic in resource constrained areas like embedded systems, games, and VR where the sizeable C++ investments are established. This created friction for adding Rust to their stack and was one of the first pains they encountered.
There’s a hope with some of the people we contacts that the work we’re doing on bindgen will continue to grow:
“Our codebase being C++, I hope we can using bindgen to generate the interface between Rust and the existing code.”
The sentiment shared focuses on reducing the maintenance and transition burden enough to allow some subset of the C++ codebase to be written in Rust, whether it is new code or a rewritten module.
Other FFI improvements also got a mention, specifically around areas that are tricky to debug (eg, accidentally overwriting the drop flag and leaking memory).
IDE support
We received a resounding response to continue investing in building strong IDE tools. IDE tools in a commercial setting help teams coordinate their efforts by making it easier to navigate unfamiliar code, on-board new users, and streamline the development process.
Additionally, many shops are already familiar with working with other languages that have strong IDE support, like Java and Eclipse or C# and Visual Studio. To these users, the IDE has become an integral part of their workflow. If switching to a promising new language also means giving up the convenience of familiar IDE tools, the switching costs often overcome the benefits.
We recently announced the Rust Language Server with the hopes that it will grow and fill this hole.
Improved build times
“Build times. I constantly find myself wandering into r/rust or hacker news while waiting for builds. Our cached builds on travis used to only take ~2 minutes and now they are approaching 10. Incremental compilation will be huge here.”
More than most, commercial users feel the pain of slow edit->compile->debug cycles. As projects grow in size, especially with the pressing demands of deadlines and growing numbers of features, each time through the build cycle costs a project. The faster ideas can be tested and built on, the faster new features can be added to products going to market.
For Rust to be successful, it needs to tame its build cycle times to make iterative work possible.
Better ramp-up for new Rust devs
Companies are staffing Rust projects with developers more accustomed to other languages. For developers from dynamically-typed languages like Ruby or JavaScript, the transition to Rust can be a bit daunting.
Commercial users pointed out that it’s not just the borrow-checker that causes new users trouble, but also unfamiliar syntax and a coding style foreign to OOP developers.
Equally, there’s a need for commercial users to be able to share their learnings with each other about the best ways to use Rust in production. As Rust continues to grow, finding ways to help this transfer of knowledge happen will help companies ramp up more quickly as they begin Rust projects.
We’re currently working on a new Rust book that hopes to smooth some of the learning curve, but there’s more we can do to help bridge the gap for developers coming from other languages and programming patterns.
Looking ahead
The growing number of friends of Rust is an indicator echoed in what we heard from the commercial user survey: Rust has some unique strengths to offer application development. People feel empowered by using Rust as part of their business. These same users, by putting Rust to use in production, are able to push it harder than most and have first-hand experience with its strengths and limitations in a variety of fields.
There are some good opportunities here to help these companies be successful with Rust, and in turn help make the Rust community stronger.