Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.
Interop with existing libraries is certainly a worthy enough feature to add to the Go toolchain, and it's an optional feature, so ease of deployment is still a primary concern, but if you need DLLs, this is available.
Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compilation took a long time.
Sure, if you're running on a raspberry pi, a few megs here and there might actually matter... but even my phone has 2gigs of RAM and 32gigs of disk space.
The nature of the modern computer is that cpu speed has increased more than memory speed, so if your data doesn't fit into cache your cpu will be do nothing quickly.
Even with shared libraries, this phenomena has such an impact that the Linux kernel now has a memory de-duplication feature (mostly for VMs):
The size of the binary is completely irrelevant when considering if the code fits in the CPU cache. What's important is the size of code that actually executes. Dynamic linking changes nothing.
That's not at all surprising considering that with static linking, each package is also built only once.
OTOH, it does well with the culture of making a lot of small, specialized executables rather than a single, monolithic application.
My point was rather that a 3MB executable used to be "large" and now it's not, even if you have 100 of them.
I don't know the background on this choice, but I've spoken to a few Go shops that have complained about memory usage when running a bunch of different Go binaries on the same machine, so hopefully this will help there.
However, this will probably deprecate or diminish the RPC and code generation techniques for implementing plugin architectures.
I was lucky enough to be able to use Native Oberon back in the day.
(raises hand) The well-documented, portable, simple OS and toolchain written by people with no interest in subversion available online for free? Not quite an Ubuntu but more usable than most things people were proposing (eg microcontrollers with hand-written Forth lol). I also thought Modula-2 or Oberon might make a good target for high level languages such as ML or Haskell if we're doing end-to-end safety arguments: one's claims can build on the others.