Go support for Android

https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_OjjnjVKxgeVBjIsTr5qIUcA4/preview?sle=true

by myko • 12 years ago

358 156 12 years ago

docs.google.com

dmoy• 12 years ago

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?

gtremper• 12 years ago

They seem to release an update every ~6 months, so probably around the end of this year.

axaxs• 12 years ago

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.

srcreigh4• 12 years ago

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.

kyrra3• 12 years ago

Being planned and discussed right now.

https://groups.google.com/forum/m/#!topic/golang-dev/eqBihsj...

howeman2• 12 years ago

December 1st. 1.3 slipped by two weeks but 1.2 was on the money.

fidotron2• 12 years ago

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• 12 years ago

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.

rational-future• 12 years ago

C# lets you develop games that run on Windows, OsX, Linux, Android, iOS, Windows Phone, Xbox and PS, while sharing all non-UI and parts of the UI code.

yzzxy2• 12 years ago

I think this is 90% a result of Unity.

CmonDev3• 12 years ago

It's the best modern language overall (if you count everything: IDE, APIs, language design, cross-platform capability, capital backing, reach, approachability).

Also XNA is reborn as MonoGame. Microsoft wants to decouple from it's APIs and tools by offloading to OSS and third party (Unity3d).

pjmlp6• 12 years ago

Good desktop integration alongside P/Invoke, meant many game studios started moving their game building tools from C++/Qt/MFC to C#/Windows Forms/WPF.

So this way C# got a foot on the door, long before XNA and Managed Direct X came into the picture.

stcredzero3• 12 years ago

Go is interesting for game servers. Channels and selects are the shiznit! Not there yet, but has potential. Rust has even more potential.

themartorana2• 12 years ago

We've moved pieces of our game backend architecture from Python to Go, especially the bits that really benefit from high concurrency and possible parallelism. Moving the entire API is a monolithic task, but I imagine we'll eventually get there. But carving out the bits that need high speed, high concurrency (like sending 500 GCM notifications a second, for instance) really thrive.

Our client dev is all Unity, however, and I don't quite see Go entering our client dev cycle at all. And I'm a huge Go fan.

cageface2• 12 years ago

Go might be a good fit for game servers, but it seems like a completely uninteresting choice for game clients. I'd imagine game developers would either want to continue to work in C++ and leverage their existing skills and code bases or use a high level engine like Unity. The potential market for this seems quite small.

I'd really love to see Google throw some serious engineering muscle behind Rust, with the long-term goal of making it the default first-choice language for Android development. I'm not holding my breath for this though.

The design of Swift was somewhat hobbled by ObjC/Cocoa legacy requirements but it's still much better language for native client development than Java, IMO. Sooner or later Google is going to need a better story here.

andrewflnr2• 12 years ago

Having written a bit of Rust, I'm not sure it's suited to being the default language for any platform, simply because it's really hard; it forces you to plan the lifetimes of your data pretty carefully. If you don't actually need all the guarantees and performance Rust gives, it's quite possibly a better idea to go with a managed language. Not that I wouldn't like to see it be a first-class option, just not the first one you point the masses at.

I'd be happy to be convinced otherwise by someone who knows more. :)

jay_kyburz• 12 years ago

As a game developer I would be intrested in this. I would love to have my client and server code in the same language so I would not have to write things twice.

Having said that, I'm not at all interested in writing an app that was Android only so I'll be sticking with javaScript for a while yet.

Pxtl2• 12 years ago

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.

myko2• 12 years ago

Unfortunately they will not be mirroring the Android SDK in Go, but only the NDK bits. It's noted in the document that it would be too much of a bear to keep up with the official SDK, and an automated tool would generate crappy, non-idiomatic Go.

I think Dart or another JVM language are the only hope for getting away from Java on Android. Dart is maybe a longshot at this point though.

fidotron2• 12 years ago

The problem with Android isn't Java though, it's the Android API being an inconsistent hacked together in a hurry trainwreck. Everything they've added since 3.x has been an enormous improvement, but they never shook off the baggage of the initial push to release.

higherpurpose3• 12 years ago

I think it's "riskier" for Google to stick with anything Java related at this point. Even if it takes 5 years to make the switch, I think they should do it. They don't know what Oracle is going to do in the future against them. The recent win for Oracle has already showed them that they made a mistake not starting supporting Go 2-3 years ago when Oracle first sued them. This could end up costing them soon, but it could also get a lot worse. I think they can't afford not moving off Java. Plus, look how much excitement Apple caused with Swift for developers. They could do the same with Go for Android.

steveklabnik• 12 years ago

