However the comparison beyond language features is very much relevant, including the lack of Android support in Scala 2.12
Adding to the woes, the code emitted by 2.12 is slower ( https://news.ycombinator.com/item?id=12066653 )
Not to say things can't improve. After the initial announcement of 2.12 at ScalaDays 2015 and 2016, expect more at ScalaDays 2017.
Anything else it is up to the respective language communities to make it work.
Right now only Kotlin seems to be improving their Android support, but that is because JetBrains needs a killer application for it, which appears to be improving the world of those stuck in Java 6.
They were very clear at the AMA:
"Anwar: Nope, not happening."
"Anwar: We don’t have any plans to officially support a new language in Android, so we’d encourage folks to continue to use Java:) That said, you should continue to use what works for you."
https://www.reddit.com/r/androiddev/comments/4tm8i6/were_on_...
People have to get over the fact that regardless of what happens in the Oracle vs Sun, the Android team which has a quite a few Sun alumnis, doesn't want to use anything else.
Even the NDK is designed in a way that native C and C++ code is always exposed via Java native. The example code on the NDK start page is pretty clear how they see the NDK.
https://developer.android.com/ndk/index.html
"The Android NDK is a toolset that lets you implement parts of your app using native-code languages such as C and C++. For certain types of apps, this can help you reuse code libraries written in those languages."
And another fun fact is that given the NDK constraints, having Linux as kernel doesn't matter that much, they could change to something else and only OEMs would notice.
Even Microsoft is only improving the Objective-C support on their iOS bridge, in spite of the Swift support requests, at least for the time being.
If you check Brillo, which is basically Android without the Java layer, their plans are to create a C++ Frameworks layer not Swift and not Go.
I would guess there's probably quite a few VB6 applications out there in business-land, and it's been EOL'd since 2012 IIRC. Not that most people would want to deal with them, but they exist, just like Java 6 in Android.
We did consider (and regret) potentially leaving android behind, but we were (perhaps naively) hoping that something like retrolambda would suffice, or that android would catch up. In any case, it doesn't make a lot of sense to have 2.12 still support Java 6, since most of its features require Java 8 (those that don't, we first implemented in 2.11.x).
As announced in http://scala-lang.org/news/2.12-roadmap/, we will continue to support 2.11 for a bit longer than most releases, and we welcome community backports of 2.12 features that you'd like to see in 2.11.
Presumably 2.11 won't be supported going forward? Or as someone who would like my libraries to work on android and doesn't particularly care about them being callable from Java 8, should I just stay on 2.11 indefinitely?
a) Java 6 is forward binary compatible with later versions
b) Google has a reasonable excuse in terms of the Oracle lawsuit. Don't get me wrong, I'm not happy about Android being stuck on Java 6, but there are extenuating circumstances.
c) Scala 2.11 has issues that affect me and I want to see fixed. Java 6 doesn't, at least not that I've noticed. (If JVM 8 were necessary to the implementation of a Scala feature I cared about I would understand that, but as far as I can see it's irrelevant to my use cases)
I don't want a SBT based build that eschews the way Android developers work.
I want a setup that embraces Gradle (even though we love to hate it), Android Studio GUI designers, plugins and annotations.
Last time I mentioned this, someone pointed me to
http://scala-on-android.taig.io/editor/android-studio/
which hasn't been updated in ages.
Using InteliJ with Android support means always being outdated as it is usually two versions behind from Google's fork.
It's pretty easy. You have to setup less things than with Gradle, because SBT deals with all the downloading, installing and managing of the two dozen SDKs Google wants you to use.
> I want a setup that embraces Gradle (even though we love to hate it), Android Studio GUI designers, plugins and annotations.
You can keep all you Gradle configuration. SBT-Android has a Gradle support mode so you can e. g. use the Gradle definitions for your IDE, but enjoy the fast turn-around and compile-times of compilation with SBT.
> Last time I mentioned this, someone pointed me to http://scala-on-android.taig.io/editor/android-studio/ which hasn't been updated in ages.
Yeah. The documentation is at scala-android.org. If you feel something is missing, I think the maintainers are happy to read your ticket.
> Using InteliJ with Android support means always being outdated as it is usually two versions behind from Google's fork.
The current IntelliJ is pretty much up-to-date with current Android Studio.
Sorry but it is not.
Android Studio 2.2 is about to be released and IntelliJ IDEA 2016.2 only supports the plugins from Android 2.0 with caveats.
https://www.jetbrains.com/idea/whatsnew/#v2016-2-android
"The update includes the Android Studio 2.0 features: faster Emulator, experiment GPU Debugger, faster full builds, and code generation and testing for App Indexing. Note, Instant Run is not fully-merged yet."
If you want to drive adoption, it should work on Android Studio as well.
This is what I usually mean by using first party platform languages versus relying on third party support.
For Kotlin, all I need is to install the plugin on Android Studio and am off to the races.
And still I am not using it, because there are a few rough edges with all the Android workflows.
What is preventing you from doing that with Scala?
I see that you filed a ticket that the setup of IntelliJ != Android Studio, but is there anything that works in one, but not the other? (Except having to skip the "install android support" from the install guide?)
I don't get the whole dooms day scenario.
- Google is working on Java 8 support.
- The current version of Scala supports the current Android stack.
- Depending on the timing, the next version of Scala might also support the then-current Android stack.
- You can always use Scala-for-Android (aka 2.11). Just think of it as a flavor like Scala-JVM, Scala.js or Scala-Native.
More than anything specific though, I don't want to be stuck on an old version as the language moves forward.
> I don't want to be stuck on an old version as the language moves forward.
How are you going to be stuck? You might need to stay on 2.11 a bit longer until Google gets their shit together. Most likely this will be during 2.12. Sure, you might miss the first few minor releases of 2.12 ... but stuck?
We're working on the performance issue, with help from the team at Oracle. The problem is likely the JIT having trouble optimizing the bytecode we emit in M5 (we know of other schemes that don't suffer this slowdown, but require more bytecode).
Read the article and you will notice that Scala 2.12-M5 will solve some of this slower code emittion. It's in the middle of your linked article.