mrudolph22

Kotlin is #23 in this irrelevant index.

I first learned Java in 1997 and have been using it professionally since 2005. If your Kotlin code is pretty indistinguishable from your Java code, you aren't using Kotlin properly. Here is what I wrote on this topic in 2022:

Here are some of my favorite Kotlin improvements over Java that I leverage all the time:

* Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments)

* Local variables are final by default ("val")

* Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java)

* Much improved collection API

* Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions)

* Extension functions (incredibly useful in practice)

* Much better DSL capabilities (great for UIs, generating HTML, etc.)

* Lazy properties (more generally: delegated properties)

* Coroutines (looking forward to Java's Loom; by then coroutines will have dramatically improved my async code for 5+ years)

* Great serialization support (kotlinx.serialization)

* Pragmatic macro-like capabilities via inline functions and compiler plugins (removes lots of boilerplate)

* Multiplatform support (JVM/JS/WASM/native; Graal native image is a good alternative to Kotlin/native and also works for Java)

Many of Kotlin's profound improvements will never find their way into Java because it's 25 years too late to do so. Java improves where it still can, which is the right thing to do. Sometimes Java even manages to improve on Kotlin because now it can learn from Kotlin and other languages. Nevertheless, it's impossible for Java to catch up to Kotlin, which was designed 15 years later with the explicit goal of fixing as many of Java's design mistakes as feasible for a JVM language.

If you think Kotlin is marginally better than Java, you probably have a superficial understanding of Kotlin. Kotlin is vastly better than Java, which isn't surprising because Kotlin was designed 15 years later with the explicit goal of being a better Java and fixing as many of Java's design mistakes as possible. For example, the designers of Kotlin went through the book "Effective Java" and tried to avoid the listed pitfalls by design.

Java will never get close to Kotlin because even though Java can, and thankfully does, still improve, it's too late to revise many of it design decisions, and large language features often need to be considered in a language's design from the start.

On Android, Kotlin is an even bigger win because Android uses an old Java version and has become Kotlin-first.

In my opinion, Java will remain the best choice for libraries that target multiple JVM languages. For everything else, I use Kotlin without thinking twice. Kotlin 2.0 laid the groundwork for toolchain improvements, which have indeed been a long-standing pain point.

Thanks for the offer! I’ll give Mill another shot the next time Gradle drives me crazy. :-)

They transitioned to a product company 5+ years ago. https://gradle.com

Gradle's complexity comes from at least two places:

1. The original vision of solving complex multi-technology/language Enterprise builds.

2. Poor early design decisions that they never recovered from.

I'm afraid that no current config language is an obvious fit for Mill. That's because Mill is fully reactive and doesn't distinguish between build configuration and execution by design.

Modern config languages offer strong validation and advanced IDE support, which is essential for a great user experience.

https://pkl-lang.org/intellij/current/highlights.html

I gave Mill a try earlier this year. My hope was to escape the nightmare that is Gradle, which I've been using for many years. Mill sounds great in theory (except for the Scala DSL). Unfortunately, I couldn't get a basic Java build to work in half a day, even though I have (admittedly rusty) working knowledge of Scala. It was one obscure error after another. My conclusion was that Java support isn't ready. There was also very little documentation on how to build Java.

In my opinion, using a GPL as the build language of a polyglot build tool is a dead end, both for technical/usability reasons and because the ensuing language wars can't be won. I'm looking forward to the day when a build tool embraces a modern config language such as CUE or Pkl.

Just wanted to mention that there are much better config languages than Starlark by now: CUE, Pkl, etc.

Java 21+ (virtual threads).

In theory, yes. But I doubt that we’ll see a TS IDE plugin that underlines violated constraints with red squiggles anytime soon. :-)

TS tooling won’t tell you when your config value violates the constraint “isBetween(0, 100)” or “matches(Regex(…))”. Among other things.

> I do wish they just contributed to nickel or something else though rather than doing their NIH as usual.

Did Nickel exist in 2018? (Someone here said that Pkl did.)

Refactorings are one example where LSP can’t match IntelliJ. A language server also takes far more skill and effort to implement than the equivalent IntelliJ plugin, where much of the heavy lifting is done by the IntelliJ framework. And you still need at least a lightweight plugin for each supported editor. That’s why a language server isn’t necessarily the best place to start but hard to avoid in the long run.

Java modules are fine but don’t offer a solution for version conflicts.

Java doesn’t have a universal practical solution for this. Principled solutions based on custom class loaders (such as OSGi) added tremendous complexity and created more problems than they solved. Other solutions such as shading (renaming classes and their usages to prevent name conflicts between different versions) work in some cases but have their own limitations and drawbacks.

Katlin isn’t developed by Google but by JetBrains. It is a multi-platform language and isn’t tied to the JVM.

The headline is misleading. Whereas current vaccines don’t protect from infection with Delta and later variants, they still protect from serious illness and death. From the article:

> Experts and regulators broadly acknowledge the benefits of a third vaccine dose to top up flagging protection against serious illness and death.