I have 2 questions though. They have reified generics. Something even Scala lacks. Does the ability to retain this information at runtime on a platform without inherent support for this cause noticeable slow down or is it practically negligible especially when compared to typical bottlenecks?
And although they mention it compiles to java byte code I would be curious to know if it lugs a runtime. This will be key for easy android support.
I like that it has function inlining, this is something from F# that when used carefully leads to generous payoffs that is missing in Scala. Their module system is another thing which sets them apart, although I don't know if their approach will yield much. In my limited experience nothing in wider use has yet approached Ocaml's module system for power and usefulness.
This language looks quite good, I will be very interested to see how it goes. It not only improves Java it actually leaps frog over C# as well.
------------------------------------------------------------------------------------------
Why I think this language is a more likely candidate for Java.next
-It is an OOP language. It is not functional, not a hybrid. They make this clear and that fact will appeal to the people it targets.
-Reified Generics.
-no checked exceptions
-It uses farmiliar curly brace syntax. And does so consistently. While I prefer whitespace I suspect this is a minority view.
-Pattern Matching. Pattern matching, especially their implementation is not so hard and once you get used to that idiom you won't want to go back to mere switch.
-It is built by a Tooling Powerhouse.
-Higher (first) order functions just sound fancy. They are actually simple and useful. Especially to library writers and allow a more composable and durable(imo) type of extension.
-It has a well thought out type system. The fact that they are thinking about introducing reified higher kinds on the JVM and their approach to the variously prefixed variances is enough said.
-It is statically typed. This is a religious issue to many. But fact is that right now these type of languages are easier to tool, the idioms are more known to the type of people who use Java, and the performance is an issue for some. And for a minority the mathematics of a properly implemented statically typed system allows you to optimize code in an algebraic way.
-It is a definite improvement over Java but not in a way that uses scary vocabulary. In Kuhn's work both the paradigm shift and gradual changes are vital.
-It originates as a language that targets industry. When Scala first started it was an academic language built to prove the applicability of certain theories. There is nothing wrong with this and Scala is certainly production capable now but it retains its heritage. It is a very big language conceptually, pushing at the forefront of many ideas. Sure you can only use the small part of Scala but if you read behavioural pyschology stuff you know framing is a big deal. Saying that you are using a small part of the language even though thats all you need will cause a lot more uptake friction than saying you are using all of the language. Irrational but valid. The fact that Kotlin is being built to address a flaw in the market from the get go sets the culture out on the right foot.
Why use Scala instead of this
From a brief look this language seems smaller and easier to use than Scala -while also retaining most of the parts that make Scala better than Java. So the question IMO is why use Scala instead of this.
They mince no words in emphasizing that this is an OOP language. So if you prefer functional programming, Scala will be more idiomatic with certain syntatical affordances. In built ability to map and fold for example. Scala's type system is also more powerful and the syntax more flexible (with its own caveats) and most importantly the collections will be more functional and featureful. Like clojure, support for more future facing techniques and concurrent, parallel programming will probably be stronger in Scala.
What would be nice in my opinion
-Early support with nice tooling for Android. The documentation and tooling for Android leaves a lot of room for ehm.. improvement.
-Syntatical sugar for asynchronous programming.
-I cant't really think of anything else.