[matrss]

I agree with this being an issue, although certainly less pronounced with go compared to other languages. I don't think containers solve the issue though: none of the mainstream approaches to building containers actually make the builds (and by extension images) inherently reproducible. It just shifts the issue from differing host systems to differing base layers (granted, the issue is less pronounced with those). As long as not every dependency is fully pinned your builds could break any day and arbitrarily between machines, if you don't build at least at the exact same time.

To solve the issue fully you need a more comprehensive approach to packaging. nix or guix can provide that.

Containers are more useful as a software distribution mechanism.

[flimsypremise]

I would say that containers are the foundation of the practice of reproducible builds. They don't solve the problem on their own, but containerization is a core element of the best practice of reproducible builds, along with utilization of lockfiles and infrastructure as configuration. It's certainly a hell of a lot easier to get a containerized application to a reproducible state than one run on a local machine with an unknown architecture and OS.

[matrss]

> I would say that containers are the foundation of the practice of reproducible builds.

If you mean containers as in the isolation features that are utilised by docker et al. to provide their flavor of compartmentalization then yes, those are pretty useful for reproducibility (although not 100% necessary, I think).

If you mean containers as in a bundled linux userland (so, e.g. a docker container running some image) then no, that is entirely orthogonal to reproducibility, as demonstrated by nix and guix which AFAIK use the low-level isolation features for their build sanboxes but do not have anything resembling a container image involved.