"Rust isn’t afraid to be imperfect as long as we ship something useful"

Introduction

Steve Klabnik is a member of the Rust core team, an active open-source contributor, and author of The Rust Programming Language, Rails 4 in Action, and Designing Hypermedia APIs books. In 2012 and 2016, we invited Steve to speak at the RailsClub (now RubyRussia) conference. Since then, Steve has been working on Rust a lot, did a lot of interesting things and we realized that we should definitely interview him once again!

We sat down with Steve to hear from him first-hand about his professional activities at the moment, the design success of Rust, a little about the "full-stack" development hype, and overcoming burnouts.

The Interview

Evrone: Besides your open source contributions, what are your professional activities at the moment?

Steve: I work at Oxide Computer Company, writing a bunch of Rust code!

Evrone: Are there any other technologies other than Ruby and Rust that you find interesting?

Steve: Rust is my focus at the moment, but I’m very interested in the rise of “headless CMS”es and JAMStack.

Evrone: You spent a lot of time hunting for theorycraft beasts to create top-notch documentation for Rust developers. Looking back at the language evolution, what do you think is the main design success that added the most to the language popularity?

Steve: The biggest thing was wanting to be useful. We tried to be familiar as much as possible, so that the few new ideas could get the focus. Rust isn’t afraid to be imperfect, as long as we ship something useful.

Evrone: What is your favorite software toolset for everyday work?

Steve: I use Visual Studio Code, with the vim plugin.

Evrone: How do you see good education for a software developer? Do we need to study the "computer science" theory to become programmers, or do we need to learn how to be "software writers", as DHH states?

Steve: I have a degree, but I learned much more outside of it. It is useful to me, but I know a lot of people who are excellent programmers who have had no formal training.

Evrone: Yukihiro Matsumoto stated once that "by choosing the language you also choose the projects you will do for your day job, and how you do them". What kind of projects and work culture do Rust developers mainly expect?

Steve: A lot of Rust jobs are in infrastructure, that is, stuff like operating systems, web servers, DevOps tooling, databases, embedded devices. There are also some web applications too, and that’s growing a lot recently.

Evrone: The new "async/await" syntax and concepts were recently introduced to Rust, as well as to other languages. As a person who writes language documentation and actually teaches people to use it, what can you tell us about the learning curve and developer feedback about these new features?

Steve: Rust has a reputation for being hard to learn, and that’s partially because it draws on a lot of other languages for inspiration. So if you haven’t tried one of the languages it’s taken an idea from, it may be hard to you. But something that’s similar to what you have tried might be easier. That means what’s hard and what’s easy is different for each person! A JavaScript programmer may say “oh yeah async/await, no big deal, cool” whereas a C programmer may say “what’s that?” But when it comes to pointers, the C programmer says “I’ve got this” and the JavaScript programmer may find it more difficult!

Evrone: Do you think there is any “natural affinity” towards software development like we have for playing musical instruments or drawing?

Steve: Maybe. Even if there is, I don’t think it’s required to be good at programming. It may make it easier, but it isn’t necessary.

Evrone: What competition do you see for the Rust programming language right now, and in what area?

Steve: The real challenge right now is jobs. There are more Rust jobs than you might expect, but it’s not super super easy to get one, because there still aren’t a ton of them. That’s changing all the time, but we’re not there yet.

Evrone: The type system landscape for modern languages spans from "dynamic typing" to "static typing" with lots of varieties like a new "gradual typing" approach. What do you think is the main challenge with types, why don't we have any "best" strategy that can be used by most programming languages?

Steve: Not all type systems are created equal. There’s a lot of different kinds of type systems, and some are better for some things than others. And then there’s also personal preference. I know some people that would never use a dynamically typed language, but while I prefer statically typed languages, I might choose a dynamically typed language over a language with a weaker static type system.

Evrone: There are lots of "burnouts" among open source developers, not to mention stories like recent actix-web confrontation. What helps you to maintain work-life balance and not burnout?

Steve: I don’t think I’m good at maintaining balance, it isn’t easy. I go through periods of doing a lot, and then periods of doing nothing.

Evrone: The new "full-stack" hype requires developers to learn a number of different languages and stacks. Given your fluency in such different ecosystems as Ruby and Rust, do you think it's a good idea for lots of developers to put many different things into their everyday work scope?

Steve: Learning new technologies is always great, and if you have the time and ability to learn more of them, you should always learn new things, in my opinion.

Evrone: Can we reasonably evaluate software developer expertise based on the number of years they have been practicing programming?

Steve: I don’t think so. Sometimes experience is helpful, but it’s also easy to get stuck in old ways.

Evrone: Do you think WebAssembly will be able to replace JavaScript as a frontend platform of choice in the future, or the "sandbox" architecture will forever limit it to the "high-performance plugin" niche?

Steve: I don’t think it’s really trying to replace JavaScript, so much as augment it. I think you’ll see a lot more wasm, but JS isn’t going anywhere.

Evrone: There are hot discussions across the internet on the "Monolith vs Microservices" architectures, with some big companies splitting their monoliths into microservices, while others gluing microservices back into glorious monoliths. It's even more complicated right now with a brand-new "Function as a Service" being available from all major cloud platforms. Could you give advice to developers on how to make a reasonable choice for their projects?

Steve: I think it depends on the skills of your team. Some teams prefer one big codebase, and others prefer many small ones. I think they all can work well, and they all can fail.

Evrone: How to choose between "SemVer" and "CalVer" for an average developer?

Steve: I personally prefer SemVer, but I am quite biased :)

Evrone: Is it reasonable for open-source if companies hire authors full-time? Or should we choose services like GitHub sponsorship, Patreon, etc., for financially supporting open-source maintainers and contributors?

Steve: I think it’s great when companies hire people full time. Everyone has to pay rent and eat food. If that money is coming from organizations that are making money, that’s often much better than from donations of other developers.

Watch a report by Steve Klabnik "Exploring Ruby through Rust" at RailsClub (RubyRussia) 2016:

We are glad to be friends with Steve who inspires us to use Ruby & Rust in a wide range of projects. Reach out to us if you need help with the development of an outstanding solution, and we'll be happy to help!