Kotlin, the Swift of Android
blog.gouline.net
blog.gouline.net
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.
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?
See a small overview: http://www.infoq.com/news/2014/06/golang-google-android-nati...
A JVM-compatible language which is better than Java, e.g. Kotlin, would be a boon for regular Android development.
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.
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.
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.
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.
Still, beats Eclipse by a country mile.
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.
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.
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.
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.
BRB, converting my entire codebase.
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]
[0] http://mvnrepository.com/artifact/org.codehaus.groovy/groovy...
[1] http://mvnrepository.com/artifact/org.jetbrains.kotlin/kotli...
[2] http://mvnrepository.com/artifact/org.scala-lang/scala-libra...
[3] http://mvnrepository.com/artifact/org.clojure/clojure/1.6.0
> 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.
To change this, Google would have to update the file format and somehow ensure dual format compatibility when running.
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...
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.
The question was whether ART would fix the issue. The answer is not "yes but not yet", it's "no" because the runtime has no bearing on the issue.
> 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.
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.
I think as the Android build system improves using other languages will become more common.
1: http://ceylon-lang.org/documentation/1.0/faq/language-design... 2: http://ceylon-lang.org/blog/2013/04/11/about-modules/
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.
Java 8 (and Java 9 and Java 10) are completely different, with huge, mandatory changes to the class file format and the virtual machine.
(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.)
Also, Kotlin can compile down to JS and can thus target another Google platform - ChromeOS/Chrome - with the possibility of shared code.
also java 8 doesn't have eatures like string interpolation, default params, etc.
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.
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)
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.
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'd rather use Ruby than Swift or Kotlin.
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).
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.
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.
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.
And even if there was, it wouldn't matter because it would be done once and then deployed directly on the development device.
Really, can we just stop making stuff up?
[1] https://github.com/jberkel/android-plugin/wiki/getting-start... [2] https://github.com/pfn/android-sdk-plugin#usage
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.
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.
I don't understand why this is preferable.
if (text2 != null) {
text2.replace()
}
"For those familiar with Objective-C, this is similar to categories."
Or just the same as extension methods in C#...