1. 24
  1. 3

    The Go team has been tracking this for, well, a while: https://github.com/golang/go/issues/6853

    If compilers are at all interesting to you, the trade offs you’ll see discussed in that and other linked bugs should prove fascinating.

    1. 2

      Very interesting indeed, although there is little information in the issue itself wrt why are the binaries growing. I’ll have to dig around when I get the chance.

      Reading the comments, I get the feeling that the growing size of compiled binaries is a kind of fait accompli but it’s going to be a pain for people wanting to use go with wasm.

    2. 3

      This is really a great write up. I assumed I knew the answer before reading (includes the runtime where others externally link a runtime ie jvm) but I was totally wrong. Glad I took the time to read it.

      1. 2

        70 MB is a 40% increase from 50MB, not a 140% increase.

        1. 2

          Not to sound too picky, but the large executables is one big reason why I haven’t dived into Go as of yet. I prefer one binary for one job, and when I have many small tools each weighing in at 1-2 MB it is unacceptable for me.

          1. 2

            I had the same problem with a Haskell thing recently. Generating 5 binaries, each with about 20MB of identical code in it (lots of libraries + the RTS) and a few kB of code specific to that one binary. Switched it around so that there’s one binary which invokes what would have been the entry point for each of the others, and the container image shrank by a hundred MB.

            I suspect this may be a big influence on Golang projects’ CLI interfaces - ever notice that Go projects seem to always have one binary that has a dozen “subcommands”? I would hardly call it a massive problem but it I’d mildly interesting.

            (If I really cared about having 5 binaries, I would have a ~5kB dynamically linked C program for each subcommand, which just calls execve() and does nothing else.)

            1. 1

              That’s a really good point! I also noticed that, regarding the subcommands.

            2. 2


            3. 1

              Recently noticed goweight to get a quick sense of where’s the fat.

              1. 1

                I wonder if we couldn’t have a way to have less descriptive error stacktraces. Eg move the Data to an external file like pdb files for visual studio or map files for minified js. Where debug symbols are move out of the binary. And instead have some minified version embedded where the data could be decoded using the file.

                However there probably comes still reflection into play too, so probably no :S