Hacker News Reader

Comment by krakensden | Hacker News Reader

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.

View on HN

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:

https://groups.google.com/forum/#!topic/golang-nuts/zmjXkGrE...

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).

I doubt Go will ever get it, given the religiosity against them from the community.

Replying to myself, since I can no longer edit.

From the gonuts-dev discussions, Go main toolchain might actually get support for dynamic loading in the future.

So I was wrong it seems.

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.)

> ...which is of zero importance to the primary users of Go, i.e., Google, as they have a unified code base.

And this is why Android will never get official Go support.

- Android only uses dynamic loading

- The Android team does not seem to care about Go

- The Go team is religiously against dynamic loading

So I bet D and Rust compilers will be able to support Android, before Google will support Go in the Android SDK.

Rust already supports Android, thanks to the efforts of Samsung.

Thanks for the heads up, I thought it was still not fully there from the mailing list traffic.

Do you have any pointers about it?

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).

I just found this,

https://github.com/mozilla/rust/wiki/Doc-building-for-androi...

it does not look like it is production ready, if this is really the latest state.

This is not something I can put into an APK.

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.

Again- go can deal with dynamic loading of native libraries just fine.

Point two- nobody is that interested- is the real thing.

> Again- go can deal with dynamic loading of native libraries just fine.

The problem is producing .so to be loaded by others.

Reply on news.ycombinator.com