Embedded Rust in Production?

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.

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.

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.

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.

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.

That's certainly true of the last 10 years of Ocaml tooling evolution.

If we both start from that point then I think we might find a common ground.

For instance, coming from C Unix programming, it took me 2 hours to try OCaml 15 years ago or so, because Ocaml tooling, at that time, was the same as C. Basically, I made a generic rule for my makefiles to call ocamlopt instead of gcc and I was good to go. Installing a dependency was just the usual "./configure && make install"

This was simple for me, but not for students with no Unix background. In that context "opam install" was simpler, although it's objectively more complex as it adds a few additional layers on top of the same process.

I moved away from makefiles long ago and I don't regret it, for a multitude of reasons that are well explained in many places.

`cargo add ...` is great and I wish every language offered a tool like that.

I use `just` for project tasks, but there are many others.