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.

But 28 years ago with Java, it had a clear edge in a certain space. It came with a ton of libraries, so you didn't have to write a bunch of code. And it had garbage collection, so a bunch of problems just went away. For code that didn't have to be close to the metal, it was clearly superior. And it was pretty easy to learn for C++ developers.

Rust may have an advantage in certain places (no segfaults is a definite win). But replacing working Python scripts is almost certainly not that place. Also, for a C++ developer, Rust isn't as easy to learn as Java.

Rust may get there. But don't use Java's success to predict Rust's trajectory.

Java had a lot of things going on for it. Huge marketing push, whole set of everything both language and lib-wise, and killer domain which was SIM and mobile which if you wanted to do it was your only choice. Rust has no such things at the level Java had when it rose. It's more of an organic grassroots movement certain companies have started to pick up.

Yea it did, and its important when making comparisons to not glaze over it. Java with the, write once and run anywhere mantra due to the JVM was a huge deal. Granted, in some ways it didn't pan out as well as advertised (embedded Java), but for an enterprise desktop application, it was definitely a huge win for the time.