As someone used to unamaged languages since 1986, and with a major focused on systems programing, it isn't that clear cut.
Rust executables are only 100% static on OSes that expose system libraries as static libraries, and there are not many of those around, outside embedded systems.
As a counterpoint to the parent commenter, I like using Rust for personal stuff (like the project being linked to) for almost everything besides the memory model; I prefer Cargo to any other build tool I've used, and I like how I can eliminate boilerplate with stuff like Serde (for serialization), clap (for argument parsing), and even for how I'm able to write one-off macros to generate code for myself. The documentation for the language and tooling is great, and most packages have fairly good documentatio as well because any package published on crates.io will have it generated from the doc comments into a static site and hosted on docs.rs. The compiler error messages are better than any other language I've used, and at least for my personal use on Linux, I can easily compile with musl and get a fully static binary when libc is my only native dependency; I'm sure that Linux desktops are part of the "not many of those around" you refer to, but the same trick would work just as easily for any Linux server, and I do feel like there are plenty of those around!
If I could get all of those quality of life things in a language with a garbage collector, I'd probably use that for most things instead. Right now though, the closest options would be maybe OCaml or Swift, one of which doesn't really give me nearly as much in terms of quality of life stuff around documentation and tooling, and the other isn't nearly as streamlined to use on my platform of choice as I'd like, so I'm using Rust unless (or until!) something better for my personal projects comes along.
After years navigating this issue, I think the common understanding of "static" binary is just "something that won't give me a dll / dylib error on startup when I copy it to my friend's computer"
Which is a possibility, given that ldd/Dependency Walker result won't be an empty list.
Even shipping the whole computer on a container, might not do it, because most containers are leaky abstractions the way their Dockerfiles are written.
Yet in practice this works fine for all intents and purposes.
Sure, you might get a loading error if you try to run your Ubuntu 24.04-compiled executable on Ubuntu 18.04 if you use the default toolchain. tTat’s exactly the same as C or C++, only much easier to fix in rust by rustup-installing the right tool chain.
Compiling on Ubuntu 18.04 and running on 24.04 is absolutely not an issue. Same for windows.
In practice this is really not a problem, especially for cargo libraries that you anyway build from source.
I would say the same regarding dynamic linking, which is why most OSes have moved away from being static linking only executables, except embedded in the cases where it is a single blob uploaded into the device.
Not even modern 3D graphics APIs, none of them, work with static linking, yet another area static linking advocates have to accept the industry has moved on.
> Rust executables are only 100% static on OSes that expose system libraries as static libraries
This seems to be a weird hair to split. GP clearly means “a single executable you can run on any install of the target OS without dependencies.” Whether it’s a truly honest-to-goodness static binary that don’t link to libc or libSystem or whatever is important to approximately zero people, outside of internet pedants.
I agree that this is what many people -- including me -- are caring about.
However, it is not achieved in practice with "static" languages like rust and golang for me
I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries between different OS like Ubuntu and Fedora or even just different versions of the same OS
> I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries
Assuming you’re talking about rust binaries, this would only happen if your binary is using glibc symbols that don’t exist on an older version of glibc, and then try to run that binary on a system with the older glibc.
But glibc is a red herring here, because rust is only using libc to call syscalls on the host, because that’s how you’re supposed to do it on every OS, and that’s how you have to do it on every OS but Linux. (Only Go seems to want to implement their own syscalls on Linux.)
It’s a red herring though, because even if rust made their own syscalls and didn’t use glibc on Linux, you’d just fail with ENOSYS when these syscalls are used, instead of failing with undefined symbols at load time. If you try to run stuff that was developed against newer kernel features, on a system without these syscalls, you’re going to run into an equivalent issue. (You might get lucky and not need those syscalls in your app, but that’s not always going to be the case.)
It is, because so many folks make such a big deal of how using computers as they used to be until early 1980's, with single static linking model.
Ironically the same folks don't see to appreciate how object files and binary libraries work in static linking, lets make it even better compiling always from source.
> Good dependency management, a rich package ecosystem, defaults to static binaries which are easy to distribute and a tendency to be fast (even if it’s just the lack of startup overhead) make it a popular choice.
> .....
> Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime.
People are using a term in a different way than you want them to.
They use static binary to mean “the dependencies I specify in my package manager are all put in the one binary, and it doesn’t require a separately installed runtime to run”, which is totally reasonable, and it is opposed to so many languages that don’t work this way.
You’re using static binary to mean “does not link to anything at all”, which on some systems results in worse portability, since the syscall interface is unstable and linking to libc/libsystem/etc is the only supported way to make syscalls.
You come into the discussion assuming definition B, ignore the fact that they’re using definition A, say that they’re making a big deal about definition B, etc.
There’s no confusion from anyone here but you. We all are using definition A. You’re the only one using definition B. It’s probably better if you just recognize that and move on rather than insisting everyone here is an idiot but you.
Rust executables are only 100% static on OSes that expose system libraries as static libraries, and there are not many of those around, outside embedded systems.