[rollcat]

"Sane" package managers is how you end up hiding the difference in complexity between installing a static Go executable, an Electron app, a C++ Gtk/Qt app, a Python app, etc.

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?

[palata]

I did not understand that. How is a system package manager hiding the difference in complexity between Go executables, Electron apps, etc?

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.

[rollcat]

> How is a system package manager hiding the difference in complexity between Go executables, Electron apps, etc?

Consider:

    apt-get install myapp

You have no way of knowing if this will install a bundled copy of Chrome or not.

    CGO_ENABLED=0 go install example.com/myapp@latest

You can be 100% certain that it will produce exactly one static executable (OR fail to build anything), that all dependencies are pure Go, inspect the SBOM, read the entire source (including the compiler, which is reproducible), and so on. There are certain ways to sidestep these guarantees, but these involve very dark magic and are non-portable.

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?

[palata]

Wait, you are defending multiple points at the same time: "only pure Go", "only open source", "reproducible builds", "static linking". Not that I disagree with all of that, but I think that they don't all go as an argument against shared libraries (shared libraries can benefit from reproducible builds, for instance).

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.

[rollcat]

> Wait, you are defending multiple points at the same time: [...]

I've been asking all of this time: where to draw the line between striving for simplicity, and just shipping software? How much complexity is acceptable because it's absolutely necessary, and how much of it is acceptable because we're busy doing more interesting things?

I keep pulling counter-arguments from both sides, because I don't think this line is clear. The closest thing we have to an objective measure seems to be the patience of the humans who have to deal with said software.

> The developer should provide the code open source, and let package maintainers build it and ship it in their distribution.

We're going a bit off topic here, but this has proven to be a poor model for many applications - see Linus' lament on trying to ship Subsurface builds for Linux, and his endorsement for AppImage.

Also: every single proprietary app in existence, which is a many-trillion-dollars industry.

> On the contrary, when the language officially refuses shared libraries, I think it oversteps.

Well that's an example of the practical trade-off that Go has made: they'd probably prefer to live in an ideal world, where you ship a static binary 100% of the time and completely refuse non-Go code, but instead they built cgo, which made C interop easy and practical.

[palata]

> I don't think this line is clear.

Well I agree: the line is not clear at all. It is a matter of use-case and also of preference. Hence my point: developers should let those who build and distribute the code decide what they want, and organize their code such that both work (usually it does not require a lot of effort from the developer).

> see Linus' lament on trying to ship Subsurface builds for Linux, and his endorsement for AppImage.

I would think that this is his preference. My preference is to be given the sources and to build it myself, which allows me to maintain a package for my preferred distro.

> but instead they built cgo, which made C interop easy and practical.

Yes, I think this is great! On the Rust side, is cargo-c an official project though? It doesn't seem like it...

[guappa]

> see Linus' lament on trying to ship Subsurface builds for Linux, and his endorsement for AppImage.

That's what happens when you use experimental libraries that are not ready for use. Your software goes into the "experimental" section.

He was in the wrong there, but likes to spin his own fantasy version of the events at conferences.