Android now supports Kotlin | Hacker News Reader

Android now supports Kotlin

venturebeat.com

620 pointsJOfferijns216 comments

Funny, I was messing around with Kotlin for the first time last night. So far, the language seems well-structured and I really like that one gets all of Java's ecosystem without actually having to write java. (Also, "override fun" just sounds hilarious. Bwaha!)

Throw in TornadoFX and Gluon Scene Builder (formerly of Oracle) and you're spinning up high-quality cross-platform GUIs faster than Atom, with a visual editor, and without having to touch Javascript!

I've been trying to find a suitable, high-quality cross-platform GUI kit for a while and this looks like it might challenge my current favorite (GTK)

Is JavaFX also included in the "safe" parts of Java (i.e., in an Oracle-sanctioned GPL VM)? I know there are some open-source versions, but Oracle's trigger-happy lawsuit button on Java these days has made me nervous to poke.

OpenJFX is part of Oracle's OpenJDK project.

It even works on FreeBSD https://www.freshports.org/java/openjfx8-devel/ so yeah, truly cross-platform open source GUI :)

New to Kotlin + ecosystem... So can you build Android UI's with Scene Builder? I see notes about it working with Gluon Mobile which appears to be a cross platform mobile library.

Not concerned about Android at the time, I was looking for a desktop app toolkit.

Now that you mention it mobile support seems to be in flux: http://stackoverflow.com/questions/20860931/is-it-possible-t...

No, Android does not support JavaFX or Swing for that matter.

From what I've read the open-source bits of Gluon Mobile are available for free via JavaFXPorts

http://gluonhq.com/products/mobile/javafxports/get/ <-- android, iOS, ARM

However it seems to be a barebones solution as it lacks mobile-specific controls (they want you to buy Gluon Mobile for that)

Not really. Android has its own graphical stack.

You might be able to write an ndk app targeting android with you own stack of widget, but that's very different from an 'sdk' app.

For Android, just use it's UI toolkit. It'll work better than trying to shoehorn a 3rd party thing in.

The problem is its performance on the device and size overhead is horrible. Javafxpackager is just about the worse too.

Check out Codename One which is more like Swing but far more robust. The GUI builder isn't as refined as scene builder but the final product actually works everywhere and far more portable than anything else.

Codename one "Professional Edition" is $79 per month! Basic is $19 per month... As a kind of "indie" developer that is very expensive. Gluon Mobile is not much less expensive at $42 per month. Still, free edition looks better than Codename 1 free edition.

Wondering if Jetbrains will release Kotlin/Native for a set price or charge monthly like most companies are doing these days.

Codename One is open source and has a free edition without nag screen or any license restrictions. For that $19 you get more platforms and no need for a Mac etc.

But you have to use their BS cloud build service? Hell no.

Why so negative?

I'm also against "cloud everything" but here they seem to provide an actually useful service.

Instead of having both a Mac and PC which is the only other alternative that's physically legal.

Notice that this is a compile time feature, you don't need to use it for production.

Had to try Gluon Mobile for work for some weeks, being a complete newb to JavaFX.

I build a simple Pacman game. Running on Android wasn't a problem even though the builds took an entire minute to complete.

Compiling and running on iPhone was a nightmare though: At the beginning of the project I was able to run it - some days later I had to tweak the RAM being allocated to the trans/com/whatever-piler - a week later and the weeks after I was unable to compile it at all, there just wasn't enough in my MacBook to throw at the thing.

And the subjective performance was relatively bad too. They tried to reimplement Material Design and it looks somewhat like it, but it performs pretty badly.

Even their own conference app demoing Gluon Mobile is terrible and that says a lot.

Those are good points, thanks for the heads up

I call Kotlin Android's Swift.

Exactly!

http://nilhcem.com/swift-is-like-kotlin/

Wow.. Swift is reading a lot like JS and TS.

(PS. I am new in both the languages and no Swift expertise)

Heaven forbid they just support Swift instead.

You'd need to rewrite Swift to run on the Android VM (a big undertaking) or fork the Android frameworks to work well with Swift. That's a much bigger undertaking than supporting a language which was created for the JVM and specifically made for interoperability with Java.

Unfortunately the JavaFX menu bar is just as broken as the one in Swing. In particular (I'm sure there's more),

1. it gets very confused about the focus when alt-tabbing between windows (as alt, on Windows, also toggles focus on the menubar),

2. there is no attempt to solve the problem of submenus disappearing when you attempt to move the pointer towards them, which is solved in Windows and Qt with a delay, and in Mac OS and GTK with ... the solution that is actually documented in the OpenJDK wiki but not implemented: https://wiki.openjdk.java.net/display/OpenJFX/Menu+User+Expe...

So JavaFX might be high-quality in some way I haven't noticed, but to me its immediately noticeable qualities were its general slowness and brokenness.

Post in JetBrains/Kotlin blog:

https://blog.jetbrains.com/kotlin/2017/05/kotlin-on-android-...

