
Kotlin Post-1.0 Roadmap - belovrv
http://blog.jetbrains.com/kotlin/2016/04/kotlin-post-1-0-roadmap/
======
acjohnson55
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 its own.

~~~
mike_hearn
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 not)
define them.

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

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

~~~
airless_bar

      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.
    

Years ago Scala tried the same thing Kotlin currently tries to sell as the hot
new stuff. That approach was abandoned altogether, because. it. just. doesn't.
work.

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!

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

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

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

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

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

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

------
sargas
I'm very excited for 1.0.x, type aliases and a library for concurrent
programming are great news. Not to mention support for Java 7-9 bytecode
generation.

------
ungzd
Still no more than "coffescript for java".

~~~
xaduha
Nope. Please educate yourself on the subject a bit more.

