Fat binaries solve one of the problems which Docker containers solve. It doesn't solve the security isolation problem, or the resource control issue. That bei

Fat binaries solve one of the problems which Docker containers solve. It doesn't solve the security isolation problem, or the resource control issue. That being said, there are many people who are using Docker primarily to solve the DLL hell problem of shared libraries. And containers don't really provide that great of a solution as far as security is concerned; VM's will also be more secure. And the statement that the Go language is the pioneer for fat binaries is, well, just wrong. People were using static binaries (with, in some cases, built-in data resources) to solve that problem for literally decades. MacOS, for one. I also remember working with one of the eventual co-founders of Red Hat back when MIT was interested in a proprietary math analysis tool for SCO, but which we were planning on running on Linux. MIT had purchased a site license, which he was going to implement by checking the network address to see if it was 18.x.x.x. He was going to provide a statically linked SCO binary that had this check. The funny thing was that his development system was Linux (it was more developer friendly), and he was cross-compiling to create a statically-linked SCO binary --- which we were then going to run on Linux using SCO emulation. But that statically-linked binary was basically a "fat binary", which would work on any system (including any Linux distribution) that supported the set of system calls SCO used. (Ah, the early-90's, before Red Hat was founded and before IBM had "discovered" Linux, were simpler times....)