I really wished they would choose Swift. It's open source now, and many developers would definitely enjoy having to learn only one programming language for developing native apps.

Unfortunately, corporate policies and hubris matter more in these things.

And the massive technical undertaking of making the Android framework work with a none Java interoperable language?

Kotlin was already mostly working with Android thanks to a community effort. This announcement just gives it Google's blessing and gives you all the Kotlin tools by default in Android Studio. Going forward they'll likely be working closely with the Kotlin developers, but this was primarily community driven.

While developers would love that, kotlin works because its interoperable with java. Swift doesn't have that. Try to add it and you'd shatter the swift ecosystem. Don't add it and people wouldn't adopt it because there's no path for gradual transition.

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.

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.

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.

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.

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

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

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.

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/

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.

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.

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.

thought recent android's tools update meant I can use java8 on android devices...

guess that requires a recent android device :(

The amount of supported features depends on the target API of the application.

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.

Bit of an aside, but is the Kotlin compiler itself runnable on JVMs supporting Java 6? So you could compile on an Android device.

I think you need JDK8 to compile Kotlin, but I'm not 100% sure.

It's supported all the way down to java 6.

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

What does it mean being "supported", given that one already can use Kotlin on Android?

Well, if you work in a more conservative company, you can use this as a way to get the "powers that be" to allow the use of Kotlin. It's basically an endorsement of the language by a company that everyone has heard of.

It's not just conservative companies, but also independent developers and startups that may not want to start investigating third-party languages, of which there's no shortage. Particularly if they're up against other barriers like not being experienced at Android, in which case they may not want to learn the Android frameworks AND a new language at once. Or they have to learn some new Android frameworks they didn't use before, like the camera APIs.

Built into Android Studio without having to install anything extra seems like the main draw.

Official support will also make it easier for people to push for Kotlin in larger projects

It means:

- being documented on https://developers.google.com

- being installed by default with the SDK

- having official tutorials provided by the Android team using Kotlin

- having code samples provided by the Android team using Kotlin

Providing the confidence to many companies out there that Google will not change Android in a way that Kotlin compiled applications would stop working.

Right, the title of the article is pretty awful and misleading. The language used at the conference was "Kotlin is now a first-class supported language". First-class supported means it gets all the treatments you mentioned above, and probably better tooling by Google for development.

You mean: Kotlin already supports Android (which is true and indeed very nice)

This is about: Android now supports Kotlin

I've never thought about it that way, nice perspective

Kotlin has been supporting Android for a while, with the promise that the language takes Android's needs into account. For example to do not request JVM 8 as a minimum...

Kotlin has been unofficially supported already by the Android tools team for some time. Meaning that they would work with the kotlin team in order to make sure that when a tools update breaks the kotlin build tools, they can be fixed in a timely manner.

Now that it is officially supported, we might have : - idiomatic android api for kotlin (there is already 100% interop, but sometimes java's code can be better expressed in kotlin) - official android documentation in kotlin. - I guess that kotlin will focus even more on Android's support

It is not going to change anything regarding kotlin compatibility with Android. Since kotlin outputs bytecode, it would be almost impossible for Android to permanently break kotlin compatibility without also breaking 99% of all Android's libs.

Good move. Out with possible null pointers everywhere for no freaking reason at all. It's 2017.

Apple did a great job with Swift but launched it when it wasn't mature yet but Kotlin will have JetBrains level of IDE support from the get go so and it's mature already only a luddite would stay with Java.

Apple released Swift early (June 2014) so that it could be used in real programs, and so that developers could provide feedback. You weren't, and still aren't, forced to use it. Although, it seems to have matured enough in 3 years to the point where it's probably the best iOS development language.

Kotlin was released in 2011. I bet that if Google had adopted it three years ago, it would have helped accelerate Kotlin adoption and Kotlin would be even further along today, having a much larger developer community.

Kotlin was released on 15 February 2016.[0]

[0] https://blog.jetbrains.com/kotlin/2016/02/kotlin-1-0-release...

That's the 1.0 release, but it has been in public alpha / beta since 2011 or 2012.

https://blog.jetbrains.com/kotlin/2012/04/kotlin-m1-is-out/

It went 1.0 last year. It was in development for 5 years, and some people did adopt it for Android development before 1.0

https://en.wikipedia.org/wiki/Kotlin_(programming_language)

Anyway, that's my point. Apple iterated Swift quickly in 3 years, and Swift is a very nice language now. Some sort of support, or even acknowledgement, from Google could have accelerated Kotlin.

Given that most developers still complain about the state of Swift and its tooling I'm not sure Google's approach is wrong here. Most serious Android developers have been aware about Kotlin for a while, and today it's mature enough to be openly endorsed by Google.

Right. Swift might be done in version 4.0. Or even 5.0. No ABI stability for example so you're always shipping up to 10MB of Swift runtimes with your app, which is still a considered a lot for a mobile app unless you work at Facebook. The constant IDE crashes are gone luckily but sometimes compiling gets reaaallllyyyy slllooowwwwww all of a sudden just when your product hits a certain critical complexity.

Seems that automatic type inference is something that's really nice for one page programs but explodes in complexity for the compiler once you start to do it in big programs with complex structures (nested dictionaries) or methods (like chaining flatMap with filter with join).

I'm trying to work with R.Swift and IBAnalyzer nowadays to have a 100% "if it compiles it doesn't crash" solution even while using Storyboards and that alone increases my productivity more than any left over annoyances at the moment might decrease.

Swift 1.x was horrible though. I had to pick up a project left half finished by a junior to finish it. What a nightmare. Every new Xcode point release broke everything

> it's mature already only a luddite would stay with Java.

Don't confuse professional programmer who would use language whatever client/employer decides with luddite.

This is pretty big. I really like Kotlin, but when I tried to integrate it into my app, it just didn't play well with popular libraries which rely on compile time code generation (Google's Dagger fork, Icepick, Parcels, etc). Has support for this improved / is it easy to integrate?

Annotation processing has been improving a lot https://medium.com/@workingkills/pushing-the-limits-of-kotli...

We use Dagger2 extensively with Kotlin where I work and it works very well. I haven't used the other libraries you mentioned.

I have a project with Kotlin + Dagger + DataBinding.

Annotation processing works fine with kotlin.

First setup can be a pain though, especially if you are not familiar with Android or the gradle build system.

I'm hopeful that with official support this process will become smoother

It was rough because I had to write the script myself (one year ago). You need to know some things that are not obvious at first glance, like the fact that the databinding compiler is versioned with the android plugin for gradle.

Nowadays, you can just copy paste it from an existing github project.

Finally!!! JetBrains has been doing an awesome job on Kotlin. Languages is a very subjective and taste specific thing, but it's way better than just having Java. Anyhow I have been arguing over moving to it for quite some time now here is a shameless plug https://hackernoon.com/in-pursuit-of-better-jvm-futures-kotl...

If you have used kotlin, it seems the obvious move. I am not coming back to java, unless completely necessary. Kotlin is a great language (and more fun!).

Kotlin is an absolute pleasure to code in, far better than Java. Add in such easy mixing with Java code, and it's by far my favorite JVM language.

Out of interest, what is wrong with Java? I found writing Android apps easy enough using Java. I am from a C++ background, so find all the C# and Java that I have to write quite simple, so I'd be intrigued to know what was "wrong" with Java.

Is it worth me looking into Kotlin? I am already halfway through investigating Swift so it seems the endless task of keeping up to date with new languages for each platform (keeping up to date with the changes in C++ and the STL is a mammoth task in itself).

There's nothing wrong with Java. It's outdated language by today's standards, a lot of code which takes 100 lines in Java would take 50 lines in Kotlin (and if we'll take autogenerated boilerplate getters/setters, it could be 1000->50), but overall Java is fine.

