Well this looks like going to push Kotlin in big league. I remember scala enthusiasts made big noise in last few years to have scala as officially supported language. But Google seems to prefer a closer relationship with Jetbrains.
Kotlin compiler generates code that's runnable on JVMs supporting Java 6, which makes it work on pretty much any Android device, even running older Androids.
Scala standard library is also huge and pretty much immediately hits the 64K method limit of DEX files forcing you to use the very slow proguard compilation step when running it. It also has issues with interoperability with existing Java 6 code.
All in all, Scala is a terrible value proposition in comparison to Kotlin which was built from ground up to modernize programming while still keeping full compatibility with Java 6 code and JVMs stuck on Java 6 language level.
guess that requires a recent android device :(
So the Java 8 tools you're talking about essentially take Java 8 compiled bytecode and patch out the parts that aren't compatible with device JVM (e.g. they replace lambda invocations with anonymous classes like you'd use on Java 6 etc.).
This doesn't work for things like Scala which use these new features in patterns those tools can't patch/recognise.
The one thing I'm having trouble figuring out, though, is how much it diverges from Java in terms of inheritance, traits, etc. The verbosity of Java is one thing, but its inheritance system is what made me want to pull my hair out.
Languages like Scala, Haskell, Rust, etc. are preferable to me in that way. Kotlin seems nice and clean--from what I've seen so far, with this "Android bump", Kotlin native, etc., I could even see it replacing Python--but I worry there's something lurking deeper.
This is the clearest thing I've found so far, but it's very old at this point:
http://codeofrob.com/entries/looking-at-kotlin---kicking-the...
It includes this quote that stokes my fears: "It feels as if the language designers haven't really designed at this point, they've just thrown a load of stuff at the wall because inheritance is something that all Java developers want and given us a few bad ways of doing something as well as something that has the potential to make us write better Java."
I don't have any attachment to Scala. However, I do think Scala, Rust, etc. have moved language design forward in significant, fundamental ways, and it would be nice to see those advancements recognized in the Android platform.
Take this all with a grain of salt, though, because I know next to nothing about Kotlin.
I'm thrilled that Google is supporting Kotlin, though. Official support for Scala was never going to happen, and Kotlin sounds like a huge step up. I regret sinking so much time into struggling with Scala on Android.
After 2 hours with the kotlin koans (short exercises allowing you to learn the language), it was already clear that Kotlin solves most of java's limitations when writing android apps.
higher order functions : so powerful .. at the cost of dex (and I don't really care about dex size), I can get very flexible calls.
nullability backed in the compiler
100 % java interop
data classes
default parameters values ..
etc
IIRC, the larger runtime was what prevented Scala from being interesting on Android. I know that Scaloid has been working on making it more svelte though.
Hey, at least they've got nullable types? That's a big win over Java right there.
Can you elaborate what you mean by nullable types?
You can set Object variables to null and with primitives you can do the same with their boxed alternatives (Integer) but I assume you mean something different?
Like the lack of types which can't be null? I can see how that's useful
The Kotlin page does a good job of explaining it if you aren't familiar. It's the single most important feature that makes Kotlin worth using over Java in my opinion: https://kotlinlang.org/docs/reference/null-safety.html
In Kotlin/Swift by default all types do not include "bottom" or "null". You add a ? to the type to indicate you may use that value, then the compiler will validate you're checking for the existence of null before you use the type.
It's one approach... I prefer the Haskell approach with a simple Maybe/Option type.
Also remember that good compatibility with Java is a big priority for Kotlin, so inheritance works very similar to Java and compiles to the same obvious JVM structures.
https://en.wikibooks.org/wiki/Scala/Traits
Or, in another example, how does use of Rust impl map onto Kotlin?
http://www.jonathanturner.org/2016/02/down-the-rabbit-hole-w...
I really don't mean this as a criticism of Kotlin, I'm just trying to map this all out. Kotlin seems nice and like something I could use, but I'm sure it has its boundaries also.
They have deep experience with the syntax of a bunch of different languages. They know what Java is missing because they've seen a ton of different things in diverse languages.
Looking at Kotlin myself, they got rid of almost all of the painful syntactical blunders in Java. I'm seriously considering picking it up for my next project just looking at their main page. It looks fantastic.
Developer reasons: Scala is a much more elegant language. Failure reporting in Kotlin completely sucks (in some ways it's worse than Java since they've removed checked exceptions and not offered any substitute - they make a lot of fuss about handling null/options but all that completely breaks down as soon as you want to actually report a reason why something failed). Typeclasses with automatic derivation are really nice. In a big application I might like to be able to do FRP stuff or async pipelines; not only does Kotlin not have an equivalent to fs2 but it's impossible to write one in the language. Every time a new thing comes along Kotlin adds it into the language as a new, different feature because they're allergic to offering general features you could use to implement things yourself (e.g. async/await).
Kotlin has the entire java ecosystem to work with.