This is true, but needs more context. Java 8 added Stream API, which (at this time) was a fantastic breath of fresh air. However, the whole thing felt overengineered at many points, aka - it made complex things possible (collector chaining is admittedly cool, parallel streams are useful for quick-and-dirty data processing), but simple everyday things cumbersome. I cannot emphasize how tiring it was to have to write this useless bolierplate
customers.stream().map(c -> c.getName()).collect(Collectors.joining(", "))
customers.map(c -> c.getName()).join(", ")
customers.map(_.name).mkString(", ")
customers.stream().map(c -> c.getName()).collect(Collectors.joining(", "))Of course you can write a generic version of `mkString` (as this method is called in Scala), so it's also just one method no matter the container count.
The Python weirdness is actually a direct result from the language lacking generics…
Personally, I'm extremely glad to not have had to write .toStream().map(...).collect(Collectors.list()) or whatever in years for what could be a map. Similar with async code and exception handling.
For me one of the main advantages of Kotlin is that is decreases verbosity so much that the interesting business logic is actually much easier to follow. Even if you disregard all the things it has Java doesn't the syntax is just so much better.
stream.map(...).toList()
The choice was Kotlin. Scala is too "powerful" and can be written in a style that is difficult for others, and Java too verbose.
Kotlin is instantly familiar to modern TypeScript/Swift/Rust etc devs.
The only negative in my mind has been IntelliJ being the only decent IDE, but even this has changed recently with Jetbrains releasing `kotlin-lsp` for VS Code
Because in 5-10 years you'll have a Java project that people can still maintain as if it's any other Java project. If you pick Kotlin, that might at that point no longer be a popular language in whatever niche you are in. What used to be the cool Kotlin project is now seen as a burden. See: Groovy, Clojure, Scala. Of course, I recognize that not all projects work on these kinds of timelines, but many do, including most things that I work on.
Kotlin is Google's C#, with Android being Google's .NET, after Google being sued by coming up with Google's J++, Android Java dialect.
Since Google wasn't able to come up with a replacement themselves, Fuchsia/Dart lost the internal politics, they adopted the language of the JetBrains, thanks to internal JetBrains advocates.
The Oracle v Google was specifically over copyright infringement concerning the Java APIs used in Android's original implementation (Dalvik/ART), not about creating a "J++" dialect.
Android never ran a JVM on mobile because it cannot be optimized for resource constrained devices a solution like DalvikVM was necessary. If you want to level critiques about creating fragmented dialects of Java I would recommend starting with J2ME. The only nice thing I can say about J2ME is at least it died.
The Android ecosystem was far too mature for Fuchsia/Dart to be successful without a very compelling interop story that was never produced.
As a technology Kotlin met Android's platform and community needs. Advocacy and politicking played a minimal, if any, role.
Nokia and Sony Ericsson were using J2ME perfectly fine, as did Blackberry. I should know ad ex-Nokian.
Kotlin met nothing, it was pushed by Kotlin heads working on Android Studio, telling lies comparing Kotlin to Java 7, instead of Java was already offering at the time.
To this day they never do Kotlin vs Java samples, where modern Java is used, rather the version that bests fits their purpose to sell why Kotlin.
Fragmentation, what a joke, the fragmentation got so bad in Android, that JetPack libraries, previously Android X, exist to work around the fragmentation and lack of OEM updates.
Gosling said it better, regarding Google's "good" intentions
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
I've written multiple production services in Kotlin Spring Boot. Now, we're building a new system and using Java 21 (25 soon).
Why? Kotlin the language is great, but there are corresponding tradeoffs in interop. Meanwhile, Java the language has improved to the point that it's good enough, and Java feels like it's headed in the right direction. In my opinion, AI models are better at Java than Kotlin. If you prefer a weaker claim, the models are trained on more Java code than Kotlin code.
Finally, from an enterprise perspective, it is a safer long-term investment for a Java shop to own an application written in Java rather than in Kotlin.
Put another way: Java only has access to a subset of the ecosystem
Almost all of the backend libraries I use are Java libs. Some of them have additional Kotlin extension libs that add syntax sugar for more idiomatic code.
For what it's worth, Spring has first tier Kotlin support, I haven't noticed this bias.
And yes, "you get what you pay for" is part of this.
https://business4s.org/scala-adoption-tracker/
The stuff currently cooking in Scala 3 will once more revolutionize the whole programming language landscape.
https://softwaremill.com/understanding-capture-checking-in-s...
Outside Android, I don't even care it exists.
If I remember correctly, latest InfoQ survey had it about 10% market share of JVM projects.
At the time Scala was on upswing because it had Spark as its killer app. It would have been a good time for the Scala maintainers to switch modes - from using Scala as a testbed for interesting programming-language theories and extensions to providing a usable platform as a general commercially usable programming language.
It missed the boat I feel. The window has passed (Spark moved to Python and Kotlin took over as the "modern" JVM language) and Scala is back to being an academic curiosity. But maybe the language curators never saw expanding mainstream usage as a goal.