But I still suggest you to look into Kotlin. If you know Java, you won't spend much time learning it and with awesome IDE support you can be productive in very short time. You might find that you'll just prefer Kotlin over Java for a lot of little things which makes coding more enjoyable.

Can you elaborate on how Kotlin maintain compatibility with Java?

Kotlin can just import and use any Java class. Kotlin doesn't introduce new strings or collections, so conversions of any kind are not required. Also Kotlin compiles to Java classes which can be used from Java without any problems too.

So, Kotlin and Java are fully inter-operable without any feature loss?

This, along with recent Kotlin Native news, lends me to believe Google is investigating some alternative platforms for replacing their dependence on Java APIs and removing any possibility of being further hamstrung by Oracle.

This news sounds quite opposite to me. Although adding a new language is always a good news but Kotlin won't solve any problems with Oracle, since it is just another JVM language. This news sounds like Google is going for an easier way instead of ditching Oracle stuff.

It does open up a path for a possible future migration to Kotlin Native (in several steps), but that's really just wild speculation.

> since it is just another JVM language

Not for long, they're working on Kotlin Native which will make it completely independent from the JVM and portable to all platforms. Killer.

That's with Kotlin's much smaller runtime. It's the stdlib that matters, not the language. Which is why the JVM or an emulated version of it will be around on Android for a long time.

That has no value for Google. If Google wanted to get rid of JVM technology and idioms on Android then it would be better off with pure native language like Swift/Rust/Go. They all are quite further away from Javaism. Kotlin's great value is mostly because it is Java like and run on JVM.

Kotlin supports automated conversion of Java into Kotlin code.

This means you could quickly transform any existing app into a Kotlin Native app quickly.

Exactly, this sounds like just the right move to me if you're Google and would like to see a nice transition period out of the Java dependency, but until then, also support JVM. I'm sure such a move wouldn't come abruptly. Would be cool if they could get that strategic move and a more fun/productive language than Java in the same bang.

And yet Microsoft did .NET Native precisely to target mobile platforms.

Why do you think that natively compiled Kotlin would be slower than Go, anyway?

