> Not sure why Google doesn't invest in their own language.
Has no one in this branch of the thread ever heard of a little thing called Go?
You could also bring up Dart, although Google's apparent commitment (and my own interest) in that is far lower.
Work IS coming along on being able to write full Android apps entirely in other Google-originated languages. You might reasonably ask why they're not pouring dramatically more resources into accelerating that process. I don't know, but I can only speculate that the enormous scale of the existing Android ecosystem makes it risky to send the wrong signal prematurely.
If we're looking at a matter of years before full featured Android apps in pure Go is feasible, then you probably wouldn't want to talk that up TODAY. The perception would be that Java on Android is dead, and major new app development for Android would halt.
Go isn't suitable for the kind of mission critical and memory constrained apps that Android requires.
The absence of generics and exceptions makes Go a step backward compared to Java. It was also absolutely not designed for Android (its driving design goal was to compile fast).
Dart's type system is also much weaker than Java so it would be a step back as well.
Right now, Google doesn't have any in-house credible alternative language to Java.
Interestingly, Kotlin is growing on Android without Google having anything to do.
Dart is a pretty nice language, and practically speaking I don't think it's "weaker" (optionally typed) system is a concern. The vast majority of Dart libraries are typed, giving you all of the benefits (compile time type checking, runtime type checks, intellisense, etc.)
Check out the flutter project (http://flutter.io) for a hint of what Dart on Android and iOS looks like.
I've been working professionally with Java for 19 years. I've only worked "semi-professionally" with Go for 3 or 4 years, as a secondary language for a few niche applications at work and some personal projects at home. So I may or may not be the most qualified person in the world to represent Go here.
All that being said, the longer I work with Go, the less I really see its lack of generics as a significant shortcoming. Go simply doesn't emphasize object-orientation to the same degree as idiomatic Java. Given the choice, I'd prefer to have that tool available than not have it. However, I haven't yet personally run across a real-world scenario in which lack of generics was an actual big deal.
I am QUITE comfortable in asserting that Go's error handling exceeds that of Java's, not lags it. The "try-catch" concept is still there (as "panic-recover"), albeit discouraged in many of the cases that an experienced Java developer would want to use it. The convention of having every function return a possible error struct, and the compiler's insistence that you do something with that that returned struct, pushes Go developers into a much more disciplined mindset of approaching exception handling.
The two points above are subjective, of course. Reasonable people could argue them either way. The third response is a bit more objective. Regarding the notion that Go is "absolutely not designed for Android" and its memory constraints, I must point out that neither is Java! As a matter of the Java language's syntactical suitability, the obvious observation is that Java PRE-DATES Android by more than 12 years. Considering the laws of physics and space-time, it was clearly not designed by James Gosling with Google's OS in mind. Secondly, the memory constraints of carrying a built-in garbage collection runtime also apply to Java. The only difference is a matter of maturity, and the level of resources that have gone into developing a custom Java solution for Android. There's no reason why Google couldn't do the some with Go (or almost any other language), and given Go's comparative simplicity it would probably take far less time to get there.
Sure, you can assign returned errors to the underscore black hole and move on. However, that is still consciously and deliberately "doing something" with it.
It is glaringly obvious in a code review that you have done this. Also, although I'm not personally familiar with any Go tools similar to PMD or Sonar in the Java world... it would be fairly easy to write a static analyzer that could scan code, recognize this pattern, and report on it (along with other code smells) in an automated manner.
Nevertheless, idiomatic Go functions return an error structure, and you must do something with that error structure. There is no ambiguity as to where the error structure came from.
Contrast that with Java's model, which is much more (pardon the expression) catch-all. There is endless debate on how wide or narrow to make your try-catch blocks, when to handle an exception locally vs. throwing it back to the caller, etc.
It is very common to deal with bugs that stem from silently "swallowing" exceptions at an inappropriately low level. It is just as common to see patterns where nearly all methods throw nearly everything without a catch at all... and there's a monster try-catch block at the top level catching the base "Exception" class.
Worst of all, there are entire classes of runtime exceptions which are NOT declared as throwable in the method's signature. The compiler has no means of insisting that you do anything about those, because the compiler doesn't know which ones are possible during a given method call. Go's error handling model is safer and better thought-out in that regard.
When you think about issues stemming from Java's handling of checked vs. unchecked exception types, it makes a lot more sense why Go went in the direction it did. Also, why Go application developers are discouraged from using "panic-recover"... and why Go library developers almost always recover from panics and create error structs for passing back upstream.
Adding Go to the official SDK and providing official bindings.
Go team is just doing what everyone else does, by making use of the NDK and writing Go wrappers manually on top of JNI calls to the official Android APIs.
So far there have been zero interest from Android team to support anything other than Java. Even the C and C++ support is just to write performance code to be consumed from Java, not to write full blown apps.
They were never asked by Google to make a language, and as far as I've always known (feel free to provide a link that says otherwise) Google employees are allowed to spend some of their work time to work on side projects, I've never heard of Google only paying them to work on Go and only Go, please feel free to correct me on this as it's news to me.
Has no one in this branch of the thread ever heard of a little thing called Go?
You could also bring up Dart, although Google's apparent commitment (and my own interest) in that is far lower.
Work IS coming along on being able to write full Android apps entirely in other Google-originated languages. You might reasonably ask why they're not pouring dramatically more resources into accelerating that process. I don't know, but I can only speculate that the enormous scale of the existing Android ecosystem makes it risky to send the wrong signal prematurely.
If we're looking at a matter of years before full featured Android apps in pure Go is feasible, then you probably wouldn't want to talk that up TODAY. The perception would be that Java on Android is dead, and major new app development for Android would halt.