Because go is significantly safer and more productive (of course this depends on the developer in question but on average) and using the ndk with c/c++ for serious development on android is absolutely one of the worst modern platform development experiences out there.
using the ndk with c/c++ for serious development on android is absolutely one of the worst modern platform development experiences out there.
I have to second this. Serious attempts to use the NDK for application-layer work will turn your hair white. It's by far the most god-awful mobile/quasi-embedded tasks I've had professionally. In my experience it's second maybe only to porting C-decompiled FORTRAN between families of obsolete and badly documented DSP chips.
Because it would suck. Android is about app modularity and inter-app cooperation. It is about installable services with high and low-level APIs. It is about handling multiple screen geometries not just with conditional layouts, but also with code reusability in Fragment objects. Skin-deep UI "portability" results in a lowest-common-denominator experience.
I did it, its trivial. The magic sauce is all in the use of the #cgo directive, which gives you a way of exporting Go to iOS code and vice versa. I ported IPFS (http://ipfs.io/) as a test, and it runs quite well on iOS:
This is the glue that the Go compiler needs to export its symbols in a way that they can be used from the C side of things in Objective-C, and vice versa. Think of it like a toll-free bridge [ * ] between the ObjC and Golang runtimes.
Comments
Why not write it in C and slap on the native cocoa/win/gtk/android front end and have something totally "portable" to mac/ios/android/windows/linux?
Because go is significantly safer and more productive (of course this depends on the developer in question but on average) and using the ndk with c/c++ for serious development on android is absolutely one of the worst modern platform development experiences out there.
I have to second this. Serious attempts to use the NDK for application-layer work will turn your hair white. It's by far the most god-awful mobile/quasi-embedded tasks I've had professionally. In my experience it's second maybe only to porting C-decompiled FORTRAN between families of obsolete and badly documented DSP chips.
Because it would suck. Android is about app modularity and inter-app cooperation. It is about installable services with high and low-level APIs. It is about handling multiple screen geometries not just with conditional layouts, but also with code reusability in Fragment objects. Skin-deep UI "portability" results in a lowest-common-denominator experience.
Why does nay of that restrict writing business logic in c or go, then just interfacing it in the Fragment or whatever?
It doesn't. But that's not what the parent comment was suggesting.
If you have anything compute-intensive enough to affect battery life in an Android app, you really ought to use the NDK, and Go will probably be officially supported: https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_Ojjnj...
Or if you want Android/iOS portability, find a common API for SQLite and implement in C.
How is go not portable to all of those platforms?
No doubt it's potentially portable. Can I compile a GO only program and run on ios?
I did it, its trivial. The magic sauce is all in the use of the #cgo directive, which gives you a way of exporting Go to iOS code and vice versa. I ported IPFS (http://ipfs.io/) as a test, and it runs quite well on iOS:
https://github.com/seclorum/ios-go-ipfs/blob/master/ipfsios/...
Is see stuff like 'cgo' and 'import "C"'.
What's going on here?
This is the glue that the Go compiler needs to export its symbols in a way that they can be used from the C side of things in Objective-C, and vice versa. Think of it like a toll-free bridge [ * ] between the ObjC and Golang runtimes.
[ * - See https://en.wikipedia.org/wiki/Bridging_(programming) ]
You dont need to do any of the cgo stuff manually anymore with gomobile