
Go support for Android - myko
https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_OjjnjVKxgeVBjIsTr5qIUcA4/preview?sle=true
======
Pxtl
So I've finally been learning to write Android Java... and honestly, as a
C#/Python developer, I figured it would be easy to pick up. Holy crap, how do
you people live like this?

Yeah, I'll be trying out Go for Android. Give me an excuse to learn Go. Still
don't like the idea of going without generics and exceptions, but maybe it'll
surprise me. I figure we're all just biding our time until Rust is ready.

~~~
michaelsbradley
Rust is almost/ready for Android and iOS, granted that the language itself is
still in a state of flux:

[https://github.com/rust-lang/rust/wiki/Doc-building-for-
andr...](https://github.com/rust-lang/rust/wiki/Doc-building-for-android)

More recently:

[https://mail.mozilla.org/pipermail/rust-
dev/2014-June/010323...](https://mail.mozilla.org/pipermail/rust-
dev/2014-June/010323.html)

[https://github.com/rust-lang/rust/wiki/Doc-building-for-
ios](https://github.com/rust-lang/rust/wiki/Doc-building-for-ios)

~~~
zanny
You are still stuck using the GUI toolkits of the platforms in their native
tongues. I think Qt and Mono (so C++ and C# respectively) are the only
toolkits that support both of them with one code base.

~~~
lvh
Perhaps not so much a Serious UI Toolkit(TM), but anything that eventually
compiles down to GL would work too. This is how play-clj does it: binding to
libgdx, which eventually calls some OpenGL methods.

While I did jokingly say "Serious UI Toolkit", there's more than a few awesome
applications on Android that have very, very simple UI widget requirements.
Particularly games, which according to the article, they're focusing on.

------
notatoad
Is this an official project supported by either the Go or Android teams, or is
it just an independent developer planning to take on this challenge? Who's
David Crashaw?

~~~
crawshaw
I'm on the Go team. My work has been internal to Google up until now.

~~~
howeman
Nice to have you be less internal!

------
danielrakh
Apple releases a series of books with hundreds of pages and hours of video
using Swift, and Google releases a one page Google Doc proposing to use Go.
And then people wonder why Apple is able to attract so many developers to
their platform...

~~~
cromwellian
Swift has been in development since 2010 in secret. This is the price you pay
for open source, you get to see things in an immature state which evolve over
time.

~~~
millstone
And Go was started in 2007!
[http://golang.org/doc/faq#history](http://golang.org/doc/faq#history)

It's got nothing to do with open source. Instead it reflects the different
approaches taken by Apple and Google.

Apple designs something new, tries hard to get it right the first time, and
commits to it completely. Swift is the way to write for Apple's platforms,
period. It's appropriate for a "social media application, all the way up to a
high-performance 3D game." There's no doubt that Swift is meant to succeed
Objective-C.

Google experiments more, sees what sticks. Go, Dart, Dalvik, v8, NaCl... You
sure have lots of choices, but the relationships between these technologies is
unclear, and has the character of uncoordinated teams working in isolation.

~~~
izacus
Go was also never made to be used in context of Android - even more it doesn't
even have dynamic linking capability and was explicitly made to generate
completely static binaries for server deployments. Which is not compatible (at
least not without some serious hacking) with an OS which has full API written
in Java an requires JNI interface and boxing of every interaction for every
API call.

While Go is a feasible replacement for C/C++ for native parts of Android
applications (which are just normal Linux .so libraries linked against bionic)
it would be a terrible fit for main application language without a full
rewrite of most of the operating system (note that ART is certainly NOT a
magic bullet here!). Note here that native (NDK) code has practically NO
access to Android OS APIs (only APIs available are bitmap manipulation,
OpenGL, OpenAL and limited sensors access).

It's staggering just how many misconceptions and lack of understanding of
Android structure is there in those "Go for Android" threads.

For us Android devs pretty much three points would improve the Android
development experience:

1.) Add Java 8 language feature support to ART/Dalvik runtime. This would
clean up code immensely, especially in so concurrency and callback heavy use-
case as a mobile app is.

2.) Clean up Android APIs and fix broken implementations. Add modern
block/callback based APIs to replace listener-heavy code. Perhaps look at
RxJava design patterns for core Android APIs as well.

3.) Improve tooling. Not the code editors (IDEA/AS with Maven or Gradle are
decent enough), but the profiling tools, hiearchy viewer, tracing tools and
other tooling which wasn't touched in years and are SORELY needed for good app
development. Figuring out why a certain animation stutters right now requires
stitching together several partially working tools with poor documentation.

Note that NONE of those issues would be improved by adding Go as a language to
interact with Android and would just cause additional issues on Go/Java
boundaries.

~~~
srcreigh
Are you proposing that Java 8 closure syntax is the solution to deeply nested
callback code? Hopefully not---because that doesn't really follow IMO. A
proper solution for concurrency is to use the Actor model or something
similar.

~~~
izacus
It's a solution for tons of boilerplate code which appears when trying to do
patterns. Compare for example Reactive Extensions (which are pretty popular in
Android community for management of concurrency) and just how much more
verbose is Java 6 code with it's piles of anonymous classes vs. lambdas of
Java 8 or Scala. Even though IntelliJ IDEA can hide that boilerplate pretty
well, it's still tons of needles code you have to pollute your codebase when
you're implementing those modern patterns.

In short, what I'm saying is, that at the current state of Android,
implementing Java 8 features would bring simillar benefits than switching to a
whole other language without having to rewrite whole runtime and most of the
operating system.

------
Zigurd
> _Providing a Go equivalent to the Android platform is intractable._

It may be several step beyond what a small team could do in a short time, but
not intractable.

Shooting from the hip, the job looks like this:

1\. Add Go language and debugging support to the ART runtime environment

2\. Port the standard Go packages, using a single-architecture backend
modified to produce ART compatible binaries to bootstrap

3\. Add equivalent support for RPCs (AIDL) and Renderscript

4\. Build equivalent APIs for those in the android.__.__ packages that make
sense in Go, possibly taking this an an opportunity to redesign some APIs

5\. Create equivalents for the apache.__.__ and java.__.__ that don't have
equivalents or alternatives in the Go packages

6\. Splice in an intermediate representation and refactor the Go compilers to
be ART pre-compilers, or take the easy way out and compile go to a possibly
enhanced Dalvik bytecode

It may seem daunting that Dalvik and ART embody Java runtime support, and that
the current (near-future, really) toolchain goes Java -> Java bytecode (and
acquires a lot of Java-oriented tooling this way) -> Dalvik bytecode -> native
code precompiled for ART. But I do not think it would bloat an Android runtime
too much to add Go as a first class citizen. The build chain has become a
little awkward anyway with Dalvik bytecode as an intermediate step that making
a Go back-end that compiles for an ART-specific intermediate language might be
cleaner.

How do I put an asterisk in a comment here?

~~~
hrjet
Android apps are meant to be platform independent. A pure Java Android app
will run fine on both ARM (various flavours) and x86. I vaguely remember a
MIPS implementation too.

Without the intermediate step (bytecode), you are pushing the awkwardness to
every individual developer.

~~~
grey-area
Platform independence isn't really a big deal. Apple managed this just fine
with fat binaries, and you could have an analogous system on Android without
problems and a build chain that automatically cross-compiled (easy in golang).
Developers wouldn't even have to notice. The size of binaries is often a small
part of the total size of the app - resources tend to take up much more room.

The real problem would be porting all the current APIs. If Google actually
decided to do this though it would be a good opportunity to clean up the
current APIs and provide a new version free from legacy cruft. So it is
doable, but a fair amount of work to provide UI bindings etc.

The obstacles are more political and monetary than technical.

~~~
hrjet
Apple controls and chooses the hardware targets by itself.

Android is open and the potential number of hardware targets is limitless.
It's not just about the size of the binaries; the app and the programmer
should ideally be agnostic of the hardware. On an open-platform with closed-
source applications, the least awkward way to do this is to push the native
translation to the run-time.

~~~
grey-area
In practice, is the number of hardware targets larger than two or three? I
doubt it would be a problem for google to certify hardware targets.

~~~
tormeh
But here's the kicker: The number of targets is a variable. Google would have
to force developers to recompile for each new ISA. New ISAs keep getting
added, many of them ARM ISAs that are not mutually compatible.

------
fidotron
Intriguing. I'm not aware of much, if any, interest in Go in the games
community, but there we are. C# seems to have finally taken off big time.

What would be cool/interesting is if you can write half decent audio
processing code in Go for Android without the GC kicking in at the wrong
moment.

They're 100% right about the broader API though.

~~~
mfn
I'm surprised C# is gaining this much traction in the games community despite
the complete abandonment of both XNA and Managed DirectX by Microsoft.

~~~
yzzxy
I think this is 90% a result of Unity.

~~~
higherpurpose
Let's hope Unity will support Rust, too, then...and I guess Go now as well, if
Google says they want it for games.

~~~
themartorana
Likely not - C# seems here to stay on Unity3D, but speeding up execution
through tools like IL2CPP seem most likely.

[http://blogs.unity3d.com/2014/05/20/the-future-of-
scripting-...](http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-
unity/)

------
micro_cam
I've been following this and, for me, the real story here is .so support from
go which they need to implement to allow this. Previously the go run time has
expected to be the one running the main method. The changes to the runtime to
support android will also hopefully allow go to be used for things like
extending python or R.

~~~
srcreigh
> is .so support from go which they need to implement to allow this

.so support on Android is pretty broken even with C/C++ code. For example, do
you know the Unix versioned .so convention? Compile to foo.so.1.142, then
create a soft link called foo.so -> foo.so.1.142? Android doesn't support this
in general, even with C/C++ code (see [1] for discussion; my recent experience
with this issue is that it hasn't since been resolved).

[1]: [http://grokbase.com/t/gg/android-ndk/11ae9h0sm5/how-to-
load-...](http://grokbase.com/t/gg/android-ndk/11ae9h0sm5/how-to-load-so-file-
which-depends-on-other-so-file-with-versiob-no)

------
eddanger
I haven't tried Go programming. I really like all these alternate programming
languages/tools coming to all these platforms. Very cool. So many things to
learn, so little time.

However, I like Ruby. In that department, RubyMotion the popular iOS/Mac
alternate programming toolset is coming to Android. Seems the floodgates of
"use your language of choice" are opening...

If you are interested in alternate languages and tool sets for your
development I'd give this a look.
[http://www.rubymotion.com](http://www.rubymotion.com)

------
dmoy
I am excited for this, if only because it might finally give me a random
excuse to learn how to write code in Go. Does someone have more context on
what the timeline for 'go 1.4' is?

~~~
axaxs
In full disclosure, i'm a bit of a Go fanatic. But two things that led me to
the language.

1 - The tour. Seriously, just go through tour.golang.org and...you know Go.
From there it's just little tricks and best practices, many covered in
'effective go'

2 - It's a tiny language. That's a plus or minus depending on who you ask.

If you aren't new to programming in general, you can pick up the majority of
Go in a day I think.

~~~
srcreigh
I agree with everything axaxs has said here! The Go Tour and also the Rob Pike
/ Sameer Ajmani talks ([Advanced] Concurrency Patterns in Go, Concurrency is
not Parallelism) are all great resources.

------
shadowmint
It continues to amaze me that as people lay more and more interesting ways to
interact with android using the ndk, even _from within google itself_ , the
official word on the NDK remains; don't use this unless you really really have
to.

~~~
izacus
If you know anything about Android then this is obvious - crossing from Dalvik
to unmanaged code gives you huge performance penalties because you need to
rebox and (in alot of cases) copy memory as arguments are passed. It also
causes huge amounts of pain as you need to convert Java objects into something
compatible with your language.

For most cases it's just not worth it.

~~~
shadowmint
There are some good reasons not to use the NDK (like the rich android UI,
webview, etc); but performance isn't one of them.

The point I was making is that despite the downsides, even people from inside
google are using it now. Makes the android teams 'pretend ndk does not exist'
stance rather ironic.

~~~
tormeh
It doesn't. Native code is by definition code compiled for a specific ISA, and
Android is supposed to run on several ISAs, including ARMv7 and amd64. Native
code is cancer on the ecosystem when you look at it from an ISA diversity
perspective.

~~~
jnbiche
Native code runs on far more architectures than Dalvik, including
(particularly) in the embedded world.

And the NDK is a rather neat solution to the compilation issue. Once you've
set up the toolchain properly, different architectures are simply not an
issue. There's no architecture that Android runs on that doesn't accommodate
native code.

After all, don't forget that under a rather thin layer of Java, the native
code "cancer" is what is driving Android.

~~~
kllrnohj
Hogwash. If you are talking about _SOURCE_ portability, Java runs in just as
many places as C code, including in the embedded world.

If you are talking about _BINARY_ portability (which is what everyone was
actually talking about), then native code isn't portable for shit, whereas
Dalvik code happily runs on multiple flavors of ARM, MIPS, and x86 with
official or partially-official support.

Unless you are proposing that Android adopts a Goobuntu design of "compile
everything from source", then the portability of native code source is utterly
irrelevant. And if you are proposing that, you are hopelessly naive. Not to
mention you must really, really hate having battery life if you want to spend
over an hour compiling & installing, say, Firefox.

------
kriro
I've recently written my first toy app for Android (first mobile app) and it
was more challenging than I thought it would be. The API seems a little odd
but like I said first app so I'll have to get used to it.

Go has been on my radar since forever but I haven't written anything in it.
This sounds like a cool announcement. I think my next mobile experiment will
involve Apache Cordova though but now I'm tempted to give Go a shot (game is
fine with me)

~~~
srcreigh
In my experience with Android apps, I've almost never had to use the NDK. When
I did have to use the NDK, it wasn't because I wanted to code in C/C++---it
was because there were strong, open-source libraries written in C/C++ that I
wanted to use in an app (Though, I have no experience making games on
Android).

If you want to check out Go, then the Go Tour [1] and the various talks by Rob
Pike [2] [3] / Sameer Ajmani [4] are great resources. The Go Tour stands on
its own as an interest-building resource; the several programming exercises it
has you do are fun and challenging.

[1]: [http://tour.golang.org/#1](http://tour.golang.org/#1) [2]:
[https://www.youtube.com/watch?v=f6kdp27TYZs](https://www.youtube.com/watch?v=f6kdp27TYZs)
[3]: [http://blog.golang.org/concurrency-is-not-
parallelism](http://blog.golang.org/concurrency-is-not-parallelism) [4]:
[http://blog.golang.org/advanced-go-concurrency-
patterns](http://blog.golang.org/advanced-go-concurrency-patterns)

------
bane
Okay, this could be interesting. I'm especially interested in how good the
performance will be compared to Dalvik.

------
marcoms
So is this basically the NDK but using Go instead of C? I was hoping I could
not use Java at all...

------
kvmosx
This is great news, good to see Google building a mobile + desktop interface
with Go. Just like Apple did with Objective-C.

And yet with Go there is more use of it for CLI apps and web apps. Adding
mobile to that equation just makes it even more complete.

Good job Google.

------
xkarga00
That's really good news. I have been waiting for it for do long! Maybe Go will
prove not to be suitable for Android development but still the whole ecosystem
around will only gain from such an opportunity regardless.

------
Naks
I myself have been wondering why this is not their original plan with Go.

------
steeve
On a side note, it's already possible to build Android binaries with CGO as
long as you use the external linker. Just build for Linux + external linked
from the NDK.

~~~
4ad
You don't even need the external linker. Just build a normal linux/arm binary
with CGO_ENABLED=0.

What this proposal brings is access to the NDK APIs. You could run Go on
Android since over 4 years now.

------
fatihpense
I think title should be "Better Go support for Android NDK" Now it seems like
a linkbait. I clicked and felt so...

------
napolux
"it also makes it possible to use the same code to bind to languages like
Objective C" Yeah, go for it. :-/

------
macspoofing
I expect Dart to make it to Android (officially) before Go.

------
blinkingled
Just as I had thought they would go (pun intended) about it -
[https://news.ycombinator.com/item?id=7845660](https://news.ycombinator.com/item?id=7845660)

------
juliafayre
Interesting!

