10 ms·

Go support for Android

358 points by myko 12y ago

dmoy 12y 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 12y ago
  They seem to release an update every ~6 months, so probably around the end of this year.
- axaxs 12y 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.
  - srcreigh 12y 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.
- kyrra 12y ago
  Being planned and discussed right now. https://groups.google.com/forum/m/#!topic/golang-dev/eqBihsj7x-k https://groups.google.com/forum/m/#!topic/golang-dev/eqBihsj...
- howeman 12y ago
  December 1st. 1.3 slipped by two weeks but 1.2 was on the money.
fidotron 12y 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 12y 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 12y 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.
  - yzzxy 12y ago
    I think this is 90% a result of Unity.
    - higherpurpose 12y ago
      Let's hope Unity will support Rust, too, then...and I guess Go now as well, if Google says they want it for games.
      - CmonDev 12y ago
        They don't even support the latest version of C#.
      - mcintyre1994 12y ago
        Would they have to be ported to Mono to be used for Unity?
      - themartorana 12y ago
Pxtl 12y 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.
- myko 12y 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.
  - fidotron 12y 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.
    - myko 12y ago
      Fair enough. Even some of the newer APIs feel slopped together to be honest. Android development does feel like a constant battle with framework bugs.
      - shakethemonkey 12y ago
        All android APIs tend to have a large number of methods, but there will be absurd omissions. Example, the WebView has no way to return its HTML contents. So it's difficult to implement your own caching mechanism. Or an even more absurd example, the android YouTube player has no .stop() -- it is simply inconceivable that a media player lacks a way to stop a video, but there it is.
deleted 12y ago
[deleted]
notatoad 12y 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 12y ago
  "Engineer at Google" http://zentus.com/ http://zentus.com/
- Aaronn 12y 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 12y ago
  I'm on the Go team. My work has been internal to Google up until now.
  - howeman 12y ago
    Nice to have you be less internal!
danielrakh 12y 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 12y ago
  Hint: it's not due to the documentation.
  - deleted 12y ago
    [deleted]
- mahyarm 12y ago
  Apple had a 3 or 4 year lead time, Go was a project to make better servers.
  - rdtsc 12y 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.
    - oscargrouch 12y ago
      I used to think like you too.. but after Jobs/Apple launched the iPhone the trend for jitted languages, as popularized by Java in the nineties is going down.. Because of the phones and batteries, AOT languages are more valued and even ordinary jitted languages are getting a AOT compiler.. ART for Java and even .Net So Dart would need to have a AOT compiler first to make it more appealing to mobile phones.. also i think a lot of apps would not like to be distributed in source code form.. So langs like Go now are on the rise.. its funny how technology trends change over the decades... not while ago it was all about dinamic languages..
deleted 12y ago
[deleted]
bane 12y ago
Okay, this could be interesting. I'm especially interested in how good the performance will be compared to Dalvik.
eddanger 12y 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 http://www.rubymotion.com
Zigurd 12y 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?
- hrjet 12y 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.
  - Zigurd 12y 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.
    - hrjet 12y ago
blinkingled 12y ago
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
micro_cam 12y 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.
- steeve 12y 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).
- srcreigh 12y 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-so-file-which-depends-on-other-so-file-with-versiob-no http://grokbase.com/t/gg/android-ndk/11ae9h0sm5/how-to-load-...
fatihpense 12y ago
I think title should be "Better Go support for Android NDK" Now it seems like a linkbait. I clicked and felt so...
napolux 12y ago
"it also makes it possible to use the same code to bind to languages like Objective C" Yeah, go for it. :-/
juliafayre 12y ago
Interesting!
xkarga00 12y 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.
shadowmint 12y 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.
- izacus 12y 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.
  - shadowmint 12y 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.
    - tormeh 12y ago
      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 12y ago
        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.
