Comment by exabrial | Hacker News Reader

Comment by exabrial | Hacker News Reader

Parent Full thread

Better is subjective. Java is a great language, has a mature and stable codebase, it runs at near-Cpp speed, has built-in SNMP-like monitoring, and the developers are super careful about not breaking backwards compatibility. That's all about there is to say about it. Kotlin is also a good language for many of the same reasons, mainly because it is run on the JVM. One really isn't better, they're just different. Use the tool you know how to use, and master it.

The only category I would say is objectively "better" is Java (and other JVM languages like Kotlin) has the best IDEs out of _any_ language. There is nothing on-par for Python, Ruby, C/Cpp, etc as far as autocompletion, type inference, automated refactoring, partial recompiles, hot code swapping, unit test integration, Tomcat or server integration, code formatting, etc. Java is great because of it's IDEs. If we were writing Java in notepad.exe it'd be a pretty clunky experience, but nobody serious does that.

> The only category I would say is objectively "better" is Java has the best IDEs out of _any_ language.

Kotlin was made by the people behind IntelliJ. I'm not sure I understand your point.

sorry, I should have included Kotlin in that part of my comment. IntelliJ Kotlin is quite incredible. Every time I've needed to use it, my expectations have been met.

Makes switching to vscode feeling going from an framing nailer to beating in rusty iron nails with a rock.

extension functions can be scattered across any number of files and the import statements do not tell you where they are declared. kotlin was specifically designed to drive sales of IntelliJ

And it’s slow as molasses without feature parity.

One feature that comes to mind is rearrange methods. I haven’t used Java in years so someone who actually uses both can find more cases where Kotlin support is worse than Java’s.

That's a single IDE from a single vendor though.

We were looking at starting a new Spring Boot project several years ago and considered Kotlin over Java - but the single decent IDE made me reluctant and we went with the familiar Java instead.

AFAIK, most people using Kotlin are somehow tied to some variant of Java 8, such as Android. Kotlin is very useful for that use case, but otherwise was a useful kick for Java but I don't know if I'd start a new project in it.

Java still has no counterparts to many important Kotlin features - number one being null safety. Java is not even trying to address it (no, JSR305, checker framework, Optional are not solutions).

> Java is not even trying to address it

Valhalla might. There's been a lot of time put into nulls and primitives for valhalla. How that manifests seems to be up in the air still. But I would not be surprised to find non-nullable types in the future (like `int`).

Well yeah, but if that's null safety only for value objects, then it's still a very incomplete solution.

The latest iteration is thinking about proper nullable/non-nullable types like String?. They want to have the user care about the semantics only (whether it makes sense to have a null value here) for any kind of object, but this same notation will also give a big performance boost to value types, as those can then be stored in memory more efficiently.

There's always going to be a hole because of a legacy of not having null in the type system. Java can't simply break that.

I don't think this is something that will only apply to null safety objects. Maybe initially, but I don't see there being major restrictions to extending this to other classes.

> Java can't simply break that.

And that, in turn, answers the question of where Kotlin is different enough from Java that it might be worth switching.

Java is very strict on backwards compatibility. That has its advantages. But it also has a lot of downsides. Kotlin doesn't want/need to be backwards compatible, and it can afford to break semantics enough to make null not allowable(*) in non-nullable types.

It's a trade-off, of course. But it explains why some people prefer Kotlin.

(*) Save for Java interop.

I'm using Java 11 and Java 17 with Kotlin without issues.

When targeting Java 8, Kotlin creates helper classes for the default methods on interfaces as that is not supported in Java 8, whereas on Java 9+ it uses Java default functions. However, you can target multiple Java versions, as I've done that with my projects for 11/17 support.

The developers absolutely wrecked backwards compatibility by shuffling classes between namespaces just a few years ago. I guess the new names are somehow better, but so many things broke because things needed renaming For Reasons

Yeah the backwards compatibility point is overplayed i think. It is mostly true but The java world paused at 8 for a hair too long and when it came time to move to 11, workarounds were needed for things like JavaEE and JavaFX being removed.

While I miss IntelliJ IDEA, I’ve found Visual Studio has mostly caught up for C# refactoring. If that’s not enough for your use-case, there’s always the Rider plug-in.

Reply on news.ycombinator.com