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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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:
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.
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.
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.
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).
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.
- 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.
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.
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.
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
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?
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!).
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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 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].
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.
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.
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.
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 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).
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:-)
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.
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.
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 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.
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.
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.
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.
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".
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:
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.
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.
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 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.
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
Kotlin claims future capability for "Native" applications. I assume that this is separate from "Android" applications, even if these are compiled to native instructions.
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?
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]
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.
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.)
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.
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)