Kotlin Post-1.0 Roadmap
blog.jetbrains.com
blog.jetbrains.com
Of course, there's still plenty of room for both languages, and I'm sure Kotlin will introduce interesting innovations of its own.
I feel that part of Scala's problem in every project I've been involved with is that it has too many features which means if you're not incredibly careful about specifying exactly what features should be used you end up with an unmaintainable mess.
Whenever I've asked people to go into the specific "too many features" in Scala it always turns out they were talking about library features, not language features. The language is powerful enough that people can write very complex libraries in it. If Kotlin ever becomes popular it will have exactly the same problem.
The funny thing is that even as people say that, every new release tends to look a step closer to Scala.
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 not) define them.
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.
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.
You can write Scala using the standard Java collections (or Guava immutable collections) if you like (especially if you're using a ScalaZ-heavy style where everything happens via typeclasses - just write typeclass instances for the collections you're using, and then it's easy to mix and match). For my money immutability is too important for it to be worth using the Java collections - even in Java I'll use the Guava ImmutableList etc.
> Scala has some constructs that can make it impossible or very difficult to call code from Java. Kotlin doesn't.
Such as? I mean, implicit parameters won't be implicit (but they couldn't be in Kotlin either), and higher-kinded types compile to raw methods for which you have to cast (but you'd have to do the same to express the same thing in Kotlin).
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.
It's a death by thousand cuts. You can keep sprinkling compiler magic on top of it, but it will be an ongoing game of whack-a-mole. See all the typesystem unsoundness and how they had to abandon (non-)null annotations for existing code because it just didn't scale/work.
The whole concept of having mutable and immutable collections within the same API hierarchy that Kotlin tries to sell is also considered to be one of the remaining design issues of Scala collections.
Those were terrible times. So happy that Scala doesn't do that anymore!
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
The original roadmap: http://www.scala-lang.org/news/2.12-roadmap/ The current roadmap: http://www.scala-lang.org/news/2016-schedule/
For reference, M4 was released 3 days ago. JDK8 was released a little over 3 years ago, and JDK9 is about a year away which will introduce some interesting challenges.
We've yet to see how fast JetBrains will iterate on Kotlin and support for JDK8, while we know exactly how fast Scala iterates.
Using Java 8 has worked with 2.11 for quite some time already.
Honest question - what is it that makes Scala's optionality inefficient compared to Kotlin? I'd never heard of this before.
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.
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<Optional<T>> you can just use the Optional class from the Java 8 standard library to do so.
You say "you can just use the Optional class from the Java 8 standard library", but as far as I can see porting code that was written to use nullables would be a pretty big refactor, and there's no way at all to write generic code that works with both, so you'd end up having to maintain two parallel copies of your common functions.
Efforts to improve the performance of Option are of course to be applauded, but for a lot of use cases we're talking about the difference between (say) 50x faster than Ruby and 40x faster than Ruby. Scala is more than fast enough for a huge range of use cases; I don't think I've ever seen someone port code off Scala because the runtime performance wasn't good enough.
I haven't programmed Kotlin before, so I'm not sure what their answer to implicits is. For ad hoc polymorphism, none of the alternatives is particularly pretty. Perhaps the current answer is to resort to adapter classes, which would be the way to do it in Java.
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.
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
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 X with performance Y?" then the biggest component of the answer is going to be how easy programming in general in that language is, not anything specific to performance.
The question "how fast will a naive implementation in language X perform?" does have an answer, but it's not a question you should ever be asking - if a naive implementation in language X is faster than a naive implementation in language Y, but takes 3x as long to write as an optimised implementation in language Y that's faster than the naive implementation in language X, then language Y is the better choice.
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.