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

Kotlin Post-1.0 Roadmap

blog.jetbrains.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Kotlin Post-1.0 Roadmap

#21

Post by yole »

systems wrote: post #11

is the plan for koltin to replace java in the development of jetbrains products if yes, then i would assume the primary objective should be performance .. but this doesnt seem to be the case and my question is, is there any jvm language which is faster than java

Yes, the plan is for Kotlin to replace Java at JetBrains. I don't see how the performance requirement follows from that. The performance of JetBrains products is determined far more by the implementation algorithms than by the compiler used to build their source code. Kotlin's performance is on par with Java, and that is all that JetBrains needs for its internal use.

Re: Kotlin Post-1.0 Roadmap

#22

Post by [deleted] »

yole wrote: post #20
V-2 wrote: post #9

This is awesome news. yield-return semantics was something I missed dearly. Note that we’re still in the process of estimating the effort needed to implement this feature, and we don’t know whether it would be reasonable to support it in the 1.1 timeframe or it would be postponed to a later release. :) I can already tell you: yield is probably doable, async-await will have to be postponed.

As the post says, yield and async/await will be based on exactly the same mechanism. Either the entire mechanism will be implemented, or it will be postponed.

[deleted]

Re: Kotlin Post-1.0 Roadmap

#23

Post by lmm »

bejar37 wrote: post #19
mike_hearn wrote: post #6

Earlier quoted context omitted.

Kotlin has things Scala doesn't, like efficient optionality in the type system, and better Java interop. These are things that the Scala guys probably aren't interested in adding, and likewise, the Kotlin guys don't want to add some things that Scala has, like implicits. So thinking of it as a one dimensional line isn't really correct. Kotlin and Scala overlap in many ways, but the ways in which they don't (and will…

> Kotlin has things Scala doesn't, like efficient optionality in the type system Honest question - what is it that makes Scala's optionality inefficient compared to Kotlin? I'd never heard of this before.

