Hacker News new | ask | show | jobs
by geodel 3326 days ago
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.
5 comments

The newest version of Scala (2.12) requires a JVM with Java 8 feature compatibility which makes it unusable on Android devices. Google would literally be stuck supporting an obsolete version of a language that's not developed... or restrict the use of it only to Android O and newer making it dead on arrival.

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.

Bit of an aside, but is the Kotlin compiler itself runnable on JVMs supporting Java 6? So you could compile on an Android device.
It's supported all the way down to java 6.
I think you need JDK8 to compile Kotlin, but I'm not 100% sure.
thought recent android's tools update meant I can use java8 on android devices...

guess that requires a recent android device :(

The devices themselves still run a JVM (Dalvik and ART) that's basically compatible only with ~JRE7 bytecode. There are some new features in ART since N, but still the JVM isn't fully Java 8 compatible (afaik invoke-dynamic for lambdas is still not supported).

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 amount of supported features depends on the target API of the application.
Scala never worked that well, for example it requires several steps, focus on sbt, requires the pure InteliJ version instead of Android Studio, thus forcing developers to be a few versions behind on Android plugins.

http://scala-on-android.taig.io/sources/

IIRC Scala also has a decidedly non-trivial runtime library with its own set of abstractions, where Kotlin is basically "better syntax" on top the existing JDK/Android library ecosystem. Writing Scala to deal with an existing Java framework "feels like" working with an FFI, where in Kotlin it's more natural.
Because of that non-trivial runtime when I used it, it also required pro-guard. I like proguard but it comes with its own set of issues. I typically set it up at some point in a project, but I don't want it required as a first step on a new project.
I don't see what it has to do with relationships. Convince us why Scala would've been a better choice?
I have nothing against Kotlin. It seems to be coming out of nowhere to surpass more "tested" languages for lack of a better way of putting it, but as I'm reading about it I can truly see the appeal.

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.

It's weird you'd accuse Kotlin of throwing stuff at the wall while simultaneously speaking kind of Scala. Scala has so many competing ideas & approaches just all mashed up into a blob.
Scala isn't so much a mishmash as it is fertile ground for people to do all kinds of weird stuff that looks like part of the language. Very much like C++, with the same potential for committing atrocities. And like C++ was, it's great from a programmer perspective (long lever, you get what you want/deserve) but bad from a corporate perspective. (Somehow C++ acquired an aura of corporate respectability, but in retrospect it's surprising, considering it has the same problems as Scala: a difficult and sometimes esoteric language, hard to hire for, amplifies programmers instead of smoothing them out, easy to misuse with tragic results, might walk by a developer's desk and see them consulting a book instead of pounding out LOC, etc.)

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.

This is wrong. It might look like that from afar, but what seems like complex features in Scala are almost always actually combinations of simple, powerful features, and the combination works exactly the way you'd expect once you understand the simple features. (Almost all of the concrete examples people give of "Scala complexity" are actually library features implemented in plain Scala, and if you get confused you can always click through to the source and read how they're implemented, because they're just plain old code). Whereas in Kotlin they really do just implement every use case as a separate language-level feature.
JetBrians is possibly the best company on the planet to implement syntax improvements to Java, which is basically what Kotlin is.

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.

Kotlin didn't change, the only difference is `trait` keyword replaced with `interface` keyword. But I'm not really getting this article. Inheritance is key principle of Object-Oriented Programming, throwing it away would be very stupid move. It could be abused, but everything could. Kotlin solves this in pragmatic way: if you need inheritance, you must declare it explicitly. If you want delegation, Kotlin got you covered with awesome delegate syntax. The choice is up to you.

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.

Thanks. This is helpful. I guess part of what I'm wondering is how much Kotlin interfaces compare to Scala traits in the sense explained here:

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.

No , inhertiance is not a key part of oop. Look at Rust and Go. https://lwn.net/Articles/548560/
I tend to agree. Sure, Kotlin is much more terse than Java. But looking at it I can't help much miss language features I've gotten used to in Rust, Haskell et al. I'm sure it's a wonderful language and an improvement over Java but there's nothing that excites me about it.

Hey, at least they've got nullable types? That's a big win over Java right there.

> 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

non-nullable*, Swift calls them optional types I believe. They use the same syntax for it, if you want your type to include "bottom" you add a ?

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.

I think they meant to say that Kotlin has non-nullable types.

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

I have starting learning kotlin 2 years ago for Android but I have not yet touched Scala, so I am also biased.

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.

I think the case for Kotlin over Scala is that the runtime you have to link into your app is substantially smaller, which is important for mobile.
Objective-sounding reasons: Scala has got a large library ecosystem, it's demonstrated an ability to retain backwards compatibility while evolving the language (Kotlin may yet get this right (well, no it won't, but that's getting into a more technical argument) but many languages don't, and Kotlin simply hasn't been around long enough to see whether it's any good at handling change).

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).

> Scala has got a large library ecosystem

Kotlin has the entire java ecosystem to work with.

So has Scala (to exactly the same extent as Kotlin, despite what Kotlin pushers will tell you), it's just got a better additional library ecosystem than Kotlin has.
I vastly prefer Kotlin over Scala. Kotlin is probably more productive for a typical dev or team.
It's kind of hard to get developers to adopt Scala for Android, when people in charge are diametrically opposed to even acknowledge its existence. :-)