The difference being (I assume), that Microsoft has ownership of the entire .Net stdlib. The current android framework relies heavily on the java stdlib, which means that any attempt at a different language would have to bring a full rewrite of the framework itself.

I think you're reading too much into this. The only reason they adopted Kotlin was because Android devs were already using it. Jake Wharton, one of the most well-known Android developers, has also been a vocal supporter of the language for a long time, so much so that Google actually invited him to give a talk about it at I/O this year - I have never seen Google invite a community member like this before.

Source: I've been developing Android apps for 2 years and closely follow all developments in the community.

Oracle winds up killing another golden goose they aquired from Sun. That's what they do though. They buy innovative technology companies who have committed customer bases and then slowly squeeze all the money out of them until they can migrate off. By then they've aquired another set of victim customers.

Not sure what you're rambling about.

Java is still and always will be the core language of the JVM. It isn't going anywhere and the Java team (comprising mostly ex-Sun people) continues to push the language forward under Oracle's fantastic stewardship. The issue is that Java is required to be more stable than other languages since it powers so many production, enterprise system and hence will be slower to innovate.

I have seen no widespread movement to jump from the Java/JVM ship if anything more and more people are moving towards it because of languages like Scala, Clojure, Kotlin etc.

I think the Oracle/Google lawsuit drove the decision to adopt Kotlin. Now Google is going to work with JetBrains to develop Kotlin and is going to fork the GPL JVM probably by not including things like the controversial project Jigsaw that IBM voted down. Meanwhile, Oracle is stuck with Java, just like they're stuck with OpenOffice, Hudson, etc.

Nah. What drove the decision is that huge swaths of Android development community already adopted Kotlin and it's trivial to implement it in existing Android codebases. It's also built by a company with which Google already has partnership with (IntelliJ built both Kotlin and IDEA IDE which is the base for Android Studio).

Yes, this is the only reason IMO. GP is reading too much into this.

Source: I closely follow all developments in the Android ecosystem, and have been doing so for over 2 years.

Jigsaw would actually help android. The entire reason Google went with their own implementation in the first place is to exclude certain APIs that were meaningless on android.

"To get started with Kotlin, download the Android Studio 3.0 preview, open one of your existing Java files, and then choose “Convert Java File to Kotlin File” in the Code menu."

You do not have to install a preview version of Android Studio, you can install the kotlin plugin in whatever version of AS you're using now. The change in AS 3.0 is simply that it will ship the plugin by default.

It doesn't need to be a preview version of AS. I'm coding with Kotlin on AS 2.3.1 and IntelliJ 16. Just make sure you configure kotlin for the project, easily done, by creating a kotlin file.

That's what I said =)

Anyone know of good online tutorials for Kotlin? I learned Swift for iOS development and customers have been asking for an Android version of my app. Sounds like Kotlin would be a good second language to learn.

The official docs has the best tutorials I have ever seen for a new language.

1 - skim the language documentation (depending on your familiarity with java, this will be more or less easy)

2 - download intellij, clone the kotlin koans repo and do these exercices.

After finishing the koans, you will have a good grasp at kotlin's basics.

The Kotlin plugin (for Android Studio; starting from 3.0 presumably built-in) allows for converting Java code to Kotlin automatically. Obviously the outcome is not necessarily idiomatic Kotlin, just the most straightforward equivalent - but still, it's a very quick way of getting up to speed with the syntax.

I hope this will change Jetbrain's attitude towards supporting Kotlin Android rules in Bazel (or anything other than gradle). Last time I asked, they are not very interested[1].

[1] https://discuss.kotlinlang.org/t/android-support-in-kotlinc-...

Don't forget you can use Kotlin to write your build files for Gradle (since Gradle 3.0 was released almost a year ago) which Android Studio auto-completes 100% of the time (rather than 80% of the time as with Apache Groovy). Gradle 3.0 also switched to Kotlin as its "preferred" language for writing addins, so conceivably you could use the Kotlin language for everything in the Android build chain.

How would this help people who wants to use Bazel or any other build system other than Gradle?

For better or worse, Gradle is the official Android build tool, so why spend resources in something else?

Because Bazel produces faster, reproducible builds, and can far better combine native and JVM code.

It’s a huge improvement.

But isn't part of the Android SDK, Gradle is.

As I learned through the years, anyone that decides to step outside the SDK tooling accepts the lack of productivity that entails the extra work, making the unofficial tools fit into the SDK expectations.

So why should JetBrains spend development resources (work time * salary / hour) into something that isn't a standard tool just to get brownie points?

Because Bazel is partially already supported. Google uses it internally a lot, and a lot of the Android buildfiles have been / are being migrated step by step either from Make to Ninja, or from Make to Bazel, long term.

It isn't neither part of the Android SDK nor NDK, or even supported in Android Studio, which actually matters to Android developers.

Actually the NDK is not even finished migrating from makefiles into CMake, let alone switching to even something else.

As you describe it is work in progress, not fully done, without any perspective if it will ever be part of the official SDK.

