Rust

I’ve noticed that although Rust is growing, the relative numbers here are staying the same. That’s good! It means the number of Rust hobbyists is increasing and they can turn professional at a good rate. Employers take note: If you look beyond people with ‘X years of professional Rust experience’, you’ll find a big hiring pool of people willing to switch from their current jobs.

Anecdotally, Rust did transition from ‘a weird new language’ to ‘it wouldn’t be insane to put this into production’ a couple of years ago, so growth here is expected, and very welcome.

Rust is a young language, so it’s hard to find people with years of experience. For that reason, managers adopting Rust should budget for training and other forms of education and support for their teams. Also, consider that someone who has programmed for decades can adopt a new programming language rather quickly with help.

People who have used Rust in the past are by and large still using it. The relative share of newcomers has been nearly constant, showing a healthy organic growth pattern. The share of senior Rustaceans has grown, which is good news for employers seeking them.

Roughly half of the responders are polyglot programmers, using another language alongside Rust. It looks like the percentages roughly mirror current popularity. As they say, the perfect tool is often the one you already hold.

I’m pleasantly surprised here – I expected the proportion of pure Rust projects to be a little lower. I’m not surprised by the JavaScript numbers; the communities are very close and get along well with each other.

Huge growth for rust-analyzer! Not surprising, given that the rust-analyzer project recently became a part of the wider Rust organization, and the Rust Language Server (RLS) has been deprecated in favor of rust-analyzer. I am personally quite happy that a lot of folks use advanced IDEs for Rust, and that there’s healthy competition and collaboration between IntelliJ Rust and rust-analyzer!

rust-analyzer has made major headway, now being the official LSP implementation for Rust. IntelliJ Rust has stayed very strong, too. Having worked with both, I still switch between them every now and then. Two damn fine pieces of engineering. Kudos!

More people use a debugger now, likely because support has improved since last year. The dbg! macro still unsurprisingly takes the cake, as a quick and easy way to get insight about the runtime state. And let’s not forget that, with Rust being as picky as it is, applications often don’t need debugging in the first place.

Debuggers are as much of a pain as ever. I myself use eprintln! (via pd snippet in my IDE), but I miss great debuggers from my time with Kotlin.

That’s squarely the toolchain’s fault! All the tools listed here are impossibly fiddly to use. If you do profiling full-time (so, a perf engineer on a big project, a-la nnethercote), you can invest time and effort into learning all the perf flags. If, however, you want to spend only a fraction of time doing perf investigation, the learning curve is very unfriendly. I wish Rust took a page from Go’s book, which has pprof.StartCPUProfile as part of the toolchain. This is going to require a huge effort, though.

It’s amazing – but also not surprising – that in a language that many people use for speed, performance measurement isn’t a common practice. My theory is that performance tooling is inaccessible and differs based on platform.

CLI tools have proven to be a niche area where Rust shines. Last year, almost half of developers were developing them. What’s also interesting is that, while blockchain companies often proudly boast that they use Rust, only 6% of respondents actually work in that space. This is either a case of outsized hype and marketing or the few Rustaceans who work in blockchains are very effective developers. Or both.

Given that the public perception of Rust is that there are a lot of Rust jobs in the blockchain industry, I’m quite surprised to see this option below even embedded and academic use.

Linux reigns supreme, though Windows has made headway. I think this may be due to Microsoft investing in Rust, combined with the fact that Linux users are often early adopters and the growing community now has more conservative users, who tend to use the OS their PC came with.

Another tiny surprise for me – I would have placed WebAssembly somewhere around embedded use. Once again, this shows how important polling is.