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.

As a Rust/Python dev I previously decided against Rust in a work context as I deemed it would make me the sole person who knows what is going on, while python feels much more like a lingua franca of programming nowadays.

I would decide this on a case by case basis tho, Rust is different, but if e.g. what you wrote derives most of its business logic from its configuration, or the usecase is so generic changes aren't gonna be a thing for a while, why not. Rust is different, but unless you want a complete rewrite or new complex features any developer should be able to get into it if you give them a little time.

And the strictness of Rust makes it unlikely that they break things in a bad way, which is good.

> but if e.g. what you wrote derives most of its business logic from its configuration, or the usecase is so generic changes aren't gonna be a thing for a while, why not

there’s also the fairly easy cross compilation to bear in mind.

i built a container entrypoint binary via python to stick in all our containers at last job.

getting that to cross compile was going to be a bunch of pain i wasn’t willing to go down for a simple “download files from S3, run a sub process, upload files to S3” pre-execution wrapper.

digital ocean infra + self hosted gitlab —> no readily available windows instances.

so everyone had to use linux to dev these containers with wine+mono.

being able to cross compile would have been brilliant here. i made the decision to not do this in rust for future maintenance reasons. but then people avoided using this thing because they couldn’t run on windows :/

(i know there’s that paid for package but the license fee is mind boggling from what i remember).

perhaps Go could have been a good solution for simple, cross-compiled code.

from what i looked at, go was a bit more complicated than rust for cross compilation. but it was still a lot less complicated than sorting it out for python. dunno. was at least two years since i looked at it, but i remember rust coming out on top in my mind.

unfortunately the same maintenance issue applied -- it was a python / R shop so no-one else would have been able to change the code once i left.

AFAIK Go has one of, if not the easiest cross compilation stories.

This is all it takes to build a linux arm64 binary:

  env GOOS=linux GOARCH=arm64 go build your_program

You can even run that from Windows and it will just work.

This is how you list all possible targets:

  go tool dist list

If you want to generate binaries for many linux distros, you can even use a simple bash script:

  #!/usr/bin/bash
  archs=(amd64 arm64 ppc64le ppc64 s390x)

  for arch in ${archs[@]}
  do
    env GOOS=linux GOARCH=${arch} go build -o your_program_${arch}
  done