I tried Kotlin to write the first version of a small internal application used at the company I work at. On the plus side is IDE support and the fact that you can mix and match Kotlin with existing Java code.
In the end though, I found the syntax "funny" in some places and slightly less verbose than Java but not enough to justify using it. The underlying Android API is so verbose that Kotlin by itself is nearly useless.
We ended up dropping Kotlin and rewriting the thing in Java. In terms of lines of code both versions are nearly the same.
Kotlin is very similar to Scala, but far less ambitious and not as focused on functional programming. In fact there have been various posts pointing out the similarities between Scala and Swift. It's rather pragmatic but there hasn't been much interest in it so far. Perhaps things will pick up after hitting v1.0. Pitching it as a Java substitute for Android would be a clever move. Java 8 is a poor substitute for Kotlin or Scala, and on Android you're stuck on even more archaic syntax. I'd be glad to see Kotlin replace java on Android.
For Activities, Fragments etc. I can easily believe that the innate verbosity of Android API defeats the purpose of using something like Kotlin. But for business logic, model classes etc.?
Google really needs to begin rewriting all Android APIs in Go. Not an easy task, but beats doing nothing, and also using something like Kotlin to make Android development slightly better.
Go is pretty low level compared to (even) java, not much of a win in terms of expressiveness or error handling. Seems like a lot of effort with minimal benefit.
I've found Go and Java to be at the same level of abstraction. Go has interfaces and structs, but leaves out implementation inheritance because its authors feel that's one of Java's bad points. Go also leaves out method overloading which causes us to think hard about what to name the numerous methods.
I don't know about the suitability of Go for Android though. Does Google have a secret project going on?
Officially, Java is the language of Android. Have a look at the last I/O fireside chat if you want to hear from them. Again, officially, they "don't see what rewriting all the API in another language would bring".
Google is deeply involved in improving Java with projects like Guava, Dagger, ..
There is a project to make Go run on Android, but it is only a hobby project from one of the Go engineers and only target the NDK (so no access to Android's APIs).
We have no way to know what they are working on under the covers, we need to assume that as far as we know, Java is here to stay...
IMHO, with Dagger, Guava, EventBus and a couple other niceties, it is possible to be productive with Android.
For me the biggest weakness of the platform from a dev point of view is that many things that are part of the platform on iOS (like elements of a ListView animating themselves when added/removed) need to be coded (with dirty and lengthy hacks). This part is improving (I am looking at you RecyclerView & RenderThread) but there is still a lot of ground to cover.
Not so secret. Go's 5g compiler can produce ARM code, runnable on an Android device. But Android's APIs are mostly Java, so for regular apps you have little benefit in using Go; for games, you could gain something.
Android apps tend to be compressed for distribution by means Proguard and Pack2000. Not perfect, but it does tree-shaking and so normally you pay only for what you use.
I don't really buy the small JAR size argument. In a real project, you care about not reinventing the wheel, so you end up importing needed dependencies anyway, like from apache commons or guava, or stuff for serialization/deserialization, or whatever - I would rather have a couple of hundred KBs extra than having bugs or spending effort on reinventing the wheel. Scala's library for example is pretty big (can't remember the size, 10 or 20 MB?), but it has things I want in it and with tree shaking it can be translated in a dependency of very reasonable size (couple of hundred KB), a technique which also makes feasible Scala.js, a Scala to JS compiler.
It's an important point in Kotlin's favour that it's developed by JetBrain, the company that makes Google's official Android IDE.
If/when Google decides it's time to sanction a Java replacement on Android, the language designed by their tool provider seems like the obvious choice.
Well that pretty much is what happens. JetBrains wrote IDEA and the Android support for it. Google made some small modifications (some good, some detrimental), and packaged it with the Android SDK.
The biggest change was to switch to gradle which is a more powerful build system but also much buggier (at least in the current Android Studio). They also lots of useful Android-related tools and lints, and a fair helping of UI bugs.
It's Google the one that added all of those nifty Android-specific features, like seeing how your app looks on multiple resolutions/screen sizes at once.
It's not only about Android. Kotlin is one of the few languages that's developed hand in hand with IDE support. That means you've got Java-class IDEA support for the language, including (interestingly) a Java to Kotlin converter tool! It's not like many languages where you end up having to sacrifice all your nice refactoring tools and libraries to use it. For this reason alone Kotlin is a natural upgrade path for many Java shops.
By the way, this converter is not without flaws. Eg. if you convert an Activity written in Java to Kotlin, method signatures do not match (because in Kotlin it should be Bundle? instead of Bundle and so on, since they are all nullable), and that results in baffling error messages that you're trying to override non-existent methods, it's not easy to figure out what's wrong.
Like much of Kotlin, it's sort of rough. I would not want to recommend it to anyone for an industrial project today, it's just not 1.0 material. For example the Kotlin API (extensions to Java classes mostly) is hardly documented at all.
That's putting the cart before the horse. Google's already shown with the Dart project that they're willing to invest in building tools for their own technology. Android Studio hasn't been the official Android IDE for very long either.
Doesn't make sense to replace Java with another JVM language. If you're thinking about the problems they've had with Oracle, then it's not Java the language that's causing problems, but rather Java's standard library and their VM that's meant to be not-quite-a-JVM-but-close-enough.
As a standard, a common denominator, Java the language is a good choice because it is popular. Other languages running on top of the JVM can be used on top of Android as well, mostly anyway, at least if you refrain from generating and interpreting bytecode at runtime.
The JVM is the best thing about Java. It's really good at optimizing statically typed code. The problem is the language and culture of verbosity that it spawned. Alternate languages are great but may not go far without Oracle's support; Oracle would rather add features to Java than seriously support other languages since they have so much code written in Java already and control it. And the new features added to Java will clash with features added to the other languages when Java was more primitive.
Google will probably not be sanctioning a replacement for Java on Android for quite a while, which doesn't prevent Kotlin from being a very, very good second language for the platform.
One of the main advantages of Kotlin over Scala on Android is that Kotlin is a small increment over Java with very little jar size and language overhead.
If Kotlin is a small improvement over Java, then the benefits of picking it over Java are outweighed by the advantages of picking Java, by the simple fact that Java is probably the most popular language in the world and as a consequence it is being taught in schools, it has extremely good IDE support, it is very stable, the whole of Android's documentation is written for it (so you can just copy/paste stuff) and so on.
Personally I do not care about how writing the actual code makes me feel or whatever, what I care about is how well the final artifact works versus the effort I've put in making it work. The act of learning and using a new language is completely useless if the new language doesn't make possible and/or comfortable new abstractions that help me in managing complexity (that would be otherwise not possible or very painful in Java).
Therefore personally I'll take languages like Scala or Clojure any day, because in spite of the learning experience being painful, at least I got something out of it.
N.B. - I don't really know Kotlin, I only played with it and I don't have an opinion on it yet - might turn out to be a good language for me, but I hope this will not be the reason promoted for using it, because it's a very poor reason. Granted, it could be popular, just like CoffeeScript, but then again, I also hate CoffeeScript.
On the small JAR size - granted that's useful, but Android apps tend to be compressed for distribution by means Proguard and Pack2000, which does tree-shaking, not perfect but theoretically you pay for what you use and in practice it works very well, not being worse than the result of importing dependencies in your project like from Apache Commons or Google's Guava or whatever and paying a couple hundred KBs for it - which counts, but nothing tragic.
I have been fiddling with Kotlin for last few days. It is trivial to get it working in Android Studio, which is a plus already. It's not nearly as verbose as Java, and for one thing, it gives me LINQ that I've been missing from C#.
I've had opportunity to play with it (at work), but given the price, not a likely choice for my hobby projects. It's not without its drawbacks, either. Since it's not native development (for Android), we 'e adding more moving parts into the equation.
And, for instance, most of the sample apps for Xamarin.Forms wouldn't even build when I tested Xamarin.
I had to fix folder paths (to Android SDK) manually.
The product is superb, but Android is under rapid development and Xamarin folks will always have to play catch up with them.
And in meantime, weird things - all sorts of incompatibilities - are bound to be popping out.
How does Kotlin compare to Groovy for Android development? Are they similar beasts when used for Android development, as in they both need to import their runtimes?
The article touches upon that: Kotlin has a runtime you need to import, but it's significantly lighter-weight than Groovy's or Scala's, and the method-count overhead is relatively low (half that of Guava without proguard).
Looking at the relevant jars, groovy 2.3.6 is 4.3MB[0] while Kotlin 0.8.679 is 353KB[1] (there's also a 503KB kotlin-stdlib, not sure what the comparison should be to but it compares very favorably even including both)
For other references, Scala 2.11.2 is 5.3MB and Clojure 1.6.0 is 3.5MB[3]
Just a side question, the author mentions method count as a downside of introducing alternate JVM languages. Does the method could slowdown/bloat apps somehow?
> You can reference a very large number of methods in a DEX file, but you can only invoke the first 65536, because that’s all the room you have in the method invocation instruction.
> […] the limitation is on the number of methods referenced, not the number of methods defined. If your DEX file has only a few methods, but together they call 70,000 different externally-defined methods, you’re going to exceed the limit.
I have seen some big, important commercial products run up against this limit, but in all the cases I have seen, architectural and implementation approach alternatives that would not approach this limit would have resulted in better outcomes for both users and developers.
I can also understand why Google has to be responsive to developers who hit this limit. But if you are stating from a clean sheet, there's no reason to come close to having this bite you in the ass.
You're talking about a similar but different issue: there's a fixed-size meta-information buffer, if you go above you crash. Increase the size of the buffer and you're good to go (which is what more recent android versions have done), the new ART might make the buffer dynamic instead of static (no idea).
The 65k method problem is a problem of the dex format itself, because method-invocation instructions take "the method" as a 16-bit index, it can't be fixed by the runtime, the dex format has to be changed to fix it (either by adding new opcodes or by changing existing ones).
Around 27:55 they discuss that they plan on lifting the limit. Indeed modifying the dex format is talked about and it is mentioned that it is a future goal.
They also speak about multidex, the interim backwards compatible fix which does not require modifying the dex format (but uses a hack) and will make modifying the dex format easier in the future.
No it's not - the limitation is part of DEX file format (it only has 16-bit method counter). ART is a runtime which runs these DEX files so it can't help there.
To change this, Google would have to update the file format and somehow ensure dual format compatibility when running.
the article linked in parent addresses that directly:
> And yes, you got it right. This issue won’t disappear even when Android will switch to the new ART runtime, unless Google decides to “fix” the DEX format or ditch it for another one.
No, but older Android versions have a maximum 64000 method limit. I think it has been fixed for later versions, but I am really not sure. There have been some blog posts about Facebook's (controversial) attempts to work around this limit: https://www.facebook.com/notes/facebook-engineering/under-th...
Not older. All. It's a limitation of the file format, not the runtime. It's a common misconception that it's fixed in later versions, because Facebook ran into a very similar (but different) problem that is fixed on newer devices (the one you linked to).
Android 4.0 introduced a new set of Dalvik instructions that supported larger methods IDs, but they were never used and were eventually removed. ART may have lifted the method limit, but I haven't seen any specific mention of it.
No.
However, there is a hard 65k limit to the number of methods that the dex format can manage.
The libraries enter into account, with google play service taking 20k entries.
All is not lost though : the limitation is going to go away in the near future.
Kotlin looks like a very nice addition to Android ecosystem. It meshes pretty seamlessly with Java and takes a few of the obvious syntactic pains away.
I think as the Android build system improves using other languages will become more common.
Swift has algebraic data types and pattern matching, this doesn't. It just seems to be Java with a paintjob and some bells and whistles tacked on. I don't see the point of such a timid new language.
Ceylon does better in this regard [1]. Ceylon and Kotlin share some features and aesthetics but Ceylon provides a lot more power over java8 than a nicer syntax for lambdas, e.g. algebraic types. I'm also excited about Ceylon's module system [2].
literally the third sentence: "For the desperate and adventurous there are the JVM alternatives like Scala and Groovy, but using them with Android is expensive: importing a language means importing the whole runtime, which is a nightmare for the package size and method count"
Java 8 does introduce a few features that are available in Kotlin, but AFAIK Java 8 won't be available for Android for some time. In addition, Kotlin makes a lot of constructs more succinct, including but not limited class definitions. So it's not only about what it adds, but what it "takes away" too IMHO.
> AFAIK Java 8 won't be available for Android for some time
Pretty sure it will never be available on Android. Best case scenario Google moves away from it. Worst case, it will add some new, similar features to Dalvik VM. But I doubt they are considering adopting Java 8.
Do you have any basis for these claims? Java 8 contains many useful language improvements and Google has shown with Java 7 that it will adopt these (albeit incredibly slowly)
Remember the Google/Oracle lawsuits over the use of Java technology in Android? Bringing in JVM changes from newer Java releases risks giving Oracle grounds for another lawsuit (covering the patents and whatever copyrights may apply to the new features), and it's not likely Google wants to run that risk.
(This is why the Java 7 features that they have adopted are the "syntactic sugar" that doesn't require JVM changes, and leaves the code running in the phones as-is.)
It has only adopted Java 7 features which are either syntactic sugar or library extensions. (E. g. everything where the Java class file version wouldn't have mattered anyway).
Java 8 (and Java 9 and Java 10) are completely different, with huge, mandatory changes to the class file format and the virtual machine.
Kotlin has stuff that's unlikely to appear in Java, such as reified generics - Java has already chosen type erasure generics instead. I wouldn't bet a penny that they ever change this approach if they didn't go with it from the start.
In fact Kotlin doesn't have reified generics. This idea was planned in the beginning and was reflected in the old docs but abandoned later. I believe there's no reference to reified generics on the new web site anymore.
Java is getting reified generics via a really cool mechanism called classdynamic (which also enables efficient implementation of tuples). This is pretty much necessitated by value types. See project Valhalla: http://www.infoq.com/news/2014/07/Project-Valhalla
Interop with existing code, access to a large developer, infrastructure and mindshare - especially in enterprise where take up of new languages is more considered?
Does anyone have some performance comparison betweend projects written in pure Java vs straightforward Kotlin? I don't feel that method count is performance measure, I'd rather see some fps, method calls/sec or something like this. Or I'm wrong about method count?
There was someone from JetBrains doing profiling and chatting about it in #kotlin (freenode IRC) the other day. Oddly, he found some things got faster in Kotlin for no obvious reason. Some JVM optimisation magic, I guess.
Kotlin is a much more pragmatic language than many such new ones. They are building it for use in their own products including performance sensitive products like IntelliJ. For example it has an inline method attribute. This may seem remarkably low level for a modern JVM based language intended for industrial use, but there's a point to it: it lets you use lambda functions and misc features that rely on them without extraneous memory allocations. Applied consistently this sort of thing can make the difference between "a lovely language that's too expensive to use" and "a lovely language that is deployable". It's not auto-inferred because otherwise you wouldn't be able to make libraries that have stable ABIs with Kotlin.
Generally they seem to be targeting zero performance degradation over Java even when using the advanced features, which is nice to see.
Yep, I agree. Mostly because it was me digging into JMH :) Indeed we are measuring and optimising. This is still early work in progress, but we have some good results already:
inline fun calc<T, R>(value: T, fn: (T)->R): R = fn(value)
inline fun identity<T>(value: T): T = calc(value) { it }
// This is optimised down to loading constant value 1 into variable x
val x = identity(1)
Besides having nice syntax for lots of everyday things Java developers are doing, we want to provide means for doing it effectively, clearly and maintainably.
Any reason to use this over Groovy ? Will Groovy has a few drawbacks, i found it much simpler and easier to use than scala.I personnally prefer a quick java over something that has to much features.Anybody tried both and can compare?
Groovy performance is pretty poor in general and is mostly used for writing build scripts. It's a scripting language whereas Scala and Kotlin are better suited to writing large systems. Groovy seems to have stagnated outside of its use with gradle, whereas Scala continues to grow.
> Groovy seems to have stagnated outside of its use with gradle
I don't think Gradle will be using Groovy for too much longer. I looked at the source code for the recently released Gradle 2.0 and they'd replaced almost every Groovy source file with a Java version - only Groovy files specifically related to the DSL were left. And I suspect Gradle will soon open up its configuration as an API any language can use.
I'm curious...why do you say it has stagnated? Seems to still be pretty popular...especially in the gradle and grails spaces.
I've done quite a bit of groovy and have really enjoyed it. After years of doing java, and then years of ruby, and then trying to go back to java, I really struggled with rationalizing the move to myself given the immense amount of extra work java required to do anything productive. Groovy made the jump palatable, and in many ways I prefer groovy to ruby.
That said, I haven't written any code which is particularly performance sensitive yet. However, groovy now has @CompileStatic, so you can statically compile the perf sensitive bits. I'm sure that doesn't completely solve the problem, but it's an option.
I really do hope Kotlin succeeds thought. Having something in the middle of groovy and scala syntax-wise with no performance concerns and the great java integration groovy brings would be spectacular.
I recently wrote some scripts using Clojure to test some Java I'd written. It worked great, and I could use a macro to get rid of some duplication that functions couldn't.
You can write shared functionality in pure Ruby using RubyMotion then write your view layers for iOS and Android and have them each compiled correctly to native apps for each platform.
Yeah, but there are people who'd rather use Haskell, Clean, Agda or Idris. Kotlin, Swift, Rust and other such things seem like a reasonable middle ground from this perspective.
Eventually you can write shared functionality in pure Ruby.
RubyMotion 3.0 for Android is still in the early beta phase and it probably won't be publicly available before the end of the year (it's not been announced, but I've seen the beta and that's my guess).
I've been looking a lot at Scala and kotlin recently. Other differences aside, Kotlin has an 800kb runtime compared to Scala 2.11's 11mb runtime. That's quite a difference
Your final app with Scala may well be smaller than with Kotlin - Scala makes very high level abstractions possible, and while the standard library is large, anything you don't use won't be included in your app. Kotlin always struck me as a bit halfhearted - if I'm going to go to the effort of learning a new language, I want one that gives me a real power boost, not just a small incremental improvement.
Even the whole library jar file which is much more than just the runtime is only 5.5 MB.
But even then it doesn't matter anyway. Android apps are ProGuarded before deployment (regardless of the language used) and the overhead in Sclaa's case is a few dozen kBs.
The less code has to be converted to the DEX format, the better. Sure, build tools have improved somewhat (incremental DEX compilation comes to mind) but, still, every time I pull in some rather big (~1 MB) .jar file in my project I get noticeably longer build times for non-production builds.
With a 11 MB dependency, even production builds take considerably more time to complete and that gets in the way when you want to test the app on a production setting and you have to wade through a lengthy build process each time you fix a bug.
I gave up trying to set it up for Android. It just sucks, and there is nothing but random blog entries on how to get it done. If someone pointed me to reliable resources on how to get it to work, I'd appreciate it very much (as I like the language itself)
I can't remember anymore what I tried and what I didn't :) At the end, I mostly tried not to bang my head against the wall.
Anyway, even your second link stresses: "The primary IDE recommendation is IntelliJ, not Android Studio nor Eclipse". My IDE of choice is Android Studio, and it not being particularly recommended is a red light to me already. Maybe I'm just traumatized.
I'm surely lazy. I wish Google made Scala support for Android official and integrated it seamlessly.
> Anyway, even your second link stresses: "The primary IDE recommendation is IntelliJ, not Android Studio nor Eclipse". My IDE of choice is Android Studio, and it not being particularly recommended is a red light to me already. Maybe I'm just traumatized.
Seriously? Android Studio is just a stripped down IDEA with an extra plugin anyway. If you already use AS, there is zero reason not to just import your config into IDEA instead.
That recommendations is strange. The directions just have you include an almost standard version of the IntelliJ plugin for SBT (it is the standard plugin with an extra bug fix). So, any of these IDEs should work without issue. You just need to set up the standard SBT plugins for integrating those IDEs.
In the end though, I found the syntax "funny" in some places and slightly less verbose than Java but not enough to justify using it. The underlying Android API is so verbose that Kotlin by itself is nearly useless.
We ended up dropping Kotlin and rewriting the thing in Java. In terms of lines of code both versions are nearly the same.