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

[V-2]

I agree with your points. "Official", out of the box support for Scala or Groovy wouldn't hurt, either!

As for IDEs, personally I grew to prefer Android Studio to Visual Studio (well, no ReSharper), although I have much more working experience with the latter. Especially in terms of navigating around the project. VS native refactoring tools are very rudimentary, too, even in VS 2013 - not much seems to have changed in YEARS.

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