[mobiletelephone]

I agree with your conclusion, but it actually could be possible for kotlin to be faster than java for practical purposes, despite running on the JVM. For example, it might be more expressive, allowing the user to give the compiler more information for better optimizations. We see this when C++ is sometimes faster than C.

[mike_hearn]

Kotlin code can be and sometimes will be faster than the equivalent Java code because Kotlin does lambda inlining on the frontend and does not rely on the JVM to do so.

That probably helps a lot, because it takes significant machinery in the profiling and JIT compilers to automatically eliminate the overhead of higher-order functions and the JVM can't always do it due to a problem called "profile pollution". Kotlin pushes a bit of the thinking onto developers, albeit aided by type hints, and then does the inlining itself in many cases. Especially helpful on platforms with weaker JVMs like older Androids (the upcoming Android update appears to have improved ART so significantly that it's now a serious competitor to HotSpot).

Whilst the article doesn't show any difference in lambdas I wouldn't expect it to show up in micro-benchmarks like this one because the profile pollution problem wouldn't occur. In any real app it would show up though.

Also when Kotlin inlines on the frontend it can also use reified generics in a few cases.

Finally, Kotlin provides features that developers can use to write more efficient code, I'm thinking about how easy it makes lazyness in particular. Whilst you always can write equivalent code in Java, it takes more effort to do so, meaning developers probably won't always bother.

[buremba]

"Finally, Kotlin provides features that developers can use to write more efficient code, I'm thinking about how easy it makes lazyness in particular. Whilst you always can write equivalent code in Java, it takes more effort to do so, meaning developers probably won't always bother." -> Agreed!