Both Go and Rust do not produce static binaries by default -- they both link to glibc and a few other libraries -- but you can coerce them both to do so (though with Rust it's slightly more painful because you need to install a compiler toolchain that uses musl, but rustup makes it pretty painless).
By static I meant go and rust dependencies bundled into the executable. Dynamically linking to libc is ok with me, any system I run on has a usable libc.
Though it should be noted that when you compile such a binary on a system with a newer glibc, it will not work on a system with an older glibc. To be fair this is basically the case with C as well (you can work around it with .symver but it's kind of dodgy), but it is worth keeping in mind.
Yes, this is true for a great many things. If I compile these pseudo-static binaries for use on multiple different linux distributions or libc versions, I compile on the oldest/lowest common denominator so that it runs everywhere I need it to.
Comments
Both Go and Rust do not produce static binaries by default -- they both link to glibc and a few other libraries -- but you can coerce them both to do so (though with Rust it's slightly more painful because you need to install a compiler toolchain that uses musl, but rustup makes it pretty painless).
By static I meant go and rust dependencies bundled into the executable. Dynamically linking to libc is ok with me, any system I run on has a usable libc.
Though it should be noted that when you compile such a binary on a system with a newer glibc, it will not work on a system with an older glibc. To be fair this is basically the case with C as well (you can work around it with .symver but it's kind of dodgy), but it is worth keeping in mind.
Yes, this is true for a great many things. If I compile these pseudo-static binaries for use on multiple different linux distributions or libc versions, I compile on the oldest/lowest common denominator so that it runs everywhere I need it to.