2016 Rust Commercial User Survey Results


#1

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.


#2

First: this is awesome. Thanks for posting it.

Second:

What does front-end application mean in this context?


#3

Here I’m trying to use the term a bit more loosely. Probably a better way to say “front-end” would be “user-facing” where back-end would be “on the server/behind the scenes”


#4

Great read. Can you say anything about how you found these companies for outreach, and what fraction of those contacted for the survey responded (since there’s inevitably going to be a degree of self-selection there)?


#5

Sure thing. We reached out to many of the companies on the friends of Rust page. There were also people connected to companies that asked to be contacted as in the community survey that happened earlier this year. Finally, there were a couple companies that reached out to us more directly.

All told, looks like about 3/4 of the friends responded and 1/2 (or thereabouts) answered the full survey or we had calls/meetings with.


#6

Can you speak more about the embedded users and their use cases? For the most part, the majority of all embedded work I’ve seen is C/C++

It would also be interesting to hear about multimedia / graphics uses if any.


#7

I don’t have a lot of detail but some of the things that came up were the need for real-time performance, low-latency audio, and some uses around video processing and multimedia transcoding.


#8

I’m a bit confused here. On the other hand, we have an ample amount of experienced Rust people that would love to do Rust jobs/trainings, and don’t find any opportunites. But they are mainly freelance or running their business. [1][2]

It seems to me that these companies want to only work with their inside teams because someone came up with the idea to use Rust. It seems odd that the consulting market doesn’t happen, though, even if it would make sense to hire externals for a PoC for example. It’s not an unusual pattern though, my usual bread-and-butter software (Elasticsearch) is only now developing a freelance/consulting market.

Would anyone know ways to kickstart that?

[1] Full disclosure, I’m one of them - I have a full set of Rust developers, but we prefer not working inside a company. [2] Many people interested in education and guidance are mostly available on the freelance market, not for hire into companies.


#9

A consulting market might work for niche product experts such as Elasticsearch, but companies hiring Elasticsearch consultants will invariably have in-house people also using Elasticsearch. They will just depend on the domain knowledge of the expert for certain things.

This doesn’t work for a programming language. If you are a tech company you need to have people in-house who know all of your code inside out and are able to make any changes necessary. You might outsource the development of parts as necessary but you’re never going to completely depend on outside people for your core products.


#10

I think you misjudge the ES market there. There are many clients that just don’t want to learn Elasticsearch before committing on Elasticsearch.

The consulting market is also very often driven by programming languages. Don’t have 5 years of PHP? Get lost, even if your job is optimising indices.

There’s an ample amount of companies building whole products our trial products outside of their core teams - mostly companies larger the say 500 employees.

Finally, there’s an ample amount of mixed forms. Should your company decide that Rust might be worth a look, why not get someone on board that knows the language already instead of falling into every trap yourself?

I used to do Ruby consulting before I switched (by chance) to do mostly ES. I know both sides of that market and trust me: the niche is there, but it’s both for clients and consultants to realise it.