
Google, it's time – We want Scala for Android - phatak-dev
http://blog.madhukaraphatak.com/scala-for-android/
======
colig
Um, people have already been able to use Scala to make Android applications.
Just about anything that doesn't require dynamically generated JVM bytecode
can manage, difficult and error-prone as it is.

If we're talking about official support, then I'd rather Java 8 instead. And
beefing up ART even more.

~~~
mncolinlee
Technically speaking, Android doesn't fully support Java 6. It's only a
partial implementation of Java, since Java is overweight. The Android team has
been adding requested features to the SDK in piecemeal form.

With that said, you can already get Java 8 lambdas in Android using the
retrolambda project.

[http://zserge.com/blog/android-lambda.html](http://zserge.com/blog/android-
lambda.html)

~~~
jug6ernaut
How does this work with a jar which contains classes using java8 features?
Will it work in this situation or is it only for classes to be compiled? Can
retrolambda be applied in other situations to keep the java version at 6 but
use java 8 features?

------
remon
Who's "we"? How about we ask Google to focus on things the vast majority of
Android developers actually want? Java 7/8 comes to mind. Even if we're
looking for just an alternative Android dev language Scala probably wouldn't
even be in the top 10.

~~~
eklavya
What matrix are you using where Scala wouldn't make it in top 10? I would bet
it would be one of the top choices.

~~~
zak_mc_kracken
All the various language surveys that have come up these past months (RedMonk,
TIOBE, job boards, github popularity, etc...) put Scala in a distant #30-50
slot. Certainly not in the top 90% mainstream languages.

~~~
frowaway001
Number 14 on Redmonk.

[http://redmonk.com/sogrady/2014/06/13/language-
rankings-6-14...](http://redmonk.com/sogrady/2014/06/13/language-
rankings-6-14/)

"The next JVM language to learn" (Java-focused survey): Scala leads comfotably
with 47%.

[http://zeroturnaround.com/rebellabs/interview-with-
typesafe-...](http://zeroturnaround.com/rebellabs/interview-with-
typesafe-4-answers-about-the-past-present-and-future-of-scala-development/)

Apart from that, you are completely missing the context. People are not
looking for a random language, but for a language which is compatible with
Java and Android, allows gradual migration and protects existing investment.

Scala is the top-contender here.

~~~
zak_mc_kracken
"Next language to learn" is the kind of metric you'd use if you don't have
real numbers to your advantage. TIOBE lists Scala at 0.03% mind share, and
you'll get similar numbers if you look at other metrics (see my post above).

For Android, there are already more projects written in Kotlin and Clojure on
Android than on Scala, so not sure why you think Scala is the "top contender".

On top of that, Scala's upcoming adoption of Java 8 means that Scala on
Android is effectively dead for several years, until the Android team decides
to adopt Java 8 (since they're not even on Java 7, this might be a while).

Typesafe just doesn't care about Android, why would you take such a risk to
pick a language that is so poorly supported?

~~~
frowaway001
You are really getting a bit desperate ...

------
pinkyand
I agree that Google should add more languages to android. And while Scala is a
great language, it's very complex - so it won't benefit many of the less
skilled users.

A better language would be something with the simplicity and power of python,
but with good performance.Groovy could be one such language.

~~~
phatak-dev
Scala is not complex in terms of the language design. Most of features [or
complexity] come from the libraries.

~~~
nvarsj
Implicits? Compared to Java, Scala is not a simple language. I'd say Scala's
complexity is on the order of Haskell + Java syntax with additional glue on
top of that.

Not to say this is bad, it just means you need greater discipline when writing
software in Scala. A bit like C++ (yes, I went there! :-)).

~~~
frowaway001
The great thing is that as soon as people mention C++, it's immediately clear
that this person has not a single clue what he/she is talking about.

------
mncolinlee
Why not Kotlin? It's more like a modernized Java. It's closer to what Android
developers are used to and it already supports Android. It interoperates well
with existing Java code in your Android app.

Also, it has excellent IDE support, since JetBrains is behind it.

