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.
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.
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.
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.
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.
>Apple designs something new, tries hard to get it right the first time, and commits to it completely.
Oh really? That must be why they removed all of their USB and HDMI ports to replace them with Thunderbolt ports. Anyway, let me get back to writing my IOS apps in AppleScript and hosting my website on my Xserve. While I'm doing that I'll being sharing my music listening habits will all of my friends on Ping.
The point of that is that they hardly ever commit to things as 'completely' as you imply. They just have a conservative marketing strategy where they won't release anything until much later than most companies would.
>Oh really? That must be why they removed all of their USB and HDMI ports to replace them with Thunderbolt ports.
That doesn't even make sense. Thunderbolt and USB/HDMI cater to different needs. When they added thunderbolt they DID take out their Firewire ports. And when they added USB they did take out legacy mouse, keyboard etc ports.
>Anyway, let me get back to writing my IOS apps in AppleScript
Again, doesn't even make sense. Applescript is a legacy language they maintain. Designed pre-OS X. Not something they actively designed for iOS or anything.
>and hosting my website on my Xserve
They would, if enough people were interested. They weren't, so they killed the product. Same for ping.
True re Google's experiments. Given there's one guy in charge of Android and Chrome/OS developers could use a clearer direction. Preferably an alternative to Java (Kotlin?) which can also run on Chrome OS.
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.