Scala Some is a box (i.e. it takes up 8 bytes on top of whatever's in it). It would be nice to represent Some(x) as just the value x (at the Java bytecode level) and None as null. The problem with that is that if you have an Option[Option[A]] you can't tell the difference between None and Some(None) (which might be semantically important), and whatever you do to solve this your Option is no longer generic and behaves in different ways depending on what's inside it, which is a disaster for being able to understand and reason about code.

Kotlin treats nullability as an ad-hoc special case. This allows them to save those 8 bytes occasionally, but it means you simply can't handle optionality generically (in Scala you can write methods that will work generically with Option and also with other cases, e.g. "sequence" does the same thing when you call it on a List[Option[Int]] or a List[Future[Int]] or a List[Writer[String, Int]] or... and it all makes sense, because Option is just another plain old type in the language). IMO that's the wrong tradeoff for almost all use cases, but evidently the Kotlin folk disagree.

Re: Kotlin Post-1.0 Roadmap

#24

Post by xaduha »

jkot wrote: post #5
acjohnson55 wrote: post #3

While the new features look great, I still can't help but feel like there's a lot of redundancy compared to things that are already commonplace in Scala. Fast forwarding 2 years, I think Kotlin will still be catching up with where Scala is today, and Scala may have migrated to Dotty / 3.0 by then. Of course, there's still plenty of room for both languages, and I'm sure Kotlin will introduce interesting innovations of…

Kotlin will be always catching up. Scala is more research oriented, Kotlin is a bit more conservative and pragmatic.

It's quite possible that in many senses Kotlin will overtake Scala. Maybe not in terms of advanced language features, but in terms of adoption, tooling.

Re: Kotlin Post-1.0 Roadmap

#25

Post by gregschlom »

lmm wrote: post #13
systems wrote: post #11

is the plan for koltin to replace java in the development of jetbrains products if yes, then i would assume the primary objective should be performance .. but this doesnt seem to be the case and my question is, is there any jvm language which is faster than java

All JVM languages "are" the same speed, because they compile to the same bytecode. OTOH some languages make it more practical / cheaper to write higher-performance code, e.g. in Scala you can use @specialized to automatically generate unboxed special cases for generic code that you'd have to write (and keep track of) by hand in Java. But if you ask "in which JVM language is it most practical/cheapest to write feature…

They compile to the same bytecode, but some languages may have features that compile to a lot more bytecode than others. A dynamic language such as Clojure, for example, is definitely slower than Java, although they are both JVM-based, because it has to do a lot more.

Re: Kotlin Post-1.0 Roadmap

#26

Post by mike_hearn »

lmm wrote: post #8
mike_hearn wrote: post #6

Earlier quoted context omitted.

Kotlin has things Scala doesn't, like efficient optionality in the type system, and better Java interop. These are things that the Scala guys probably aren't interested in adding, and likewise, the Kotlin guys don't want to add some things that Scala has, like implicits. So thinking of it as a one dimensional line isn't really correct. Kotlin and Scala overlap in many ways, but the ways in which they don't (and will…

Scala does want efficient optionality in the type system - just not at the cost of a consistent representation of optionality. I'm sure an optimization for the common case would be very welcome. I constantly see Kotlin advocates claiming better Java interop but I don't see how; Scala already has 100% Java interop as far as I can see.

Luckily JVM languages mostly interop with each other very well and the question is just convenience and efficiency.

For instance, Kotlin is using the same collections library as Java. So there are no adapters or conversions needed. Scala has its own collection library instead.

Scala has some constructs that can make it impossible or very difficult to call code from Java. Kotlin doesn't.

Re: Kotlin Post-1.0 Roadmap

#27

Post by mike_hearn »

lmm wrote: post #23
bejar37 wrote: post #19

Earlier quoted context omitted.

> Kotlin has things Scala doesn't, like efficient optionality in the type system Honest question - what is it that makes Scala's optionality inefficient compared to Kotlin? I'd never heard of this before.

Scala Some is a box (i.e. it takes up 8 bytes on top of whatever's in it). It would be nice to represent Some(x) as just the value x (at the Java bytecode level) and None as null. The problem with that is that if you have an Option[Option[A]] you can't tell the difference between None and Some(None) (which might be semantically important), and whatever you do to solve this your Option is no longer generic and behaves…

Unfortunately boxes are not so efficient :(

A box takes at least:

• 4 bytes to point to it, unless you need a big heap and OOP compression isn't usable, in which case it's 8 just on the pointer.

• Either 4 or 8 bytes of mark word, depending again on 32 vs 64 bit mode.

• Either 4 or 8 bytes of class pointer, ditto.

• Then another 4 or 8 bytes for the pointer inside the box.

• GC algorithms impose some additional overhead too.

That's hoping there's no alignment padding going on.

If the JVM supported real value types, then a lot of this overhead would boil away, but not always all of it.

When you use Option[] as a local variable or as a return type of a method, then HotSpot can sometimes optimise it out using escape analysis. Unfortunately the escape analysis in the C2 compiler is quite conservative and can often fail. The Graal compiler has a different design for its escape analysis and can remove the overhead a lot more often. Graal does show better speedups on Scala code than on Java code:

http://lampwww.epfl.ch/~hmiller/scala2013/resources/pdfs/pap...

(old paper)

The ability to nest optionalities is not something I've wanted to do so far, whereas the ability to freely represent optionality without having to worry about cost is quite freeing. I think Kotlin has the right tradeoff here, especially as in the rare cases where you do want the ability to represent Optional> you can just use the Optional class from the Java 8 standard library to do so.

Re: Kotlin Post-1.0 Roadmap

#28

Post by mike_hearn »

gregschlom wrote: post #25
lmm wrote: post #13

Earlier quoted context omitted.

All JVM languages "are" the same speed, because they compile to the same bytecode. OTOH some languages make it more practical / cheaper to write higher-performance code, e.g. in Scala you can use @specialized to automatically generate unboxed special cases for generic code that you'd have to write (and keep track of) by hand in Java. But if you ask "in which JVM language is it most practical/cheapest to write feature…

They compile to the same bytecode, but some languages may have features that compile to a lot more bytecode than others. A dynamic language such as Clojure, for example, is definitely slower than Java, although they are both JVM-based, because it has to do a lot more.

Kotlin relies quite heavily on bytecode level method inlining, for instance.

The advantage is that it makes code written in a functional style effectively free (well, almost, unless you could gain performance from step fusion). The disadvantage is that the JVM wasn't designed for that and it messes up stack traces.

Re: Kotlin Post-1.0 Roadmap

#30

Post by ta_donk_gt »

lmm wrote: post #8
mike_hearn wrote: post #6

Earlier quoted context omitted.

Kotlin has things Scala doesn't, like efficient optionality in the type system, and better Java interop. These are things that the Scala guys probably aren't interested in adding, and likewise, the Kotlin guys don't want to add some things that Scala has, like implicits. So thinking of it as a one dimensional line isn't really correct. Kotlin and Scala overlap in many ways, but the ways in which they don't (and will…

Scala does want efficient optionality in the type system - just not at the cost of a consistent representation of optionality. I'm sure an optimization for the common case would be very welcome. I constantly see Kotlin advocates claiming better Java interop but I don't see how; Scala already has 100% Java interop as far as I can see.

> I constantly see Kotlin advocates claiming better Java interop but I don't see how

I think generally when people say this they mean things like:

1. You can freely mix and match Java and Kotlin files in the same package

2. Being a more lightweight layer on top of Java makes interop with all Java environments (specifically Android) more practical

Post reply on HN