Hiding the complexity is not necessarily bad, but that decision should be made consciously. Some complexity is inherent to the problem space, some is accidental - but even the latter must sometimes be tolerated. So again, how do we draw the line?
My point was that a sane system package manager has maintainers for the packages and should not accept to ship a full OS in a single package.
Consider:
apt-get install myapp
CGO_ENABLED=0 go install example.com/myapp@latest
Also consider that the former command merely installs a pre-built artifact - try building Chromium from source. How is this not hiding complexity?
> My point was that a sane system package manager has maintainers for the packages and should not accept to ship a full OS in a single package.
How do you make that choice? Where do you draw the line? Why does Emacs make the cut, but VS Codium doesn't?
Also you can go check the recipe of your package, and if you choose a distro that only ships open source software, then it gives you the sources that were used to built it. You can even build it yourself. But again those are not points that I believe go into a "static vs shared" debate. Or do you disagree with that?
> How do you make that choice? Where do you draw the line? Why does Emacs make the cut, but VS Codium doesn't?
That's a distro philosophy. That's all a distro does, and you choose the distro that you like. Some distros will ship everything they can, some will be minimal, some will ship only free software, etc.
IMO it is not the developer's decision how I want my software packaged. It's a distribution question. The developer should provide the code open source, and let package maintainers build it and ship it in their distribution. If the developer (and the language tooling) can make it easy for maintainers to make their choices, then that's good. On the contrary, when the language officially refuses shared libraries, I think it oversteps.