steeve 12y 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 12y 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 12y 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)
- srcreigh 12y 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 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
Naks 12y ago
I myself have been wondering why this is not their original plan with Go.
marcoms 12y ago
So is this basically the NDK but using Go instead of C? I was hoping I could not use Java at all...
kvmosx 12y 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 12y ago
I expect Dart to make it to Android (officially) before Go.

358 points by myko 12y ago

dmoy 12y 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 12y ago
They seem to release an update every ~6 months, so probably around the end of this year.
axaxs 12y 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.
- srcreigh 12y 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.
kyrra 12y ago
Being planned and discussed right now. https://groups.google.com/forum/m/#!topic/golang-dev/eqBihsj7x-k https://groups.google.com/forum/m/#!topic/golang-dev/eqBihsj...
howeman 12y ago
December 1st. 1.3 slipped by two weeks but 1.2 was on the money.

fidotron 12y 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 12y 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 12y 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.
- yzzxy 12y ago
  I think this is 90% a result of Unity.
  - higherpurpose 12y ago
    Let's hope Unity will support Rust, too, then...and I guess Go now as well, if Google says they want it for games.
    - CmonDev 12y ago
      They don't even support the latest version of C#.
    - mcintyre1994 12y ago
      Would they have to be ported to Mono to be used for Unity?
    - themartorana 12y ago

Pxtl 12y 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.

myko 12y 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.
- fidotron 12y 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.
  - myko 12y ago
    Fair enough. Even some of the newer APIs feel slopped together to be honest. Android development does feel like a constant battle with framework bugs.
    - shakethemonkey 12y ago
      All android APIs tend to have a large number of methods, but there will be absurd omissions. Example, the WebView has no way to return its HTML contents. So it's difficult to implement your own caching mechanism. Or an even more absurd example, the android YouTube player has no .stop() -- it is simply inconceivable that a media player lacks a way to stop a video, but there it is.

deleted 12y ago

[deleted]

notatoad 12y 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 12y ago
"Engineer at Google" http://zentus.com/ http://zentus.com/
Aaronn 12y 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 12y ago
I'm on the Go team. My work has been internal to Google up until now.
- howeman 12y ago
  Nice to have you be less internal!

danielrakh 12y 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 12y ago
Hint: it's not due to the documentation.
- deleted 12y ago
  [deleted]
mahyarm 12y ago
Apple had a 3 or 4 year lead time, Go was a project to make better servers.
- rdtsc 12y 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.
  - oscargrouch 12y ago
    I used to think like you too.. but after Jobs/Apple launched the iPhone the trend for jitted languages, as popularized by Java in the nineties is going down.. Because of the phones and batteries, AOT languages are more valued and even ordinary jitted languages are getting a AOT compiler.. ART for Java and even .Net So Dart would need to have a AOT compiler first to make it more appealing to mobile phones.. also i think a lot of apps would not like to be distributed in source code form.. So langs like Go now are on the rise.. its funny how technology trends change over the decades... not while ago it was all about dinamic languages..

deleted 12y ago

[deleted]

bane 12y ago

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

eddanger 12y 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 http://www.rubymotion.com

Zigurd 12y 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?

hrjet 12y 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.
- Zigurd 12y 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.
  - hrjet 12y ago

blinkingled 12y ago

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

micro_cam 12y 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.

steeve 12y 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).
srcreigh 12y 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-so-file-which-depends-on-other-so-file-with-versiob-no http://grokbase.com/t/gg/android-ndk/11ae9h0sm5/how-to-load-...

fatihpense 12y ago

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

napolux 12y ago

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

juliafayre 12y ago

Interesting!

xkarga00 12y 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.

shadowmint 12y 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.

izacus 12y 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.
- shadowmint 12y 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.
  - tormeh 12y ago
    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 12y ago
      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.

steeve 12y 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 12y 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 12y 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)

srcreigh 12y 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 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

Naks 12y ago

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

marcoms 12y ago

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

kvmosx 12y 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 12y ago

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