Go supports shared C libraries- people have linked it against things like SDL and GTK+.
I'm not so sure it's really necessary for new things. Disk and memory are now cheap and plentiful enough that most of the advantages of shared libraries don't outweigh the advantages of static ones.
I'm talking about being able to call into Go code comprising a shared library via some sort of C calling convention. What you're referring to is something almost any modern language can do, which is call a C library via some sort of library loading mechanism (ctypes, FFI, etc.).
You can see a recent proposal for shared library support in Go and some reactions here:
So unless what you're talking about has happened in the past few months, I'm not aware of true shared library support in Go.
Practically speaking, shared library support is absolutely necessary if you're looking to use a low-level language as a means of speeding up a dynamic language. Or least highly-desirable (you can use IPC, but you lose a lot of speed, which is often the reason why you're using the lower-level language in the first place).
One advantage of shared libraries is that applications that link against them benefit from bugfixes when the system updater updates the library. (Well, it might also cause regressions, obviously.)
On the other hand, applications also "benefit" when the system updater introduces breakage (library incompatibilities, regressions).
To be clear, D can use the shared C libraries of your system just fine since the beginning.
When D people talk about shared library support, they mean: create a D shared library, which is used by C/C++ code. The tricky part is stuff like initializing the runtime.
...which is of zero importance to the primary users of Go, i.e., Google, as they have a unified code base.
But nobody prevents the Gccgo people from implementing their implementation differently. (It's just that for Google, this is really not a pressing issue.)
The traffic on the mailing list might lament the inconsistent state of Rust on ARM in general, but AFAIK Android should work ( https://github.com/mozilla/rust/issues/1859 ). For pointers, I encourage you to either post to the mailing list yourself or check out the IRC channel (#rust on irc.mozilla.org).
Go is a language. There's no problem with dynamic loading as such; it's just that the primary implementation uses static linking for convenience. You'd simply have to write a dynamically loading runtime (and come up with some semantics for dynamic loading, which sounds tricky but probably can be handled somehow). The simple-yet-efficient model of implementing Go would require some things to be taken care of - for example, the method dispatch tables.
Also, "Android only uses dynamic loading" - given the existence of NDK, how is that true? As far as I know, you can link statically whatever you want.
> Go is a language. There's no problem with dynamic loading as such;
True. However the ones responsible for writing the main compiler are against providing such support on the official compiler toolchain.
> Also, "Android only uses dynamic loading" - given the existence of NDK, how is that true? As far as I know, you can link statically whatever you want.
The NDK only produces shared objects as final binaries. You are allowed to produce static libraries to link on your final .so, but that is about it. You cannot produce pure executables.
The code compiled with the NDK is loaded and executed from a DalvikVM instance.
The NativeActivity that so many people without NDK knowledge think is native code, is actually a Java class that inherits from Activity, loads the produced .so and delegates the Android events into native code.
I'm not so sure it's really necessary for new things. Disk and memory are now cheap and plentiful enough that most of the advantages of shared libraries don't outweigh the advantages of static ones.