We build every Rust commit against Android already: http://buildbot.rust-lang.org/builders/auto-linux-64-x-andro...

I'm pretty sure that was contributed by Samsung.

kibwen• 12 years ago

Plus, Rust doesn't have exceptions any more than Go does.

shailesh• 12 years ago

Scala is also a good option. The g8 template for Android apps is at:

https://github.com/jberkel/android-app.g8

V-24• 12 years ago

I thought about Scala, but the Scala plugin for Android Studio is rumored to be buggy and Scala doesn't integrate well with Gradle build system. At least I couldn't get it to work and I gave up after a while. If they (Google) wanted Scala to be supported on Android, they would make sure it isn't such a pain. And some documentation - all I could turn to for help is a handful of random blog entries etc.

zak_mc_kracken2• 12 years ago

If you're writing C#, it's hard to believe you'd find Java challenging.

libria• 12 years ago

I'm reading into his comment that he dislikes the tedium of Java's verbosity e.g., getters, no var/auto, no LINQ, no delegates, etc.

skrebbel• 12 years ago

My guess is that that's his point. Java is easy to pick up, but the Android API is such a hurriedly-hacked-together piece of nonsense that it hurts.

Case in point: To make a list on Android, you need to jump through hoops, assign stuff to a "Tag" property (a field intended for hacks and workarounds), typecast your ass of, or if you don't do all that your list will perform absolutely shitty. So, the easy flow is a crappy, slow, buggy list. The "best practice" (which is not the easy flow, because hey, why would we make good stuff easy) is a "View Holder Pattern" [0] that involves using intended-for-hacks framework features.

On top of that, to my feeling there's also a big difference in quality between the enterprisey Java ecosystem and the Android ecosystem. Android-o-world is full of not-entirely-good advice and bad examples. Jumping into Android reminded me of past PHP experience: lots of well-meaning, but ultimately not-very-experienced people set the tone. Enterprisey Java might have AbstractFactoryFactoryProviders, but at least they have no buggy/wrong/hacky/insane code with 300 stackoverflow upvotes.

[0] https://developer.android.com/training/improving-layouts/smo...

V-24• 12 years ago

Java's datetime API and (to some extent) collections were a cultural shock to me (coming from a .NET background) :)

That's why there are all these crutches like Joda, Guava etc.

michaelsbradley• 12 years ago

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

More recently:

https://mail.mozilla.org/pipermail/rust-dev/2014-June/010323...

https://github.com/rust-lang/rust/wiki/Doc-building-for-ios

zanny• 12 years ago

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.

CmonDev3• 12 years ago

Rust is a browser development language. Maybe he doesn't want to bother with memory management. Besides, is there a modern IDE for Rust (automated refactoring etc.)?

personZ2• 12 years ago

It sounds like Rust, right now, can build a library that you can use in an NDK app. Go, right now, can build a service or utility that you can use in any Android app.

http://goo.gl/mkCaJd