Also last time I checked AOSP sources where actually slowly being migrated to GB, the only place where Go is kind of used in Android.

So what is again the business value of supporting an unofficial tool, spending development resources, just for getting a few brownie points?

Huh, that's a really useful tip, thank you.

Would be lovely if they officially supported Clojure too.

I'd love that too, but there is a startup time overhead with the Clojure runtime. Given the moves Google's made in recent wrt moving away from JIT for startup time reasons, this would be challenging.

I'm with you, but I think the size and startup time of Clojure might be a big hurdle.

If you want to use Clojure on Android, I'd recommend Clojurescript and React Native https://github.com/drapanjanas/re-natal

Google has chosen to support kotlin because the community has very strongly pushed in that direction.

I am not too familiar with Clojure, what would it bring us that kotlin (or java) don't have ?

Parenthesis.

And lots of other things too. I just wanted to make a lisp joke. I will see myself out.

As much as I want this, it's not going to happen for the simple reason that Clojure adds a big runtime and a huge startup cost on Android, which is unacceptable. It's fine for servers, but a total deal-breaker for mobile apps.

Kotlin on the other hand has a tiny runtime (< 1 MB before dead-code elimination etc with Proguard) and negligible startup cost - in fact several popular Android libraries have a bigger startup cost impact than Kotlin.

Steve Yegge had this to post about Kotlin:

http://steve-yegge.blogspot.com/2017/05/why-kotlin-is-better...

I love Kotlin and her twin sister Swift. They're both beautiful and allow you to code apps for the desktop, server, mobile, watch, TV, IoT, and everything in between.

They're here to stay and they're a joy to use. Jump on the happy wagon and join us!

I've avoided writing React Native modules in Swift because I don't want to add the Swift runtime. It would make my app a lot bigger, and while I love Swift, I'm fine writing a few lines of code in ObjC.

Will Kotlin add any extra data to an Android app? Does it have it's own runtime, or does it just compile down to the same bytecode as Java?

If the app size is equivalent to Java, then this is amazing. I love Kotlin, and will write all of my React Native libraries in it (as soon as there is some support.)

UPDATE: Looks like the Kotlin runtime is around 859KB. Maybe smaller after ProGuard? In the grand scheme of things, that's smaller than many web pages. But it's probably not suitable for an open source library.

I don't think Facebook would rewrite React Native in Kotlin. I've heard that they might be moving towards C++, so that more code can be shared between the different platforms.

Rewriting React Native with Kotlin would make a lot of sense. Kotlin compiles to Java bytecode, so you don't need to deal with JavaScript engines, serialization/deserialization, etc. Kotlin will compile to machine code, so it'll be supported with iOS with the same advantages. Kotlin performance is better than JavaScript. Kotlin has async constructions, etc. Kotlin could be compiled to JavaScript for web apps, so code reuse will work.

The only thing that Kotlin misses is XML Tags inside the language, but they could be modeled with DSL API.

That said, I don't think that Facebook would rewrite react native. It's an impossible task and they don't really need it. But I hope that some big player will replicate react native with Kotlin.

> Kotlin compiles to Java bytecode, so you don't need to deal with JavaScript engines, serialization/deserialization, etc.

I don't think the GP meant replacing JS with Kotlin, rather they're referring to implementing React Native modules in Kotlin instead of Java, keeping the JS part untouched. (As you may know, React Native modules/components require native implementations before they can be used in JS).

I hope that clears things up a bit!

Was hoping for golang but this is good too

Why haven't they supported Go on android?

Total guess, but maybe they see the actual usage numbers of developers that use Go? AND that number is not very high. Also, how well does Go translate into Android apps? Just a guess.

I like writing Go, and it's my go to (pun intended) for writing web API's. Building a framework around it for Android apps would be a mighty task. Kotlin makes more sense considering it's connection with the JVM.

I'll keep writing Java to build Android apps though. I'm sure it's "more fun" or whatever, but Java's worked just fine for me thus far. I'm used to the verbosity, and have no desire to start from scratch with another language. If some huge benefits were presented, I would. But, I'm failing to see any.

You can mix Kotlin and Java in the same project easily. I have a project where we have a bit of both. All the new code is written in Kotlin and some older features are converted to Kotlin when we feel like it.

I kind of gave up on Java and Android a few years ago and picked up Python. I have given Go a whirl... but it doesn't tick all the boxes for me. I really, really want to build apps for all the platforms with one language and awesome GUI's.

Go would require building a whole new set of APIs and massive work since Go does not interop with Java.

Kotlin, however, interops with Java nicely since it compiles to jvm bytecode. So there's no new APIs to build and no transition performance costs.

