Kotlin 1.2.20 released
blog.jetbrains.com
blog.jetbrains.com
If JetBrains didn't make most of their money with their IDE, they would probably put more effort in providing general tools that can be used with any IDE/editor. In this sense, I think JetBrains is hampering the success of kotlin. They should try to give kotlin a better organisational foundation.
Even typescript (a MS product) can be written with all sorts of IDEs/editors.
I've found the same of IntelliJ products. They're so good that I don't mind being forced to use them.
I left the Java world because I couldn't stand having to have all of the hand holding just to achieve simple goals. I'm not saying Java or Kotlin are _bad_ languages at all. Perhaps I'm just bugged by the general attitude that "everyone will have IntelliJ".
In a language built for the same platform where Scala has already been available for a decade it's very disappointing though.
Kotlin's biggest strength is that it brings near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle.
Boutique languages on the JVM are old hat by now, and they're neato and everything, but most people do not have the luxury of getting to choose to base their company on one of them. Kotlin is so compatible with Java that you can mix Java and Kotlin code freely in the same project, allowing people to move to adopt Kotlin gradually, without throwing away their extant business logic or requiring the wholesale sign-off of everyone in the org all at once.
Kotlin may not be the most theoretically pure language, but it lets you hit the ground running while shedding many of the crusty, obnoxious parts of the Java language. We've badly needed a semi-modern JVM language for the working man, something that doesn't get in the way and makes the business of doing software simpler. That's why Kotlin has had such an ecstatic reception.
SBT is indeed a wreck, just ignore it (at least to start with) and keep using whatever you were using (Maven or Gradle or what-have-you). In maven and eclipse/scala-ide with the m2eclipse-scala plugin installed I always found it "just worked": add the scala plugin to the pom, let eclipse notice that it's Scala, create a Scala class in the project and keep going. The IntelliJ experience is only very slightly more involved (have to manually tell IntelliJ to update the project config with Scala nature).
> while it's ostensibly interoperable with Java, there are many caveats.
> Kotlin's biggest strength is that it brings a reasonable amount of modernity with near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle.
This is the Kotlin narrative but I don't think it's actually supported by the facts. In the early days Scala looked perfectly interoperable with Java, but as we started writing more substantial things in Scala and a native-to-Scala library ecosystem developed it became clear that there was more to interop than being able to call methods directly, as nice as the latter is. As Scala became a full-fledged language with its own idioms we started needing idiomatic wrappers or native-to-Scala libraries. This is happening in Kotlin too, e.g. look at how http://arturdryomov.online/posts/kotlin-the-problem-with-nul... talks about having to consider whether calls are into Java libraries or not and treat them differently if they are.
And if anything I'd say this is getting worse for Kotlin with "modern" Java code: Java 8 is seeing more use of Optionals (particularly in streams) which correspond directly to Scala but are more difficult to interoperate with in Kotlin with its null-oriented design.
But in the vanishingly rare case where you have a performance-critical codepath that needs to zigzag back and forth between Java and Scala... it's still not a problem, because it's easy to work with the Java collections in Scala. The absolute worst case is "just using their Java API" (the same thing you dismiss about using Optionals in Kotlin). But since Scala has typeclasses we can actually do much better than that.
Given that after literally years of Scala experience I could easily write code I couldn't read three months later, this is not a big negative.
Kotlin takes a lot of the good from Scala, leaves most of the bad, and gets the hell out of my way (while giving me literally-perfect Java interop--the only problem I ever had was how to annotate only the getter part of a property, and it was unintuitive but I figured it out). I'm a big fan.
The complexity I end up carrying in my head is way, way too high.
Hmm, that's backwards from my experience. Like, I actually regret it when I use the Future-specific operations on Futures, because I don't use those often enough to remember what they are, whereas I use the generic Monad operations all the time on pretty much everything.
> trying to get something out the door that doesn't turn into a mess of code I have to sit down and chew through, slo-oo-owly, is a heck of a fight
I find often something that would be 10 lines of Java or Kotlin can be 1 line of Scala - but still 8 lines' worth of reading time. It can be difficult to remember that this is an improvement when you're thinking "why is it taking me all morning to read 10 lines?", but when you take a step back you realise that those 10 lines are actually doing the work of many more.
However, if you look just at Kotlin's syntax, the default is meant to be immutable while the mutable version is longer: listOf versus mutableListOf.
That looks very much like design and not like an afterthought.
It is a new language on JVM. It also suppose to work with Java libraries. So it won't radically different from Java.
There's exactly one unusual/novel feature in the language (AIUI), and it's a feature that I personally find inspired: anonymous receiver functions, as it makes EDSLs trivial to write.
(I think it's a very good idea, but it's as innovative as anything you'll see in e.g. Scala, so it makes a mockery of the "blue collar" narrative)
Non-representable types are also decidedly "novel" (in the sense of "wtf?"), as are some of the details of their preferred way of doing await/async (assuming they haven't radically changed again in a minor version as they did in the past).
The only sense in which Kotlin is blue-collar is that it prioritizes immediate use cases over consistency and theoretical coherence. That's not "Java as if it had been designed today", that's "Perl as if it had been designed today".
However, I think it is better to write all new code in Kotlin.