I've read, though I can't remember where, that a number of languages were under consideration.

But the Android team mostly came from Danger, and Danger used Java. So the Android team had considerable experience designing a Java VM for a device with very limited resources. Although Android never shipped on such a device, the design target was 200Mhz CPU, no GPU, and, IIRC, 128 or 256MB RAM. That's luxurious compared to a Danger Hiptop, which IIRC had only 32MB.

If you look at how many VM instances get started when an Android boots, it's pretty amazing that it doesn't take 15 minutes.

Also it enabled them to piggyback on a very mature toolchain by translating from Java bytecode to Dalvik bytecode as the last thing before packaging an app. At the time, XCode had nothing like the linting and refactoring Eclipse had. If they had a similar toolchain for Danger, that would be another reason to stick to Java.

The original G1 had 192 MB RAM total, i.e. including radio. For application system, 128 was available (including VRAM).

I played with a Sooner phone (the HTC development phone) and I remember it having 64MB of RAM.

I'm sure Java was chosen because it was the dominant smartphone programming language at a time.

And not for any actual good reasons.

And we (Android developers) still need to suffer through their poor initial choice of platform; things would be so much better if they exposed a C API as a first-class citizen of the OS, rather than making Java the only first-class way to access Android.

The original Danger Hip-Top also used Java. Rubin had already experience with that. They removed the part that sucked hard (MIDP) and replaced with their own implementation (Dalvik).

In 2009, I thought the same way as you do - that C API would be better. However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Today, we have ARM, Intel, MIPS implementations, that are all first class citizens. Compare that to the failure of Windows-on-ARM.

Yes, the Java language is nothing to write home about - but there is a lot of existing code written in it, so replacing that would be difficult. Designing another language that could use the same standard library, API semantics AND be effective on small devices is not that easy (for example, Scala and Clojure both bring their own large standard libraries, Clojure also runtime overhead, making them both unusable on small devices).

>However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent.

Just about anything would have been better than Java. I'm not a big fan of C#, but CLR would have been better. Even JavaScript would have been better. But an intermediate VM language (like the LLVM intermediate representation) would have been the best option, if CPU architecture targeting were the concern.

I do games, primarily. And writing games in Java (which is what Google tells you to do -- though they finally gave in to pressure and added the NDK) just sucks, because you have to ship the JDK when shipping on every other platform -- or you need to write your game twice.

So pretty much every major game uses C/C++ despite it being the ugly stepchild of Android. Google set up the dev environment so that you can add as many target architectures as you want, making your APK "fat", or alternately shipping various APKs with different architectures in them and letting the store pick the appropriate version. Which works, but is ugly.

C and C++ have been CPU-architecture-independent for a long time, and if they DIDN'T want to force the multi-binary approach, using LLVM to build to an intermediate language and compiling for each platform would have been an even better fix.

Intel and MIPS are not first-class citizens, by the way, because the NDK exists, and many developers still only ship ARM binaries. And while other platforms ship with ARM emulators, they're buggy: An app I'm currently working on just fails on MIPS, and there are few enough people with MIPS devices that the client decided to just not support MIPS (our build process uses libraries that aren't build using the Android.mk system, so I can't just add "mips" to the platform list).

> Compare that to the failure of Windows-on-ARM.

I don't think that failure occurred due to anything other than mismanagement.

The Win8 cycle produced many things:

    * An OS for desktop PCs
    * Under the hood improvements vs. Win7, like faster boot
    * A tablet UI
    * A tablet
    * A port of NT to ARM
    * A tablet based on the above which could only run code signed by Microsoft
    * An app store with a new set of APIs that nobody cares about

In a weird attempt to distinguish all of these bullet points they muddied the message. What was Windows 8 exactly? They produced oddities like a Windows tablet that won't run Windows programs (not even after a recompile), and a tablet UI that ran on desktops.

Imagine a world where they shipped some other combination of these bullet points. Example: A laptop running ARM and recompiled Win32 apps, with a UI that more resembles Windows 7. I'd argue (and argued at the time) that would be more successful than Windows RT.

> the Java language is nothing to write home about. Sure, but it is also not as bad as its reputation in hackerNews circles. With the right libraries (Dagger 2, Volley, GreenRobot/EventBus, ...) Java for Android can be quite productive (not to mention that IntelliJ also helps a lot). Kotlin could allow us to go even further and remove most of Java biggest weaknesses.

I object to the underlying assumption that it's OK to need to rewrite my app for every platform it runs on.

I want write-once-run-everywhere.

write-once-run-everywhere does not work for high quality apps. You can share some of the model code with something like J2objc, but I have yet to see a non trivial app fitting in 2 platforms UX principles written by some sort of write once framework.

Look at almost every top game on iOS and Android for examples of write-once-run-everywhere.

It's more true that GUI-heavy apps can be harder to get right, cross-platform. But it's a no-brainer for game development.

I am talking about apps, not games :) . Of course for games you want to use a cross platform approach, for example with unity. They are a very specific case though. For games : -you probably don't want to use the platform's UI framework (unless you game is extremely simple and even in that case it is probably not the best choice for crossplatform). -the platform specific layer is pretty thin. Google Play Games/Apple Game Center. Share achievements, tweet game events and that's it.

None of this applies to regular app though.

You have no idea how happy I am to no longer need to program for Android =D

Sadly.. still programming in Java (most of the time).. but one step at a time I guess

BREW. Oh dear god.