Although that said you can actually use Go on Android ( https://github.com/golang/go/wiki/Mobile ) but since Go is native code you're stuck with Android's NDK or dealing with JNI and the performance costs of that.

Java, Python and C++ are the actual workhorse languages at Google.

Go doesn't seem to be used that much other than a few known projects like the stuff that got re-written for YouTube or the download server.

You see this when new Web APIs are released, usually Go isn't part of the preview SDKs, and on Android all the work done on Go mobile has been done by people on the Go team or from the community at large.

Dart runs all of their AdSense code. I also believe your information about the usage of Go at Google is also out of date.

Dart runs the AdSense code, because the AdSense team rescued the Dart team when the decision came to them stop being part of Chrome development efforts.

Regarding Go at Google, if you have better sources of information to share with those living outside Mountain View, it would be very helpful.

I think Go needs and does very little marketing inside or outside Google. Despite what Go baiters say about its usage and lack of features like generics etc, it is now reasonably successful in industry. Unlike Dart they do not need to do constant hammering that a huge/critical application X inside Google is written in Go.

I've never heard of the story where the AdSense team rescued the Dart team. Do you have a citation for this?

The story as I heard/read somewhere I cannot at this moment recall (InfoQ, conference networking, Podcast, blog,...), goes like this.

Many of the important devs on the V8 team, like Gilad Bracha, were getting tired of working on the project and started to look elsewhere for a career change.

Allowing them to create their own vision what a JavaScript replacement might look like (aka Dart) motivated them to stay on the team and at Google.

When the Chrome team decided that they wouldn't be merging the Dart VM into Chrome at all and would rather focus on JavaScript, including their efforts for adding type annotations to JavaScript, the Dart team was going to be assigned new tasks.

However in the meantime the AdSense team had started using Dart and they enjoyed using it quite a lot, so a decision was made to move the Dart team away from Chrome into supporting the AdSense team as main role.

If this is not true, I would welcome any Googler that knows better, to correct me.

it's fair to say that Go is actually used more outside Google than inside Google. And to be fair I don't see Java or C++ specialists moving to Go when they'll loose a lot of their tooling and language features in the process. I like my enums explicit and my generics ,personally.

I think one of the things that get people excited about Go on desktop is it is one of the few well supported GC langs that compiles to an exe. There isn't anything else super compelling about it.

On android, everything gets AOT compiled on install already.

Because to support a language you need 2 things:

1) interoperability between existing ecosystem and APIs

2) development environment support.

In case of Kotlin Google had to do nothing: Kotlin is 100% interoperable with existing Java code and libraries, including Android APIs; as for the development environment, JetBrains (the company behind Intellij IDEA and Kotlin itself) provides the same level of development experience for Kotlin as for Java, which means that Android Studio gets the very same nice features for Kotlin.

Now, how would they get the same with Go? For interoperability they would need to either generate tens of thousands of bindings for existing APIs and provide a convenient way to include compiled Go binary as a static library. It is highly doubtful they actually can do, since they have been having troubles to do it for C or C++ code for a very long time. Or as alternative they can improve their support for native code, which then can be used as a base for interoperation with Go code; however it is still considerably less pleasant way to do things than in case of Java + Kotlin.

Now, as for the development environment, Google will have to basically create yet another IDE on top of Android Studio to support Go; they might take an existing plugin (which is not that great, compared to Kotlin support in AS/Intellij), but it means that they would have to collaborate in development on it, which in case of Google takes too much time. Another indicator of how difficult for them implement at least someway decent support for another language on their own is situation with native code - it's being in development for like 3 years, and still is highly unusable.

Jetbrains also have Gogland in preview, which is a top notch Go IDE. The bindings point is more likely to be the reason?

It's not a JVM language and probably partially also because Go doesn't have generics, so it's not even in the running.

The perf profile is also similar to java.

I think Go is never going to be officially supported on Android. Dart, though, seems more likely as it is Java like VM based language.

Go is going to have better support on Fuchsia OS from Google.

Dart is not a JVM Language. It can be compiled to the JavaScript or run in the Dart VM.

The wording was a bit confusing, but I think they meant "Java-like" and "VM-based" as separate things, not that Dart runs on the JVM.

Oh, it seems I've skipped "like" in "Java like VM based", sorry.

I don't doubt that Fuchsia will support Go, but Dart appears to already be Fuchsia's officially preferred userspace language (via Flutter).

Indeed. It seems preferred way for Fuchsia UI side. Go is more of infrastructure plumbing there. As someone who mainly work on backend stuff in enterprise apps I am happy with this situation.

What I am not happy with this whole browser platform embedded in frontend apps and called native and amazing. But that's for another discussion:-)

Kotlin 1.1 supports coroutines what IHMO makes concurrency in a GUI much nicer. For example, it has C# like async/await methods; but more flexible...

So what does it do better than C# 7's async/await?

Its more flexible and customizable, e.g. works with RxJava, CompletableFuture, JavaFX, Android... Moreover, you have more control where a coroutine is executed. https://kotlinlang.org/docs/reference/coroutines.html

Have you by any chance seen that I specifically mentioned version 7 of C#?

Which allows full control how async/await works, kind of like on the upcoming C++ co-routines, where async/await become syntactic sugar for blessed data structure.

