Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

As someone who spent the first 15 years of their career in Java, but has been out of the ecosystem for some time now, it's cool to see Java get such big improvements, especially virtual threads.

However, given the number of excellent JVM languages, especially Kotlin, I'm curious what the general consensus is for starting new projects. That is, if I were starting a greenfield project, I think I would definitely use Kotlin over Java - Kotlin doesn't have to deal with the backwards compatibility concerns of Java, and thus does away with some of the problematic annoying complexity of Java. E.g. first class language support for nullable/optional types I think is critical these days - Java has bolted on an Optional wrapper, but it's cumbersome and doesn't provide the kind of strong guarantees that a language-implemented version does.

So what does the HN community think? Would you use another JVM language over Java if you were starting a new project?

View on HN

Kotlin is getting some of its own baggage, at least by virtue of having to deal with multiple compilation destinations (JVM, native, Android, JS). This is why you end up with things like @JvmStatic or @JvmInline.

Java is coming along quite nicely. Its pattern matching looks to be better implemented than Kotlin's (e.g. destructuring implementation). Same with string interpolation (https://openjdk.org/jeps/8273943). And now with Loom, no need to maintain two separate API surfaces for sync vs async. It has the last mover advantage.

I like Kotlin. However, these decisions aren't always simple - and are based on more than the technical merits of the language.

Some years ago, my division at <large company> decreed Scala was the way of the future. All new development was to be done in Scala. We were offered training classes. We formed book clubs. We paired, shared, and opined as we tried really hard to do functional programming correctly. We genuinely tried, and then we gave up. The specific reasons would better suit another post, but it was a grassroots developer-led effort that led us to abandoning Scala.

At this point, we have backend code in NodeJS, Scala, GoLang (this is currently a performance-sensitive one-off), and Java. That's a problem for code reuse, tooling reuse, and general maintenance. If we were to write new components in Kotlin, we would be making the problem worse. At this point in time Java is our safe fallback.

In the future we may try a different language again, but for now there needs to be a really good reason to add to our tech stack. I suspect most new projects will continue to be Java for quite some time, because we're not going to rewrite all the Scala and NodeJS code "just because". It will slowly get replaced as it stops working, or as we find reasons to replace it other than "it's in a language we don't like". Until then, our polyglot set of codebases is too intimidating and devs are going to resist adding another language to it.

Did golang live up to the performance requirements you wanted from it? Unless it is some very small microservice which can get away with only value types, I fail to see go beating java.

> If we were to write new components in Kotlin, we would be making the problem worse. At this point in time Java is our safe fallback.

I don't agree with this. Kotlin is essentially a drop-in replacement for Java, so much so that you can replace your Java classes _one by one_ with Kotlin classes. The build tools, frameworks etc are mostly the same, so no real changes required in the environment. (All this is not true for Scala, for example.)

From one perspective, one might argue that Kotlin didn't do enough (eg. it has ADTs but no pattern matching), on the other hand, this is exactly why it is so easy to step up. You can also very quickly get productive in it coming from Java, there is no need to use advanced stuff like async/await, and there are very few caveats you need to worry about.

Just my 2c, based on experience.

I would use Scala. I like FP and Scala comes with some awesome libraries for concurrent/async programming like Cats Effect or ZIO. Good choice for creating modern style micro-services to be run in the cloud (or even macro-services, Scala has a powerful module system, so it's made to handle large codebases).

https://typelevel.org/cats-effect/

https://zio.dev/

The language, the community and customs are great. You don't have to worry about nulls, things are immutable by default, domain modelling with ADTs and patter matching is pure joy.

The tooling available is from good to great and Scala is big enough that there are good libraries for typical if not vast majority of stuff and Java libs as a reliable fallback.

If you have a small team of engineers and you need the added productivity of a more ergonomic language, then go ahead with Kotlin. In particular it's good for "lite-functional" style with OO mixed in, and your engineers get to keep all the familiarity they have with the JVM ecosystem.

It's not some panacea though, and at the end of the day Java is the system language of the JVM. New VM features are not built to cater to the guest languages. In the case of virtual threads we have a directly competing "async" solution to Kotlin coroutines. So you may see further ecosystem split between libraries catering to Android and those catering to backend work.

Virtual threads are NICE, but not truly critical for most Java devs. What I am really happy with are the pattern matching implementation. Coupled with exhaustive switch-case, its a whole new world for Java devs. And its great that the design they came up with fits so nicely into the existing java language that they didnt have to introduce much new language syntax.

> Would you use another JVM language over Java if you were starting a new project?

no. I'm never a fan of anything like typescript or Kotlin where it's transpiled (yes i know Kotlin is compiled down to JVM byte code) end up dealing with more headaches and troubleshooting in the end.

FWIW, after doing "plain" JavaScript for a couple years before moving to TypeScript, I would never do another project without TS, and these days I think not using it is a colossal mistake.

First, yes, I agree that setting it up initially and understanding all the various tsconfig options can be a pain. But it's also largely a one-time cost, and honestly over the past couple years I really didn't have any "weird troubleshooting" problems once I got it working. Also, these days more is being done to make TypeScript easier to run out of the box, e.g. Deno.

But the benefits of using TypeScript are vast, even from an individual programmer perspective, nevermind the huge benefits of using it to allow for refactoring and better comprehension in a larger team. The autocomplete benefits alone that I get with it in VSCode are worth it.

TypeScript vs JavaScript is a completely different story of Kotlin vs Java though. All of the typing benefits are already present in Java with the benefit that Java is the system language of the JVM.

Been working on a greenfield project for 3 years now. The initial config isn't even the problem. It seems like every time I run into a bug or update packages, typescript is the cause behind it. Just couple weeks ago I had to update mongoose to the latest version to satisfy some STIG requirements and typescript basically broke all the compatibility and I had to go back and rewrite a bunch of sort functions. I'm in more of a infrastructure role now, but I'm constantly having to deal with other devs typescript bugs. We are sticking with typescript cause of how much easier it is for them to write, but personally I would never ever use trans piled languages if it was up to me or for my personal projects.

Actively coding in Java in a large system at the moment (so we can't Kotlin), but if I were to start a greenfields I'd give serious consideration to doing it in Kotlin.

Reply on news.ycombinator.com