You call it hype, I call it enthusiasm.
But regardless of the names we use , what I find very interesting is that Kotlin is generating such positive feelings even though it's not even 1.0. I haven't seen this happen for languages in a while (probably "ever"). What's also striking is that most of what I read about Kotlin is positive, and again, languages hardly ever generate positive feelings so widely across the board.
The positive feelings ring very false to me. Kotlin has announced a lot of features long before they were delivered, and taken a lot longer to deliver a working language than they originally claimed. It's the old "two types of languages" - most languages sound good when you talk about their features, it's only when you actually use them that the negatives become apparent.
I don't know anyone who's actually used both Kotlin and Ceylon and prefers Kotlin, and Ceylon is actually more mature (1.2 released recently, IIRC). But since King only advertises features that are actually implemented and release dates he can actually make, there's a lot more hype for Kotlin.
`List<Int> myNewList = myList.stream().map(i -> i +5).collect(Collectors.toList());`
In Kotlin:
`val myNewList = myList.map(it+5)`
Can you see how that can be clearer and simpler to read? Technically it is doing the same thing, but it is much simpler to reason with. On top of that, you've got improved null safety, monkey patching and type inference.
That comparison looks misleading - the .stream() and .collect() are conversions, not necessary on every call by any means.
Kotlin's approach to null safety is ad-hoc and integrated into the language in a way that makes it hard to abstract over. I think it will lead to inconsistent code as the JVM ecosystem moves on to make more use of Option-like alternatives.
Monkey patching is pure evil in any large codebase.
I think Java will likely add more and more type inference in future releases.
Don't get me wrong, syntax and sugar are important. But a language that only offers those is probably not worth the overhead, and such things are relatively easy for the "parent" language to adopt.
Besides, it's not any more magical than "_" (which has, what... eleven different meanings? [1]) and it's super convenient. Still, don't like it? Just explicitly name your closure parameter. But you'll be surprised how you will quickly stop doing that for trivial closure uses because finding names is such a pain.
You're right that Java 8 has been closing the gap, though, but note that Java 9 doesn't have any new language features that will close that gap further.
FWIW I avoid "this" as much as possible. I prefer a named self, which Scala has a nice concise syntax for.
> Besides, it's not any more magical than "_"
Like I said, "_" looks like syntax. "it" looks like an ordinary value.
> which has, what... eleven different meanings? [1]
Sort of, but it's always obvious from context. I have literally never been confused by an occurrence of "_" in 3+ years of full-time Scala programming.
You're assuming here that a lot of people have used Groovy. People generally don't even use "it" in Gradle, the most common access people have to Groovy.
You can't see a future for a language that offers far more succinct code than Java, but maintains the ease of Java?