3 ms·
...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 implementi
by gngeal 13y ago
...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.)
- pjmlp 13y ago> ...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.
- kibwen 13y agoRust already supports Android, thanks to the efforts of Samsung.
- pjmlp 13y agoThanks for the heads up, I thought it was still not fully there from the mailing list traffic. Do you have any pointers about it?
- kibwen 13y agoThe 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 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).
- pjmlp 13y agoI just found this, https://github.com/mozilla/rust/wiki/Doc-building-for-android 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.
- gngeal 13y agoGo 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.
- pjmlp 13y ago> 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.
- krakensden 13y agoAgain- go can deal with dynamic loading of native libraries just fine. Point two- nobody is that interested- is the real thing.
- pjmlp 13y ago> Again- go can deal with dynamic loading of native libraries just fine. The problem is producing .so to be loaded by others.
- pjmlp 13y agoReplying 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.