[http://kotlinlang.org/](http://kotlinlang.org/)

~~~
lmm
It's less mature than Scala; it has a smaller developer base or library
ecosystem, and it is missing many Scala features (higher-kinded types,
implicits). Most of Kotlin's features are already present in Java 8; if you're
going to go to the trouble of supporting two languages, it seems perverse to
pick Java and Kotlin when they're so similar.

~~~
curtis17
If Google can't resolve their differences with Oracle Kotlin could be a way
forward. Especially given the Android Studio connection.

------
programminggeek
I'm not sure the author understands why Java is the language in the first
place - there is an army of developers who knows how to use Java. Yeah, it
might not be the best language ever, but neither is C++ and neither is Scala.

For what Google is doing their choices were basically C++ or Java, there is no
other embedded, performant option that hits mass quantities of developers
worldwide. Every other language is either too niche, or not performant enough,
or doesn't have the features you would want. Sure, I guess they could have
done C#, but I'm pretty sure Google hates Microsoft, so that's not going to
happen.

iOS only has Objective-C because of NextStep and OS X. Otherwise, it could
very easily have had C++ or Java. Blackberry ended up with C++ for their
native toolkit.

Has there been a significant mobile platform that wasn't C++ or Java that
doesn't have some historical reason like Obj-C has behind it?

~~~
wes-exp
I think WebOS was going to use JavaScript.

The thing about Java and C++ is that they themselves are around for historical
reasons. Far better languages have already been proven out. But, it will take
a major industry player to move the masses forward on this. Apple's Swift
effort gives hope on this.

~~~
humanrebar
> Far better languages have already been proven out

For what they do, C and C++ don't really have serious challengers yet, not
that there aren't some promising contenders.

~~~
wes-exp
When I say proven out, I don't mean in the sense of being widely used; I mean
academically. In other words, I am trying to say that it's not a research
problem, it's a problem of, say, engineering and marketing to bring it to
reality. Cool language features are well established in academia (but tend not
to go anywhere due to entrenchment and industry complacency – in that sense I
would agree that they aren't 'proven').

~~~
tormeh
If Google says "This is the second official lanuage for Android" I bet any
adoption issues would go away a la Swift.

~~~
programminggeek
Google would need to do this internally. Good luck convincing the 10,000
developers inside of Google stop using Java. Sure, they aren't all on Android,
and there are plenty of people using Go, or Dart, or Python, but moving a
company culture that large away from Java doesn't happen overnight.

Obj-C to Swift won't happen overnight at Apple either, but it is much more
likely to happen because they've been gradually working towards it for years
now with LLVM and such.

------
TeeWEE
Please not scala! I prefer to have clojure for android. Scala is too complex,
to ugly, and tries todo too much. Its also to heavy for android (it needs tons
of libs to run).

~~~
Cyph0n
Clojure would be too large a leap syntax-wise I think. Scala at the very least
gives you both FP and OOP in the same language.

~~~
adambard
Perhaps, but some people have built pretty amazing abstractions in Clojure. I
just found this tutorial, and was quite impressed:

[https://github.com/krisc/events/blob/master/tutorial.md](https://github.com/krisc/events/blob/master/tutorial.md)

~~~
phatak-dev
Similar abstractions implemented in Scala
[http://macroid.github.io/tutorial/BuildingLayouts.html](http://macroid.github.io/tutorial/BuildingLayouts.html)

------
DCKing
Over the last few months I've been writing Scala full time, and have even
written some (demo grade) Android apps in it. My opinion is: Android should
_not_ adopt Scala as one of its primary languages.

I think a platform's primary language should be accessible. It is an
unfortunate fact that the stuff that most people only know about programming
using some object oriented imperative language. People find it harder to hobby
with unfamiliar styles, and it is hard to find leverage within your
organization to go into unknown territory. If it isn't a popular widely known
language (Java) it should at least _resemble_ popular widely known languages
(Swift). Give people a piece of Java or Swift code, and they can read it. Give
people a piece of Scala code, and they usually cannot.

Scala _can_ be an accessible language; its imperative syntax is really nice.
But Scala _is not_ an accessible language in that idiomatic real-world Scala
and most of its libraries are written in a wholly unfamiliar style. Powerful,
yes. People should learn it, yes. But if Scala comes to Android it will only
serve to make the platform seem _less_ accessible. And that's a much bigger
downside than whatever expressivity Android Java currently lacks.

Scala can't even properly be a primary language in _parallel_ to Java at the
moment. Swift is just a better syntax for expressing idiomatic Objective C
programs. Good Swift programs should look mostly like good Objective C
programs with a different syntax - Swift has been made for this purpose [1].
Scala is _not_ a better syntax for expressing idiomatic Java programs. Despite
backwards compatibility, good Scala programs look very different to good Java
programs. This means that Google cannot present them as equivalents. The
Android platform APIs heavily promotes mutability which makes writing
idiomatic Scala code for Android a pain in the ass. Should Google ask people
to write non-idiomatic code for their new primary language, or should Google
provide new APIs for their new primary language?

I dislike Java very much. But I think it's a great language for Android,
because everyone can do it and that makes the platform accessible. There's
only one other language I can even remotely imagine in its place, and that's
Dart. And that's not happening either.

In the meantime, making Scala run on Android is perfectly doable. That is good
enough for me.

[1]: I'm aware that this comparison doesn't do Swift as much justice as it
should.

~~~
lmm
The advantages of immutability are real. At some point an improvement has to
be a change. Even if Google sticks with Java-only, I would very much hope they
will offer a more immutability-friendly API in parallel with the existing one.

Certain Scala libraries are indeed not accessible. But the trend is in the
right direction (there are better alternatives to requests now, and even
scalaz has become less symbolic in recent releases). If Google were to provide
the same APIs and sample programs that they currently do, those programs would
be as accessible as they currently are - probably more so, given Scala's
cleaner syntax. You say this could make Android less accessible. Maybe. But it
could also make Scala more accessible, providing a whole new class of
developers with a stepping-stone from somewhere very familiar towards these
valuable high-level features.

As the Python folks say, a good language should make easy things easy and hard
things possible. IMO Scala does both halves better than Java. It's just that
so far, people have mostly been using it for hard things.

~~~
DCKing
Google should do something about their APIs, sure. But they should do
something about their APIs _before_ doing something about their language.

The problem with Scala is not symbols or legibility (although that used to be
a major problem), but the fact that its programming style tends to be mostly
functional. Monads, for-sugar, implicits, immutability: stuff everyone should
master but in practice very few do.

> You say this could make Android less accessible. Maybe. But it could also
> make Scala more accessible, providing a whole new class of developers with a
> stepping-stone from somewhere very familiar towards these valuable high-
> level features.

The Android developers unfortunately have no interest in making Scala more
accessible. They have an interest in making Android more accessible. They
would have to make a lot of sacrifices to make Scala a primary language for
Android, and the benefits would be rather small from their perspective.

Scala's killer apps are on the server side. That seems to be going quite well
so far.

~~~
lmm
> The Android developers unfortunately have no interest in making Scala more
> accessible. They have an interest in making Android more accessible. They
> would have to make a lot of sacrifices to make Scala a primary language for
> Android, and the benefits would be rather small from their perspective.

Accessible is one thing, but not the only thing that matters, particularly as
the platform matures. If using Scala makes developers more productive, or
leads them to write less buggy code, that could be a huge advantage for
Android.

~~~
DCKing
If Scala makes developers more productive and code less buggy at all, it will
only do so for _some_ developers. Look at the investments required: APIs need
rewriting, apps need rewriting for the new APIs, people need to be trained
within Google, people need to be trained for it outside of the workplace, and
other people will still look at Scala code and stay behind confused.

And you need to do that for what? Because Java is too verbose? I hate (real-
world) Java as much as the next guy but I don't have any illusions on this
because the argument just doesn't add up and the effort doesn't seem worth it
by a big margin. It would be much more feasible if Google would release an
improved Android APIv2 with stronger immutability, first-class support for
Java 8 and its features (lambdas, Optionals) and no 64k DEX limit. That would
be a _huge_ improvement for both Java and Scala Android devleopers, and it
would also be _feasible_.

------
captainmuon
I want Python for Android.

Ideally, it would compile to Dalvik/ART or ARM. It would use something like
PySonar to infer types or use annotations to be able to use native types when
possible (for speed & correctness). When the type isn't given or can't be
deduced, it would fallback to boxed objects (like Nuitka does, in the way the
offically C-Python keeps its objects in memory).

But that is not neccessary, all that is needed is a decent wrapper to the
Android API for Python, and some packaging support. It is now already possible
to compile Python for Android to include it in your app. What I'd like to be
able to do is to write the whole thing in Python (+ a GUI design tool maybe).

I already see some people saying, that's not possible, because an interpreted
language uses too much resources (CPU, memory, esp. battery) for mobile. Well,
90% of the apps I use are not computationally expensive. The consume battery
mainly via network access, and via the screen, both of which is independent of
the language or runtime used. And when they are doing something
computationally intensive, it is usually the layout and drawing of the GUI -
most of which is done by the native framework anyway. Most apps are literally
just fancy listboxes and details pages, with a database and a web backend.
(The great exception are games, of course.) For these apps, a rapid
development language like Python (or Javascript, or heck, a new VB) would be
great, ideally augmented by good tooling. And if you have something CPU
intensive (map routing, image processing, complex translation etc.), you'll
just write it in a C library anyway.

~~~
waps
[http://kivy.org/](http://kivy.org/)

Best you'll get, and quite good.

------
pjmlp
It is not going to happen.

Google IO 2014, Android development fireside:

[https://www.google.com/events/io/schedule/session/85311b0e-7...](https://www.google.com/events/io/schedule/session/85311b0e-70ca-e311-b297-00155d5066d7)

The answer to this request is "Java is the _official_ Android development
language".

~~~
phatak-dev
Direct link to the question
[https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566](https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566)

~~~
smrtinsert
That wasn't linked correctly.

------
jug6ernaut
I would be happy with Java 7/8.

~~~
bni
I bet if Google asked Oracle nicely, it could happen :-)

------
trendnet
Why do people think that Swift has a managed runtime with garbage collection?
It has reference counting, it's compiled into native code. It has a small
runtime lib. linked into the executable (but hey, even C executables have it).

~~~
pjmlp
The younger generations grew with VM based implementations, never learned the
memory safe system programming languages that lost the market to C and C++ and
lack compiler design understanding.

As such, any language they see announced as safer than C and C++ must be VM
based.

------
WoodenChair
If they're not even giving us Dart or Go for Android (their own languages),
what is the probability they will give us _official_ support for Scala? Yes,
Scala runs on the JVM, and the former two don't. And yes, Go is not really
designed as an end-user GUI application building language. But Dart has a nice
VM of its own and is designed for client-side apps. I would like to see Dart
on Android and the original author is definitely confused when he calls Dart
and Go "niche" languages (as a way of dismissing them) and somehow doesn't
feel the same way about Scala. Scala might be marginally more popular than
Go/Dart but it's not an order of magnitude. In fact, according to the latest
Tiobe index (a terrible metric in my opinion, but one indicator) Go is more
popular than Scala by one place.

~~~
phatak-dev
Original author here

I don't mean disrespect when I say niche. I just mean in terms of community,
Scala seems to more diversified as it gets used in variety of fields compared
to Dart and Go. This is just view of mine.

------
zak_mc_kracken
The problem is that Scala generates very big jar files, which is why the only
couple of Scala Android applications I've ever seen are toy apps. There is no
doubt that any more sizeable project will blow up Dalvik's various
restrictions like is already happening with Scala apps without ProGuard.

There's also the fact that Typesafe doesn't care about Android so even if your
current app works on Android, a future version of the compiler might make it
blow up on the phone after you recompile it.

Unfortunately, the Ceylon team doesn't seem to be interested in supporting
Android either.

Which leaves Kotlin, as a reasonable option for non-Java development on
Android.

At any rate, don't expect any help from Google about Scala, they're not even
supporting their own non-Java languages there (Go, Dart).

~~~
frowaway001
> The problem is that Scala generates very big jar files, which is why the
> only couple of Scala Android applications I've ever seen are toy apps.

Yes, it's the same problem why compiling Scala to JavaScript is impossible ...
oh wait!

In both cases the standard library overhead is a few dozens of kB! The horror!

That's why nobody is using Scala.js or Scala-on-Android for anything serious
... oh wait!

That's already happening.

~~~
zak_mc_kracken
That's three strawmen in a row, none of them coming remotely close to
addressing the point I made above.

The web (scala-internals, scala-users, stackoverflow) is filled with threads
of people trying to run their Scala code on Android and being mystified by
fatal errors from Dalvik or DEX generation simply dying on them.

~~~
ebruchez
Maybe this could change if Google helped, don't you think?

~~~
zak_mc_kracken
Of course, but it's obvious they have zero desire to help support Scala on
Android. First because they don't use Scala at all internally and second
because even the languages that they created (Go, Dart) are not supported on
Android. If Android ever officially supports a language other than Java, you
can bet it will be one of these two.

~~~
ebruchez
By the way it seems that Dart is struggling to get any support at all within
Google. Also, it's not statically typed and bringing it to the Android runtime
might be much more effort. In short no, I wouldn't bet Go or Dart will be the
solution, not unless these languages change a whole lot.

------
general_failure
The article reeks of ignorance. Swift doesn't really have GC (but ARC) -
[https://www.google.com/webhp?sourceid=chrome-
instant&rlz=1C5...](https://www.google.com/webhp?sourceid=chrome-
instant&rlz=1C5CHFA_enUS504US504&ion=1&espv=2&ie=UTF-8#q=apple%20swift%20uses%20arc).
It also takes an unnecessary dig at nodejs. Has the author ever written
node.js production code? What bugs has the author found and filed?

I am sure most android devs rather have a major ramp up of the Android APIs
rather than switching the programming language. The real problem with Android
is the ungainly APIs and how very cumbersome it is to develop anything
reasonable.

~~~
th3iedkid
Adding more complexity to scala is its dependency on ASM for class file
creation [1] and more refined performance options like tail-recursion [2] are
implemented in a contrived fashion to make scala actually port to a non-
standard JVM like dalvik .However if things were to change from ground-up like
ARM actually made easy for functional programming.

These facts actually can make porting a performance application to scala quite
a job!

[1]:
[http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded...](http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/2012Q2/GenASM.pdf)
[2]: [http://blog.richdougherty.com/2009/04/tail-calls-tailrec-
and...](http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and-
trampolines.html)

------
TeMPOraL
Can we have a good Lisp for Android already?

~~~
emidln
Clojure sorta runs on it. It has various issues, but is usable. It's nice
having a repl into your phone.

~~~
mjn
There's also a commercial ($200) Common Lisp implementation that targets
Android (and iOS): [https://wukix.com/mocl](https://wukix.com/mocl)

Somewhat different setup though. Instead of a Java-replacement language on top
of a JVM, I believe it's compiling to native code. The intention seems to be
to target "logic-heavy" apps where a smaller portion of the code is UI. You
still write the UI in each platform's "normal" way (Java on Android, Obj-C on
iOS), but call out to Lisp for the real work. I'm not 100% sure on this part,
but I believe that's done on Android via the NDK route, not Dalvik/ART. No
idea what happens on iOS.

------
ryanthejuggler
You can use Scala for Android right now, as people are pointing out. However,
it feels like a "second-class citizen" because the Android JVM has been
optimized for enterprisey, Java-style coding with fewer, longer-lived objects
than functional programming usually demands.

At a guess, I'd say that with Java 8+ they'd have to fix that. Probably why
they said "no comment" as pjmlp pointed out
([https://news.ycombinator.com/item?id=8192614](https://news.ycombinator.com/item?id=8192614)).

------
krschultz
Theres a different between "supports writing your own code in that language"
and "the platform APIs are in a language".

In theory, it should be possible to write code on the Android platform using
any JVM language. Groovy, Scala, Clojure, Kotlin, etc. There are hiccups to
that right now but you can hack your way to it generally.

But Android's APIs are going to stay in Java. That is a lot different than
Apple's move to Swift, where the platform itself is moving to the new
language.

------
krschultz
This has a lot more to do with refactoring the build system than anything
else. The more the build system adheres to the Java Gradle plugin, the easier
it is to use Scala or other JVM compatible languages. There is an open ticket
for it, and supposedly Gradle 2.0 will make this possible.

[https://code.google.com/p/android/issues/detail?id=56232](https://code.google.com/p/android/issues/detail?id=56232)

------
seivan
Swift doesn't have a GC from what I know it has automatic reference counting.
It's not really the same thing.

It's on compile time and not at run time. It injects release/retain calls
between acquiring ownership and relinquishing ownership.

I could be wrong but I don't think they added GC to Swift, as Objective-C (at
least not on Mac OS) doesn't have it.

EDIT: They got rid of the GC on Mac OS as well. They use ARC there as well
just like iOS.

~~~
monkey_slap
Correct, Swift uses reference counting in just the same way Objective-C did.

------
donniezazen
1\. Most of the threads like this are going to turn into I like this language
so let's rewrite Android in that.

2\. Even if Google changes the primary development languages of Android where
do you go to ask developers to port their Java libraries, technical bloggers
to update their blogs with Scala code or change thousands of questions on SO.

Documentation/Q&A created around Java/Android is equally important.

------
serge2k
according to apple, swift uses ARC, not GC.
[https://developer.apple.com/library/prerelease/mac/documenta...](https://developer.apple.com/library/prerelease/mac/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html)

How does Scala solve any of the problems with Java?

~~~
lmm
It unifies the type system, which gets one of the big headaches of Java out of
the way.

It has a generics system that makes a lot more sense (allowing
covariant/contravariant types, rather than forcing use-site variance
everywhere).

Case classes are wonderful for making simple data classes easy to read (and
write).

Honestly Scala is all about solving the pain points with Java, so just look at
anything that's been written about it. [http://www.scala-
lang.org/](http://www.scala-lang.org/)

~~~
serge2k
right, all nice to have things.

Does it actually solve any real problems?

Does it fix GC performance? Does it fix API issues? Does it remove the need
for JNI bindings to native code?

No?

~~~
lmm
Repetitive code is a real problem. Or do you think performance is the only
thing that can ever qualify as a "real problem"?

Implicits make it much easier to deal with API issues.

------
knodi
No. Google its time, we want Go for Android.

~~~
reustle
It's being talked about
[https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_Ojjnj...](https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_OjjnjVKxgeVBjIsTr5qIUcA4/mobilebasic?pli=1)

~~~
merlinsbrain
Yes, however there is a major caveat: "Providing a Go equivalent to the
Android platform is intractable."

What is actually happening: "There is however, a subset of Android apps
written against a much smaller C-based API surface provided in the Android
NDK: Games. It is feasible to build Go support for Android providing the
equivalent features found in the NDK."

Source: parent link
([https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_Ojjnj...](https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_OjjnjVKxgeVBjIsTr5qIUcA4/mobilebasic?pli=1))

------
apetrovic
Knowing that Google and JetBrains have a good cooperation (Android Studio will
replace Eclipse plugin as a preferred way to develop apps for Android), I
kinda-sorta expected Kotlin to be backed from Google as an official Android
language on the latest I/O.

------
gizmodo59
"As phones are getting faster memory is not an issue anymore." No, its not
true. Memory is an issue. Android does not only run on premium devices but
also economical devices.

------
fritz_vd
Um... why .. on .. earth.. scala. Make it stop.

------
howdoipython
I think there are better selections than groovy to be the next language
supported on Android.

------
otikik
Make golang for Android and I'm yours.

~~~
zura
Swift would be better.

~~~
eigenrick
Rust would be better.

~~~
BinaryHole
No~Go is the best~ Too simple, and too powerful~

------
justplay
My bet is for golang.

~~~
izacus
Current design of Android makes any non-JVM language a rather illogical and
problematic choice.

Writing JNI bridges for everything and reboxing costs would be prohibitive.

~~~
higherpurpose
So what? I think with the arrival of ART, it's also not an impossible task
anymore, in terms of compatibility. They just need a separate team to rewrite
all the _existing_ API's in Go (and also catch-up with the _new_ ones by the
time they finish this project). How much would that take for a team of 20
developers? I imagine not that long.

In theory, they could make ART allow for both the Java code and the Go code to
work on Android, no? So we could have Google push new app development to Go,
while they deprecate Java over the next 5 years (after Go support is out).

But to get developers to write Go, they also need a significant market share
of Android L/ART-enabled devices, like over 50 percent, which will take 2-3
years to arrive there anyway. They can use this time gap to port Android APIs
to Go, and when ART is on 50-70 percent of the devices, announce that
developers can now write Android apps in Go, too (for Android L+ only).

They could announce it at the release of Android N (the one after M). By then
Go 2.0 will probably be out, too, so they can support 2.0 on Android from the
beginning, especially if they plan Go 2.0 to have some pretty major
incompatibilities with 1.x. In the meantime, the Go team could also work on
some "made for Android" features for Go 2.0, to make Go more optimized for
Android. By then, they'd probably only have to support ARMv8, too (preferable,
I think). So they can target only 64-bit ARMv8 hardware with Go (from what I
hear Go works better with 64-bit hardware anyway).

I think Google can do this. They just need to plan it out. Three years is
probably a reasonable time period for this.

------
Afal
No

------
jcc333
Scala doesn't have very good type inference, dude...