EDIT: Should have provided the actual information.

The feature as introduced in C# 7 is called "Generalized async return types".

https://github.com/dotnet/docs/issues/1756

Keep in mind coroutines is very much experimental, things will change.

I should note that Kotlin now supports JDK, JS, iOS, and LLVM as backends. Gradle also announced support for Kotlin. This means you can write your Android app, iOS app, web browser app, desktop app, and your build scripts -- finally all in the same language.

That's a pretty absurd claim, their native implementation is not only experimental, the GC solution is "unknown". You can't make this stuff up, it will be years before anyone is writing production IOS apps in Kotlin.

Heck, their JS implementation still generates massive binaries. Targeting the JVM/Android? Sure, good to go; otherwise the promised land is a long way off.

"Unknown"? They have said from the beginning that it uses reference counting with cycle collection, for example in RELEASE_NOTES.md:

"Currently Kotlin/Native uses reference counting based memory management scheme with a cycle collection algorithm. Multiple threads could be used, but no objects shared between threads are allowed."

They have also said that it's pluggable and they might experiment with other collectors on different platforms, but it's hardly "unknown".

The size of generated JS is definitely a problem at the moment but they're working on it:

https://discuss.kotlinlang.org/t/kotlin-js-file-size/2501/2

The point is that the claim of cross platform everything is wildly unrealistic at this time. JVM/Android is production ready; javascript, getting there; native, not even close.

I don't doubt that 2-3 years from now Kotlin will have a cross platform solution, but to claim so today is borderline delusional. It's understandable that users are excited, Kotlin's on the verge of bigger things, perhaps even mainstream level adoption if everything falls into place, but there's a ways to go before they achieve one-language-to-rule-them-all.

Absurd, not really. I even forgot one of the most important platforms. It's very production ready on server and is highly supported by Pivotal for Swing Boot server apps.

It seems the only "beta" platform listed there is LLVM, which doesn't even work on Windows yet. The point is that we should expect these things to improve quickly. JetBrains are hardly hacks. Kotlin existed in production being used by major Android apps while significant libraries were still incompatible.

I doubt believe anyone read my comment and thought, "WOW, I should pitch this for production on every platform today without even investigating." It's a useful data point as proof of where they intend to be quite soon.

WOW, what?? That's amazing! I want to write some cross-platform native code for React Native modules, and I was considering Rust. But I will definitely have to check out Kotlin now.

The official tweet:

https://twitter.com/Android/status/864911929143197696

So where is the best place to learn Kotlin?

I am very interested as Jetbrains is also working on Kotlin to native translation. [1]

[1]https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-...

They link to resources at the bottom:

> For more information on getting started with the programming language, check out How to start using Kotlin[0] and the Koans tutorial[1].

[0]: This one's actually broken in the article, but: https://kotlinlang.org/docs/tutorials/kotlin-android.html

[1]: https://kotlinlang.org/docs/tutorials/koans.html

If you're already familiar with Android dev, using the built in Convert Java to Kotlin feature in Android Studio is invaluable, especially in the beginning.

I wonder if Android will ever support Go? Seems Google would want to do this.

I was about to reply that go seems more systems oriented, but on second thought that is really more of a self fulfilling prophecy. With the proper library support I bet go would be a great language for mobile development.

the bigger issue with Go is the binary size

Go (like other non-JVM languages) doesn't talk to Java APIs well - the JNI bridge is ugly and adds a severe performance penalty. Short of actually rewriting Android itself, it's probably not going to happen.

I'm curious to know, just from a general understanding - How much of the situation changes when Java 9 releases? Will it lead to some features in Kotlin becoming redundant/unnecessary, some other new features open up in Java 9, grass-is-greener situations, etc?

Java 8 won't be supported on Android, at least not on most devices, for a while still, so I can't see why the release of Java 9 would be a game-changer all of a sudden

Pretty big step up for kotlin. And for programming in general.

I'm assuming that this is going to work natively via LLVM, as Kotlin's original target was JVM bytecode, which should work fine on Android right now.

Today, Android cross-compiles JVM bytecode to its own non-JVM bytecode; I'd assume they'll continue using a two-stage approach for Kotlin.

Kotlin claims future capability for "Native" applications. I assume that this is separate from "Android" applications, even if these are compiled to native instructions.

Correct, they are working on targeting LLVM

hey maybe this means we will eventually be able to build apps in other languages to that target the JVM like Jython (or pure python would be cool).

Eh, I'm moving on from Python so if they never threw the ability to build apps for android with python that'd be fine, too.

Am I the only one that finds Java's (and Java 8's) syntax fine. I like the traditional type annotations and perceived verbosity.

Google/Android's answer to Swift?

I prefer to think it's an answer to java/oracle.

I was curious how this fits in to the bad blood between Google and Oracle over java, but the 'reporting' I've read on the usual tech sites appears little more than rehashing the Google press release. Does this help them build a road away from Java entirely eventually? Could Kotlin eventually provide a route away from the JVM, especially this Kotlin native stuff on LLVM?

