> Go has never focused on binary size and probably never will unless it actually becomes an issue for Google.
The Go project moved to being community directed quite a few years ago. The community hasn't shown it desperately needs smaller binaries either, though. It'd take them, I'm sure, but there are more important concerns.
> That's the disadvantage of having a corporate BDFL I guess.
Even if we, for the sake of discussion, assumed that Google still only specs the language for Google needs, there shouldn't be anything in the specification that necessitates large binaries. tinygo has shown that they can be small. And now that Microsoft has its own Go compiler, Google isn't the only deep pockets involved either. But so long as it is not seen as a pressing concern there isn't apt to be anyone to step up and put in the work to close the gaps.
The Microsoft Go distribution is a special build for FIPS 140-2 compliance (replacing some TLS / crypto libraries and such). I do not believe that there are plans to make any other changes here.
The Go project moved to being community directed quite a few years ago. The community hasn't shown it desperately needs smaller binaries either, though. It'd take them, I'm sure, but there are more important concerns.
> That's the disadvantage of having a corporate BDFL I guess.
Even if we, for the sake of discussion, assumed that Google still only specs the language for Google needs, there shouldn't be anything in the specification that necessitates large binaries. tinygo has shown that they can be small. And now that Microsoft has its own Go compiler, Google isn't the only deep pockets involved either. But so long as it is not seen as a pressing concern there isn't apt to be anyone to step up and put in the work to close the gaps.