Unless you're using arrays. They went with "predictable" over "sensible" here.
> is flawless from my experience
As a heavy Kotlin user, I'd say it's far from flawless (not sure if you mean interop or the entirety of the language, but applies to both). I'm often creating and starring YouTrack issues. But yes, it's still a highly recommended alternative to Java.
0 - https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db11...
It may be easy when your engineering org is 5 persons. It's much harder, genuinely harder, when it's 250 engineers, and an hour of downtime costs hundreds of thousands. Adoption of another language, even clearly superior and interoperable, becomes a large and costly undertaking.
So "just use Kotlin" is not always possible, and I'm thankful to Lombok's authors for their work.
The hard truth is that Scala was not designed with tool support in mind and it probably never will be. For example hierarchical implicit conversions, while powerful, are terrible for tooling.
You should pay attention to what's going on in the ecosystem. Dotty comes with LSP support. The Scala Center's main focus is tooling. JetBrains has been pretty committed and cooperating as of late. And several projects are building serious alternatives to SBT.
Because it does a pretty good job with implicits now: https://blog.jetbrains.com/scala/2018/07/25/intellij-scala-p...
Most libraries — SBT is one example — have shifted away from the use of excessive overloading.
Additionally the JVM wasn't enough for JetBrains and code written for multi-platform has slightly different semantics (see Kotlin/Native and immutable data).
Kotlin is a good alternative on Android due to a frozen Java 8.
Against Java 12 not so much.
It is very hard to displace platform languages when others just feel like guests.
* Excellent null safety enforced by the type system
* Data classes reduce boilerplate and bug sources
* Extension methods
* Declaration site variance removes a lot of the ? extends T
* Everything being an expression (if, switch/when) is powerful
* Smart casts are useful, especially when combined with subtypes and when (switch)
* Removal of checked exceptions
* Inline functions, a good way to work around runtime type erasure
* Properties, no more getX or setX
https://trends.google.com/trends/explore?geo=US&q=java,kotli...
Specially since JetBrains decided that they not only want to go against Java, they are also positioning Kotlin agoainst JavaScript, TypeScript, WebAssembly languages, C, C++, Rust, .... Ergo choosing multiple fronts to focus on.
Which already has the consequence that Kotlin/Native code does not fully follow the same semantics.
Also regardless of what people in HN think, Eclipse still rules the enterprise and the Kotlin plugin is a bit meh playing catchup with latest features. Most IT departments won't sign off InteliJ licenses just because some devs think Kotlin is cool.
It is not language feature bullet points that make an eco-system, specially for those that don't own platforms.
With ChromeOS and Fuchsia on the game as well, it remains to be seen who will win Google's internal OS wars.
So far Android seems to be the one taking them all, though.
Outside Android I don't really see a major benefit switching whole teams away from Java, Eclipse/Netbeans and rewriting/wrapping libraries to be idiomatic Kotlin and such.
- supports both dynamic and static typing - it works just as well for bash level scripting as it does for full application development. For example, you can use it exactly like an interpreted language (no compilation needed).
- seamless Java integration. I know many JVM languages say that, but Groovy actually makes it one of its core features. It has a lower impedance mismatch than any other JVM language I've tried (and I try them all).
- partly because of the dynamic typing, it is able to support the most concise, powerful options in its syntax of any of the JVM languages. So you get more done with fewer, simpler lines of code
- because of the static typing and low impedance mismatch with Java, it can achieve very high performance. I was not able to get Scala to perform as well, for example, because of type conversions needed to invoke underlying Java library calls (unless you abandon idiomatic Scala).
- The amazing SQL library - HTML builders (there are XML builders too) - Literal collections (lists and maps)
This causes the program to run in dynamically-typed mode, much sloooower, so why do it? You'd have to add @Static annotations everywhere to get anything approaching Java-like speeds. One of the Apache Groovy project managers has long since wanted to make Groovy statically compiled by default, but that's never going to happen because they're running an unofficial go-as-slow-as-possible in the official upcoming upgrade to Groovy 3.
Kotlin has data classes which auto generate sensible 'toString' and 'hashCode' methods which is a massive time saver.
Really, if you are considering introducing Kotlin to a Java project I'd recommend you just take the plunge. It's pretty much just a minor change to your pom file (if you're using Maven). Kotlin has Java interop as a primary feature and is flawless from my experience.