Yes, they are extremely similar languages. You can see some of the similarities in this blog post: https://ragunathjawahar.wordpress.com/2015/03/18/my-first-io...

Congratulations to Jetbrains.

The Instamotor Android app is entirely built using Kotlin.

After becoming first officially supported non java language in android now, All eyes are on kotlin native!

If they can deliver good kotlin native experience, then kotlin is unbeatable

Will Google end up buying Jetbrains?

Where did Groovy go wrong ?

When it was created? Its dynamic types can often cause a headache (as you’ll notice when working with Grails, for example).

Groovy’s creator famously said that, had he known Scala, he’d never have invented Groovy.

That was 10 years ago. Last year he tweeted "I still love groovy (jenkins pipelines are so groovy!), java, go, typescript and kotlin. I don't use scala anymore."[1]

[1] https://twitter.com/jstrachan/status/784333918078169088

Looks like Kotlin will soon be skyrocketing to the top of the TIOBE charts.

And a little bit of drop in java ranking

God I hope so. Every time I see Java up there I feel the suffering of a million souls having to deal with it.

Most of these souls are perfectly happy with Java.

Stockholm syndrome anyone?

I write Kotlin on the backend now mostly but I never really minded writing Java either. It's a boring and predictable language with great tooling.

Disclaimer: I am always looking for that Unicorn. The one that will let me write my code once and run it on all platforms. I refuse to give up this quest.

I use Pycharm and have used other Jetbrains IDE's in the past. They make me soooo very happy to use. That is, I have tried almost every Python IDE and suped up Vim/Emacs; None of them came close to Pycharm for me. They know cross platform. Their IDE's are just as bad ass on the macOS as they are on Windows... again, for me.

They make IDE's for just about everything and I assume they are all of stellar quality. My assumption, as of about 30 minutes ago, is that Kotlin could be a great bet for cross platform development in the near, near future. Jetbrains has every reason for this language to succeed in as many places as possible. Web, Mobile and Desktop. The fact that it runs on the JVM and compiles to JS out of the box makes me wonder why I haven't tried it yet.

Funnily enough I was also looking for this unicorn recently.

I was aiming for Windows/Linux/Mac/iOS/Android.

In the end the two platform that were closest at the time (summer 2016) were HTML/Javascript and C#. Or C/C++ with OpenGL for the hardcore (not me!).

The real killer these days is the GUI toolkit. Ideally you'd want a SWT/Wx type wrapper around native widgets, most likely with a desktop flavor and a mobile one. Unfortunately nobody's investing in it, I think there's not enough money to be made. And there's no OSS community for it...

Actually, there is an animal exists that runs on Windows/Linux/Mac/iOS/Android. Unfortunately, it's not as pretty as a Unicorn. It's an ugly hybrid with lots of raw power. C++ + QT (Qt Quick) + Something that looks like JS. I have seen one very complicated iOS and Android app made with QT with very good results. But the programmer was a very good with around 20 years of experience.

"Disclaimer: I am always looking for that Unicorn. The one that will let me write my code once and run it on all platforms. I refuse to give up this quest."

Except all those platforms have different paradigms regarding UI, and different ideas regarding base components. Even if you could have your code run on all of them, you'd still be writing platform specific code.

It's perpetually surprising to me that there isn't more competition in this space. Have you tried flutter.io?

I've found something that could possibly be the unicorn: React Native. Facebook's official motto may be "learn once, write everywhere" but I don't care. I've found that it's completely possible to "write once, run everywhere", even if it's not officially supported.

I'm still a few weeks away from launching, but I'm writing a little game that I'm going to ship on iOS, Android, Windows Phone and desktop (UWP), and web (with react-native-web.) They all share 99% of the code, except for a few native modules.

I've had to do a ton of work to get all of this working, but I'm going to release all of my changes, open source libraries, and a boilerplate so that it's easy to get started.

After the initial release, I'm going to be adding support for Mac, Xbox One (UWP), Apple TV, and maybe Linux. Mac and Apple TV are both forks of iOS that share 90% of the native code. Xbox One almost works out of the box, and I just need to add gamepad support. Linux is the only platform that is missing - Canonical's Ubuntu fork has stalled and no-one seems to be working on it.

I'm also keeping an eye on Kotlin. I just found out that it might be possible to write cross-platform React Native modules using Kotlin. (I was planning to use C++ or Rust for some shared code.)

why not use llvm as virtual machine instead of JVM assuming backward compatibility is not an issue.

Backwards compatibility is an issue when 50% of users aren't even using Lollipop yet. Also LLVM is no longer an actual VM.

Is this official?

Edit: sorry, I completely forgot googleio is today, and i couldn't believe this kind of news comminng ftom non google domain.

Yes.

Yes, they announced it a few minutes ago on I/O

You'd know the answer if you'd taken the < 1 minute to read the article. It was mentioned in the opening paragraph.

Reply on news.ycombinator.com