undefined | Better HN

0 pointspron8mo ago0 comments

> 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.

0 comments

Expurple8mo 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

pronOP8mo 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.

j / k navigate · click thread line to collapse