For people with super-custom kernels, static builds might use a custom syscall thinking its a syscall for a newer kernel. Further, it might not support their kernel version (libc-to-syscall mismatch).

Then there's the fact that I might have compiled libraries with certain options that a static compilation won't get, ever (such as native CPU instructions or other optimizations).

Even worse, static builds mostly use musl as the libc implementation, for which there are many issues (DNS issues, the fact that most openssl library tests don't pass and are disabled). I wouldn't trust musl/alpine/et al in production for "serious" things.

Static builds are __convenient__, but they shouldn't be the default.

They suck to maintain.

I love the fact that you can just update one single openssl lib and all installed apps use the updated version after a restart.

Static builds have their legitimate use-cases so maybe change that to "mandatory static builds". (iirc go support for dynamic linking is worked on and will become stable eventually)

JS executables with deno or bun aren’t terribly different from pyinstaller executables. Of course they’ve been made more convenient by being bundled with the toolchains.

> I wish Python had static builds!

while unusual in the "python world", there are more or less well supported ways: https://www.askpython.com/python/examples/compiling-applicat...

i'm sure go will support dynamic linking aswell sooner or later