Live data from Hacker News

Kotlin, the Swift of Android

blog.gouline.net

81–90 of 114 posts

Re: Kotlin, the Swift of Android

#81

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

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.

Re: Kotlin, the Swift of Android

#85

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

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

Re: Kotlin, the Swift of Android

#86
post #76

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.

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.

Re: Kotlin, the Swift of Android

#88
post #27

Earlier quoted context omitted.

Is this limitation going away (or otherwise obviated) by ART?

Yes, but not just yet: https://plus.google.com/107130354111162483072/posts/VEy3JChn... Mentioned at about 27:55 in this podcast where a member of the ART team is interviewed: http://androidbackstage.blogspot.se/2014/08/android-develope...

Just so you know, your link lead to a 404

Re: Kotlin, the Swift of Android

#89
post #15

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.

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.

Re: Kotlin, the Swift of Android

#90

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?

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.
Post reply on HN