If you need to be on the JVM, that seems to be the case. I just wish there was something better than gradle for managing dependencies and building apps in kotlin.

I don't know if you were being dramatic, but Maven builds kotlin just fine and my experience is that it is a ton more stable over time than "./gradlew ohGawdWhatGradleInternalsAreGoingToDieNow"

I can’t say I love maven either. I haven’t really lived in the JVM for a few years but other ecosystems just have way better tools for building and dependency management.

I recently did a Kotlin project using Bazel and it wasn't perfect but it was definitely serviceable.

One thing was that while iterating on the build was painful compared to Gradle with Kotlin script it did have very nice performance in combination with remote build cache and I imagine the remote build execution feature could be very nice for large JVM projects.

I don’t get the hate for gradle. Sure, one can make some monstrosities with it, but the common case is pretty much just listing your deps, not different to, say cargo.

Yet, when you inevitably have to add something more complex, it will let you do it. Gradle is perhaps one of the most misunderstood technologies, many people believe it is some imperative ant-script, when in fact you have the script write a declarative plan for you, which will be later executed “purely” (much more so than maven for example)

It’s not so much hate, I just don’t think the dependency management story for any of the JVM tools is very good.

With the faster pace for Java now, I wonder if I'm the only one feeling lesser need / lesser incremental benefit of moving to Kotlin.

Yes, some of my fellow engineers like it for the language itself, but I feel these days it's getting harder to argue that "the team using Kotlin is so much more productive than the team using Java".

Curious what HN thinks about this.

What's the story with nullability in Java these days? I used to be a Java dev, and NullPointerExceptions were a thorn in my side.

Kotlin has (real, language-level) non-nullable references, which strikes me as a big improvement.

Even basic intellij suggestions can save you from most instances of NPEs, but you have the option for complete third-party static analysis (with either default to nullable, or default to non-nullable, and then adding @NonNullable or @Nullable annotation, respectively ). These are not standard annotations, but all third party analyzers do in fact understand each other, and they have the stdlib annotated. Oh and debugging story became much better, you get exact property-access instead of only a line number, but that is a JVM-change not java.

If you do some long, chained property accesses (which imo are the primary sources of NPEs) I can only recommend mapstruct. You basically declaratively write what has to be mapped to what and it will generate at compile-time the necessary, performant Java code with proper null-handling, even n level deep.

So my empirical evidence is that NPEs ”million dollar” fallen victim of inflation :D

Thank you -- glad to hear there's been progress!

I think that’s reasonable if you are on a recent JVM version and expect to upgrade very regularly. Many are in organizations where that’s not the case.

The biggest annoyances in Java cannot be fixed for backwards compatibility reasons. It will always allow you to do the wrong thing.

What wrong thing?

Java

Kotlin has always been positioned as a better Java.

But with Java on a faster release schedule the point of Kotlin gets weaker every day.

Scala on the other hand is more and more a true FP language.

Scala is not a true FP language. A true FP language won't let you do imperative stuff.

s/true/pure/g

I guess Haskell is not an FP language then.