Go programs are not (generally speaking) statically linked, unless you're explicitly doing CGO_ENABLED=0, -tags 'netgo' and the whole variety of other tricks needed to coax static binaries out of the compiler. Try running "ldd" or "file" on your Go binaries -- most of the time they'll be dynamic objects and linked to glibc, especially if you're just doing a stock "go build".

In addition, Debian definitely does package Go programs -- they've packaged some of mine and they have possibly the most ambitious way of solving the great vendor/ issue (which most other distributions have ignored).

The likely issue with LXD is that they require specific versions of various system libraries that they package in their source code bundles (including a fork of sqlite3!). I packaged LXD for openSUSE[1]. It wasn't really fun, but it is fairly doable if you have a flexible enough view on "good packaging practices" (and I imagine Debian packagers didn't feel like going through all the necessary workarounds -- which includes patching the ELF binary in the openSUSE case). And note that LXD isn't even a static binary -- I tried to compile it statically to get around a whole range of issues and it was a nightmare.

[1]: https://build.opensuse.org/package/show/Virtualization:conta...

"Appimages are great but there's no sandboxing or updates"

Actually there is sandboxing and updates, if you want to take an extra steps.

I prefer AppImages over Flatpack and Snaps for essentially the same reasons commented above.

I typically launch them with Firejail for the sandboxing. i.e. "firejail --appimage /path/to/appimage" instead of just the appimage alone. Seems to work just fine. Firejail has additional options that can be done.

Some AppImage creators do provide an update method that can be installed using zsync2, but I've not tried it since the whole point is disposability.

> prevent statically linked binaries, like Go programs

What do you mean? There's debian go packaging team: https://go-team.pages.debian.net/ as well as go packages in stable (for example https://packages.debian.org/buster/influxdb)

> Appimages are great but there's no sandboxing or updates.

I know nothing about AppImages, but up above someone said they do have updates: https://news.ycombinator.com/item?id=23773878

Go also supports dynamic linking actually.

For the first part, I found Debian’s Maintainers’ Guide [0] pretty helpful when I was updating xscreensaver last year (hasn’t been uploaded yet though...). It also has a section at the beginning concerning how to adopt orphaned packages. For upstream updates, some projects will have a way to create deb packages themselves, which can make installation/updates easier later on (concrete example, with OpenZFS can create RPMs and debs from the upstream tree).

0: https://www.debian.org/doc/manuals/debmake-doc/index.en.html