Embedded Rust in Production?

Access to competant Rust developers can be a challenge even for large companies.

I recently finished a contract at a (very large game dev) company where some tools were written in Rust. The tools were a re-write of python scripts and added no new functionality but were slightly faster in Rust.

The reality was that these tools were unmaintainable by the rest of the company. Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.

The only reason these tools were written in Rust was because the dev wanted to learn Rust (a big but common mistake). I pointed out to the Technical Director that this was a big mistake and the teams had taken on a large amount of technical debt for no reason other than the ego of the wanna-be-rust-developer. Since I "knew" Rust he wanted me to maintain it. My advice was to go back to the Python scripts and I left.

This question of "what tools / languages" should we use was introduced to me (during an interview, actually) as "technical strategy". There is more to the choice of language or tooling than whether it's fast or slow or reliable at one instant in time -- you have to ask how you will grow and maintain things going forward.

That said, obviously all languages were in that state at some point. Twenty-eight years ago you might have said the same thing about Java. Twenty-four years ago, Perl might have looked like a better choice than Python; now it's clearly the opposite. XenServer took a gamble and wrote their main control stack in OCaml in 2008; on the whole that has had some benefits, but the number of OCaml developers has not significantly grown, and it's not easy to hire people.

That said, I think Rust is much more likely to follow Java's trajectory than OCaml's: My prediction is that it's only going to be easier and easier to find Rust developers.

> Rust is much more likely to follow Java's trajectory than OCaml's

I'd rather compare Rust to Haskell and Kubernetes.

  Haskell:
  - Dozens of handfuls of experts open to remote work.
  - Lots of aspiring juniors who see no way to enter the market.
  - Most employers are R&D-heavy academic consulting environments.

  Kubernetes:
  - Wildly hyped and cherished among people who don't have the complexity to warrant the purchase.
  - Eventually criticised for being overly complex and suitable only at a certain size and setup.

> it's only going to be easier and easier to find Rust developers.

I imagine it's never been easier to find Haskell developers and Kubernetes developers, either.

Yet, one's wish to code Haskell professionally does not necessarily align with one's market value.

It seems like there's a lot more open for Kubernetes, so Rust could go that way.

Unlike Haskell, Rust seems to gain industry acceptance.

Haskell and OCaml have a lot of what Rust has (namely exhaustive pattern matching + sum types, typeclasses and the like) but Rust has stellar tooling.

Had both of these languages' ecosystems and communities not dragged their feet and go full elitist on newcomers then Rust might not have ever been created.

So sure, Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program and then spending the other half on trying to do the same in OCaml I just threw my hands in the air and said "frak this, there has to be a better way".

Hence I landed on Rust. You and others can always say "skill issue!" but that's hugely missing the point; I want to use my skills on solving the actual problem, not on the logistics. We're not in the 1970s anymore and a weirdly huge number of people still haven't gotten that message.