It isn't integrated, and as they note as one of the gaps, doesn't currently support CGO (meaning you can't compile C code or libraries in with your Go executable), but it has worked quite well for some time.

bratsche• 12 years ago

You could always try the Xamarin way. Basically the same APIs, but with nicer languages (C# or F# instead of Java).

zupa-hu• 12 years ago

Holy crap, how do you people live like this?

The hole point is getting advantages. Lucky us that it's hard; others won't keep pace!

Timmmmmm• 12 years ago

Yeah writing java for Android is a pretty awful experience. But it's not going away soon - this Go release will only have access to the things you can already do in C++ on Android. Namely, OpenGL, audio, and touch input. That's about it.

Anything GUI or system-related you have to do in Java. You won't be able to use Go to run other apps, enable wifi, receive GPS locations, communicate over bluetooth, etc. etc.

Qt is worth a look, but it's still not quite ready.

keithwarren• 12 years ago

As a C# developer, have you looked at Xamarin? I have done several apps with it, shared code between iOS and Android. I highly recommend you give them a try.

Infinitesimus• 12 years ago

Another .NET dev here in the same boat as OP. I really want to play with xamarin but the cost puts me off :(

notatoad• 12 years ago

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?

rch• 12 years ago

"Engineer at Google"

http://zentus.com/

Aaronn• 12 years ago

All you have to do is search "David Crawshaw", the first result is a Linkedin profile for someone who works at Google and the third result is a GitHub user that is part of the Google and golang organizations.

crawshaw• 12 years ago

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

howeman2• 12 years ago

Nice to have you be less internal!

danielrakh• 12 years ago

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

Gigablah• 12 years ago

Hint: it's not due to the documentation.

mahyarm• 12 years ago

Apple had a 3 or 4 year lead time, Go was a project to make better servers.

rdtsc2• 12 years ago

As someone else already said, this should not be Go it should be Dart.

Go in this case is seen sort of an in-between C and Java. But Go is not really as fast as C as much as we want it to be. So I don't know. Maybe it will be useful for something already written in Go to be ported. But I would rather see Dart succeed as a higher level-than java development language (both on Android and on the Web).

Years back I hoped Python would do that (being Guido was at Google and all). But as he confessed there was a minor political struggle internally over it and Guido lost. Not too long after he left Google.

oscargrouch3• 12 years ago

Go is more of a community driven technology.. more in the unix way style, i think google endorse it, but unlike Swift, i think they dont have a marketing department, official budget and the like.. so i think the comparison is pretty unfair

zak_mc_kracken2• 12 years ago

And then people wonder why Apple is able to attract so many developers to their platform...

There are quite a few more Android developers than iOS ones, not sure what point you are trying to make.

Go will probably have zero impact on Android but Java has certainly been instrumental to Android's success.

sgarman• 12 years ago

I have been dying to find an Android dev who has at least written a real app but I'm overflowing with iOS devs. Any advice where to find these guys?

djur• 12 years ago

There are quite a few more Android developers than iOS ones

Do you have a source for this? My observation is that it's much easier to hire iOS developers than Android developers.

cromwellian• 12 years ago

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.

kyrra3• 12 years ago

Agreed. And to add, Swift is designed and marketed as an osx and iOS language. Golang still mainly targets CLI tools or server programs. If you look at how Go progresses, some of the devs on the team seem to be able to choose the feature they will work on and move it forward. This seems to be the effort of one man getting this initially working. If it pans out, they may throw more resources at it.

millstone• 12 years ago

And Go was started in 2007! 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.

esolyt• 12 years ago

This is the price you pay for open source, you get to see things in an immature state which evolve over time.

Quite the opposite.

Wouldn't there be more people to write books and to work on SDKs when a language is openly developed?

higherpurpose3• 12 years ago

It's pretty obvious they've just now considered adding Go to Android, and have just begun working on it. I'd like to think it's in part because of my constant pestering on HN about Google supporting Go in Android.

kisielk2• 12 years ago

You're comparing apples to automobiles. The documentation and video accompanying the Swift announcement was the official promotional materials and guides. The document linked here is a development proposal sent by a developer to the golang-dev mailing list outlining his intentions to work on a feature for the next release.

ahoge4• 12 years ago

Go also has documentation. Also, Go has a spec. Swift doesn't. That's a pretty big deal, don't you think?

Android is fairly open. You can run whatever you want on that platform. If you want to use LuaJIT, no one can stop you.

Also, this isn't "Google". It's one guy working for Google. He's on the Go team. He wants to make Go a viable option for games on Android.

If you like Go, this is a good thing.

pjmlp6• 12 years ago

Swift has a spec. Just go to Apple developers documentation.

bane• 12 years ago

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

eddanger• 12 years ago

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

Zigurd3• 12 years ago

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?

hrjet4• 12 years ago

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.

Zigurd3• 12 years ago

I just finished editing in step 6 and saw your comment after I hit update.

Currently, ART uses Dalvik bytecode as a platform independent intermediate representation. I wonder if Dalvik bytecode is ideal for that purpose.

grey-area2• 12 years ago

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.

blinkingled• 12 years ago

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

micro_cam• 12 years ago

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.

steeve2• 12 years ago

Don't hold your breath for dynamic modules. Basically it's the whole binary into a .so file for loading in Dalvik. The whole Go program is in that .so file.

Look at go-android (already working for quite a while).

srcreigh4• 12 years ago

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

fatihpense• 12 years ago

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

napolux• 12 years ago

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

juliafayre• 12 years ago

Interesting!

xkarga002• 12 years ago

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.

shadowmint2• 12 years ago

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.

izacus5• 12 years ago

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.

shadowmint2• 12 years ago

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.

steeve2• 12 years ago

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• 12 years ago

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.

kriro• 12 years ago

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)

srcreigh4• 12 years ago

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 [2]: https://www.youtube.com/watch?v=f6kdp27TYZs [3]: http://blog.golang.org/concurrency-is-not-parallelism [4]: http://blog.golang.org/advanced-go-concurrency-patterns

Naks• 12 years ago

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

marcoms• 12 years ago

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

kvmosx• 12 years ago

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.

macspoofing• 12 years ago

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

Go support for Android

Related Stories