I did indeed add Squirrel just to try it out (I'm considering using it as a scripting language), though I wouldn't be surprised if Euphoria and XSLT were also originally used for that reason. XSLT is there for generating .html documentation. C because I needed speed but didn't want to use C++, C++ because a C++ programmer contributed, Obj-C for the Mac port, JS for the web port, x86 assembly for the original DOS version, Bash, Batch and Python for scripts... any project can quickly reach 10 languages this way.

This has the problem that your deps can get out of sync with your lockfile... which is why most/all the newer python package managers have a run command that works more like cargo e.g. https://python-poetry.org/docs/basic-usage/#using-poetry-run

If you tried it a while ago things likely improved since then. `cargo fetch` and `cargo vendor` are both single-command solutions for airgapped networks.

I don't want to assume too much about your specific use case, but in a lot of situations that people describe this way, the truth is that the code would've been correct if it was C but -- because it violates the no-mutable-aliasing rule -- it's genuinely broken under the Rust memory model and will trigger UB if you use unsafe code to work around the compiler errors. https://youtu.be/DG-VLezRkYQ

If you find it aggravating to use, then it’s not likely this will make you happy but just in case it helps, you can just bake it into your image and be completely airgapped and the only real factor is storage because the actual functionality is easy.

You can use the 'cargo vendor' command to download all of a project's dependencies and then transfer them to an air-gapped environment.

https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

This allows for the project's dependencies to be checked before they are introduced in the air-gapped environment and also placed in version control for a full snapshot of the project.

At $WORK we have been using Rust this way for a few years now and it has been great. Cargo is much easier to use than cmake, make, and other custom build scripts we were using before. After a few trials, we have been migrating projects from C/C++ to Rust and management has been impressed with the results. The code is equally fast, errors are down, and our velocity is improving since we find and correct more problems earlier in our processes.

Cargo does have an `offline` mode for `cargo build` which won't hit the network, and you can vendor dependencies. You can also invoke `rustc` directly outside of Cargo. In general though I think the Cargo team is optimizing usability for the 90%ile who can and do use the internet while developing (which is also unavoidable with other language ecosystems). But getting stuck if you're in that 10% is always hard.

That's what unsafe is for. From the rust book:

"Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler tries to determine whether or not code upholds the guarantees, it’s better for it to reject some valid programs than to accept some invalid programs. Although the code might be okay, if the Rust compiler doesn’t have enough information to be confident, it will reject the code. In these cases, you can use unsafe code to tell the compiler, “Trust me, I know what I’m doing.” Be warned, however, that you use unsafe Rust at your own risk: if you use unsafe code incorrectly, problems can occur due to memory unsafety, such as null pointer dereferencing."