The Rise of Rust in DevOps
How powerful and easy-to-use Rust became the next-gen infrastructure language.
Florian Leibert, CEO of Mesosphere, recently sat down with Steve Klabnik to talk about the rapid adoption of Rust and its role in DevOps. If you're on Hacker News, you probably already know Steve, who is active under his handle, steveklabnik. We're very excited to have a Rust expert like Steve contribute to our blog because a lot of Ruby on Rails developers are moving to Rust, which could be the next generation infrastructure language.
Steve is currently working for Mozilla on Rust and is deeply focused on developing high-quality documentation. Developing helpful, informative and easy-to-digest documentation just might be the major theme of Steve's career. It all started when he got his computer science degree and almost got an English graduate degree. At that time, he realized that combining coding and writing was deeply fulfilling, and that's a good thing for the rest of us because he's leveraged his gift into creating some of the best tutorials and documentation available for Ruby on Rails and Rust. His Rust for Rubyists tutorial has turned into The Rust Programming Language, the official tutorial for the language.
Rust's Rapid Adoption a Result of Great Tutorials and Documentation
Florian Leibert (FL): I think documentation is one of the most underrated things out there, primarily because it's such an accelerator. When you're trying to hunt down a bug or trying to figure something out it can take hours on your own, or with the right line of documentation it can take a minute or less.
Steve Klabnik (SK): Definitely. We did a survey of Rust users. We do one every year, but we did a specific one asking "how do you figure out how to use packages in ecosystem" and the number one response was that good documentation often leads developers to choose one library over another. I think that's true of languages and everything else. If you can't figure out how to use something, you're just not going to use it.
SK: I was not around for the initial announcement of Ruby on Rails, but my old boss was. He had been just starting a new web application in whatever the Java Framework of the day was, and he was about one week into it and had spent most of his time setting up the project, getting the database hooked up and doing all that kind of work you do at the start of a project. Then he ran through a Rails tutorial and realized that in Rails it would take five minutes to do what had just taken him a week to do in Java. From that moment on, there was no looking back for him. I think that one reason Rails took off was that it was such a clear improvement on the status quo. Interestingly, I also think that's why Rails is not really considered to be the cool thing anymore, because by now those kinds of advantages have been incorporated into other frameworks and languages to make them easier to use also.
Rust's Growth Driven by Positive Community Interaction
FL: When you first started to work with Rust, what attracted you to the language?
SK: What really sort of got me hooked, was the people. My first contact with the Rust community was when I joined the IRC channel and I asked something about "Hello, World!". Instead of people telling me, "you're just doing "Hello, World!", you must be too stupid to use this. Go away.", they replied with a friendly "we're so excited you're interested in Rust. We'd be happy to answer all of your questions." And then they proceeded to do so really well.
I've also learned doing open-source for years that communities are a very big important part of open-source and I want to try to work in projects that have a really great community. Rust has a particularly excellent community and that's been really helpful.
Also, I had been doing Rails for the last couple years, but before that, I did a lot more low-level programming. I felt like I had achieved everything I wanted to achieve in the Ruby world and this new language came along that was being touted as being great for low-level tasks. I thought that this was a great opportunity to get back to my low-level roots. It turns out that Rust is convenient and safe way to program on a low-level. I was intrigued because Rust took the low-level approach and combined it with a lot stuff from the functional programming world. That got me really excited about learning it.
Efficient Plus Easy to Debug Equals Operationally Boring
FL: What types of projects do you think Rust is best suited for?
SK: I think that we're sort of even still figuring that out. People are using it for all kinds of things we never dreamed of. Rust is really useful when you have particular hard requirements on your runtime. For example, you need every single last ounce of speed. Rust has very low overhead and very low memory usage, and that's beneficial in these use cases.
Another great use for Rust is when you're coding something that has to be 100% accurate, which sounds like a strange concept because no one wants their code to be wrong, but very few programs must be 100% correct. Engineering is all about tradeoffs, and sometimes something that works 80% of the time is good enough. Rust contains a set of guarantees that tend to take a little bit longer to develop initially, but they do a really good job of forcing you to write correct code.
Obviously, no one would ever claim that every Rust program is perfect, but our users say that they tend to spend significantly less time debugging after the fact. One of our production users has said that they enjoy Rust because it's boring operationally. Once they put it into production, they don't have to worry about it ever again. In general, you just write it and then it does what it says and you forget about it. It's both boring and exciting.
Desert Island Rust Libraries
FL: That's great that people are finding so many uses for the language. I bet you have at least a few libraries that you couldn't live without. What are the three Rust libraries that you think you could just can't live without?
SK: This is a great question. We invested very heavily early on in a great package manager called Cargo. The Rust standard library does not come with very much in it, so the packages and the package ecosystem are essential for expanding functionality. As a result, there are a lot of packages out there that are great.
I think probably my number one favorite package is Regex because I really love regular expressions. I love regular expressions so much that I have a Perl ML tattoo. I'm really into this because specifically our Regex specification is extremely fast. Regular expressions are one of those tools that is so useful you tend to use it even you probably shouldn't.
Number two on my list would be CLAP which is short for Command-Line Argument Parser. The last one, I can't really say it's the most useful, but it's the most interesting and one that I talk about a lot is a package called x86. It gives you binding to the low-level processor features of the x86 platform.
Runtime-less Rust Rocks
FL: And are you familiar with anything maybe like Spark or something like TensorFlow that's written in Rust?
SK: Y Combinator funded a startup called Autumn.AI and they were building a TensorFlow competitor entirely in Rust. Unfortunately, as startups tend to do, they ended up going out of business (not because of Rust but because of the business) and basically said, "Who can compete with TensorFlow? So nevermind."
I don't think there's anything super at the moment written in Rust, but one of Rust's strengths is it can treat itself as being like C. Because Rust has no runtime, interfacing with other languages is a huge growth area. One of the first production uses of Rust was actually extending a Rails map. Rust not having a runtime means it can pretend to be C and anything that knows how to talk to C can sort of talk to Rust. I know people have TensorFlow bindings and even work with TensorFlow in Rust, interface with TensorFlow in Rust even if TensorFlow is not native to Rust itself. This space is very interesting and exciting and there's a whole lot of stuff coming up, but it's sort of still at an early stage everywhere, let alone in Rust as well.
Rust's Role in DevOps
FL: How does Rust play into systems automation, container management and container orchestration? What is the role of Rust in DevOps?
SK: There are a number of places where Rust is being used in the space and they're all slightly different. Oracle developed an entire container runtime in Rust and that was their first open-source project in the language. To have a company that's that large developing a container runtime in Rust is a pretty interesting development. Another one is CoreOS.
One example that's really interesting is Coursera. While they're not building container stuff in Rust, they are using Rust and Docker together to power their educational platform. Students write these homework examples or exercises and then they run the code inside of a Docker container and grade it. They use Rust code in the Docker container to deal with permissions and other security settings.
Chef has a new project called Habitat that is sort of this whole deployment strategy. Basically the idea is that instead of having a particular sort of centralized place that manages your infrastructure, it packages the infrastructure stuff with your application when you deploy it. They're going all in on that and that entire new product of theirs is completely written in Rust from the ground up. That's a very interesting use of Rust to evolve of the DevOps space.
Buoyant is investing extremely heavily in Rust. They not only have written some projects in Rust, but they're also investing heavily on the Rust open-source ecosystem. They've just made several key hires of big names in the Rust space and they're paying them to work on open-source stuff that Linkerd uses. I'm really excited to have them involved in the Rust community and do a lot of great open-source work.
FL: Buoyant is actually a big partner of ours and we have a really awesome combined use case of Kubernetes on DC/OS combined with Buoyant Linkerd and it's really exciting.
SK: They're committed to improving the open-source ecosystem and that's something I really care about since it's been most of my work across ecosystems for the last couple of years.