Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin, the Swift of Android

blog.gouline.net

Post reply on HN
Print view View original

91–100 of 114 posts

Re: Kotlin, the Swift of Android

#91

Post by bad_user »

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.

Re: Kotlin, the Swift of Android

#92

Post by bad_user »

pavlov wrote: 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.

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.

Re: Kotlin, the Swift of Android

#93

Post by orangy »

mike_hearn wrote: post #46
wasyl wrote: post #43

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

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(value: T, fn: (T)->R): R = fn(value)

    inline fun identity(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.

Re: Kotlin, the Swift of Android

#95

Post by Zigurd »

masklinn wrote: post #9
PudgePacket wrote: post #4

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?

It's way more fucked up than that, Dalvik is limited to 65k invocable methods per dex file: https://medium.com/@rotxed/dex-skys-the-limit-no-65k-methods... > 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 met…

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.

Re: Kotlin, the Swift of Android

#96

Post by rst »

dtech wrote: post #52
higherpurpose wrote: post #25

Earlier quoted context omitted.

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

Re: Kotlin, the Swift of Android

#97

Post by seunosewa »

bad_user wrote: post #92
pavlov wrote: 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.

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…

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.

Re: Kotlin, the Swift of Android

#98

Post by vorg »

gruvector wrote: post #81
higherpurpose wrote: post #74

Earlier quoted context omitted.

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.

> Go is pretty low level compared to (even) java

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?

Re: Kotlin, the Swift of Android

#99

Post by vorg »

gruvector wrote: post #80
aikah wrote: 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.

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

Re: Kotlin, the Swift of Android

#100

Post by vorg »

rufugee wrote: post #86
gruvector wrote: post #80

Earlier quoted context omitted.

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

> the great java integration groovy brings

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.

Post reply on HN