4 ms·
> But the point is that native, static binaries depend only on the kernel interface Many binaries also depend on shared libraries. > while the other programs
by pron 1y ago
> But the point is that native, static binaries depend only on the kernel interface
Many binaries also depend on shared libraries.
> while the other programs also depend on the language runtime that's installed on that OS
You can (and probably should) embed the runtime and all dependencies in the program (as is easily done in Java). The runtime then makes responding to OS selection/changes easier (e.g. musl vs glibc), or avoids less stable OS APIs to begin with.
- Expurple 1y ago> Many binaries also depend on shared libraries. Yeah, and those are also the opposite of "solid" :) That's why I qualified with "static". I'm so glad that Go and Rust promote static linking as the default (ignoring glibc). > You can (and probably should) embed the runtime and all dependencies in the program (as is easily done in Java). Congrats to the Java team and users, then. That makes it similar to the Go approach to binaries and the runtime, which I approve
- pron 1y ago> Yeah, and those are also the opposite of "solid" :) So if that's what the author meant by "solid", i.e. few environmental dependencies, then it's not really about "native" or not, but about how the language/runtime is designed. Languages that started out as "scripting" languages often do rely on the environment a lot, but that's not how, say, Java or .NET work. > I'm so glad that Go and Rust promote static linking as the default (ignoring glibc). That doesn't work so well (and so usually not done) once you have a GUI, although I guess you consider the GUI to be part of the kernel.