Hacker News Reader

Comment by gngeal | Hacker News Reader

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

View on HN

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