Hacker News Reader

Comment by davnicwil | Hacker News Reader

A question for HN - I like Java a lot for the ‘http API talking to SQL database’ usecase, with my goto for that being dropwizard or spring boot.

I’ve only ever looked at Kotlin code in blogposts, haven’t ever actually used it. I’m probably at least a few years behind on its feature set, but I am aware of all the great features Java has added in that timeframe, many no doubt inspired by Kotlin!

Would you advise me to use Kotlin over Java building a new API from scratch in 2021, given where both languages and ecosystems are today? Why or why not?

View on HN

You have to consider not only the language but what the team working on it will look like. It is still a bit hard to find server-side kotlin devs. On the other hand in my experience, Java devs pick up Kotlin really quickly (as do Python devs interestingly whereas they struggled with Java).

I'm a huge proponent of Kotlin on the server side, less on frontend (JS) side.

If you go with Kotlin and Spring Boot, Micronaut or even just Ktor,you'll likely not regret the choice. (I have no experience with DropWizard).

Now if you choose Java it will not be a horrible choice either, and it is not too hard to convert to Kotlin later if you need/want to. I've heard cases of people going back to Java a few years back, mostly for compiler performance reasons, but there has been a lot of effort on that recently. And while compiling Kotlin is still slower than compiling Java, the fact that you can divide things more easily in multiple files and incremental compilation compensates in most cases (except of course in the case f a clean build).

Strictly imo, using Kotlin with Spring Boot defeats the purpose if you're trying to get away from traditional Java web frameworks (didn't think I needed to spell this out due to the next sentence, but HN gonna HN).

Kotlin is a chance to get away from the cruft and annotation magic of traditional Java.

I use Ktor and it's everything you need for a modern API (and can be deployed as a WAR if that's why you want Spring Boot)

Ktor's API that will be familiar to anyone who's used similar "neo-web frameworks" in other languages like Gin or Express, and it allows you to architecture your app in a way that makes sense to you (so if you need DI, you can bring in something like Koin, but you're never compelled to by the framework)

I thought ktor was a toy, but apparently YouTrack (JetBrains' alternative to Jira) is built on top of it:

https://www.jetbrains.com/help/youtrack/standalone/Third-Par...

It's not surprising that the company behind the language would promote use of tools native to that language. They have the incentive to fix the tools if bugs are found to make the ecosystem more attractive. Whether it's a good choice for your use case - you need to evaluate it.

My old team used Spring and Kotlin and it was a really productive combination. Spring isn't standing still. They have first class support for Kotlin and rewriting their framework to support the graalvm.

Spring is not standing still, and I'm not trying to claim it is, but there's still a fair bit of ceremony around a lot of features

That's not necessarily a bad thing, but usually people who are giving the JVM a "second chance" via Kotlin were initially turned off by that ceremony

So when someone asks me "What should framework should I try for Kotlin web services?" my answer is usually Ktor.

Because if they had to ask me, they probably aren't going to be that in love with Spring Boot (people coming from Java from example, are usually just going to default to Spring Boot)

Java developers are spoiled for choice.

There's everything, from the simplest possible https://sparkjava.com/, to the a little bit nicer https://javalin.io/ (which has a Kotlin wrapper), to the high performance and full framework https://vertx.io/ (which always had great multi-lingual support within the JVM), to the newer and GraalVM-friendly https://micronaut.io/ and https://quarkus.io/ ... for the Enterprise-only crowd, you still have the JEE successor, https://jakarta.ee/ and Oracle's own https://helidon.io/#/ (which likes to position itself as microservice focused, like Micronaut and Quarkus). Not to mention lower level libraries you can use, like https://www.eclipse.org/jetty/ and https://netty.io/.

Ktor has a tough fight to become dominant even in the Kotlin world.

Spring Boot is, still, definitely the most popular option, but it's still just one of very very many!

You forgot https://www.playframework.com/

Just to add https://www.ninjaframework.org/

Never again. Play is one the worst things I've had to work in. Too much scala when you're just trying to Java.

vert.x has unfortunately reduced the support of JVM languages to Java, Kotlin and Groovy. No longer any Scala support, also no support of Javascript.

JavaScript's support has been moved to the reactiverse project. It's an incubation like project for projects that aren't fully 1.0.0 yet. In there you will find https://reactiverse.io/es4x/, the EcmaScript support For Vert.x. It's a new approach of using vert.x with GraalVM to provide modern ES language features such as ES12, instead of the old Nashorn ES5.1.

It also changes the development workflow from a maven-based project to a NPM-based project which should be more familiar to JavaScript developers.

Scala support is still being finished, however the project team decide to go ahead releasing 4.0.0 at the beginning of the year avoiding the block until the Scala support work was complete. You can follow its development on GitHub or the official Discord server.

Thanks for the info. While checking out vert.x 4.0 I had a hard time figuring out language support from the release notes and blog posts.

Or http4k, which implements "server as a function" and is fantastic for an API backend, with lenses/contracts, auto-serialization on top of your choice of Kotlinx/Gson/Moshi/Jackson, nested routing, so much more.

It depends on your needs I guess. Not all API can be handled by just a few classes. If your plan is to maake a microservice that expose a single value, yes spring boot is likely overkill. But when you have complex models with runtime configuration and profiles and so on... Maybe we need to specify what we are really talking about when we say API. For some it just means a partial implementation of REST.

Who said anything about a few classes?

How does using Ktor preclude one from using anything you just described?

Lol just using Koin alone would bring every thing you just described, with the added benefit of not delving into XML files.

Really some people are just married to the mentality of "If it's not on the feature list, I guess you can't do it". I believe in using focused tools that excel at specific things. Ktor lets you do that.

Spring (and particularly Spring Boot) requires no XML for configuration — everything can be done with annotations and plain Java (or Kotlin).

The canonical way to use Profiles, even with Kotlin is with your Maven XML or a web.xml

You can set them up other ways, but it just ends up making a lot of sense to define them there.

To be fair, Ktor is pretty similar with the "application.conf" if you use the built-in Profiles equivalent: https://ktor.io/docs/configurations.html#hocon-overview

I just prefer that if I'm using DI, the concept of environments be handled by DI. Scoping is what DI does best after all...

My team uses Kotlin + Dropwizard + Postgres a lot. I would absolutely recommend trying Kotlin out on your next API. You will find the code very easy to learn coming from Java, and it is honestly a joy to work with compared to Java. You will find your code much more concise yet more readable. Also, IntelliJ gives you all kinds of hints for how you can make use of Kotlin language features.

You can also easily handle nulls in Kotlin, since values have to be explicitly nullable in order to be able to have one. This is great for your application model layers. The val/var paradigm is nice so you can stop having to remember to write 'final'.

If you ever get stuck and don't know how to write something in Kotlin, you can just write it in Java and either use it, or just paste the code in IntelliJ and it will convert it to Kotlin.

Lastly, Kotest + Mockk is awesome--super readable testing.

What do you use at the database layer? Hibernate, or something lighter, and more Kotlin native, like Exposed?

We use MyBatis annotations. Usually, for our specific use case we are calling a Postgres sproc. It was a little tricky for one part since we have a json type column, so we had to create our own little pgobject mapper which took a day to figure out how. Other than that, it has been a breeze.

Kotlin never appealed to backend developers (based on job ads, new open-source projects in the domain). Data pipelines, concurrency and streaming are becoming more and more part of what a backend dev should know. Instead, I've noticed that Scala is used in many systems where Java historically was less ergonomic for the task. Spark, Delta, Deequ, Scio, Finagle, Flink, Kafka, the Typelevel & ZIO ecosystems, Akka are some of the examples. Using Kotlin as a sugary interface to Spring Boot? Maybe for some that would be an incentive.

I think a big part of the appeal of Kotlin was that Scala was impractical for use on Android so Kotlin slid in as "the missing pieces" of Java.

Yeah also somewhere after Java 7 (I think) Java stagnated because the next version was too ambitious (stuck in development-hell). To get back on track they cut a bunch of features, labelled it Java 8 and moved Jigsaw (the biggest hurdle) to Java 9. After this they also moved to the fixed release cycles.

Java stagnated because Google torpedoed Sun, left it sink without bothering to own Sun, Oracle was the only one that bothered to keep their buy offer (IBM withdrew theirs), and and to spend a couple of years setting the house straight.

Yet, there are no FOSS language that matches JIT and GC capabilities of the JVM.

Looking forward to the KVM, if Kotlin is so great.

Because Google as Kotlin's Godfather is stagnating Android Java on purpose, on the proper JVM we don't have such constraints.

Can't really blame Google for deciding to move away from Java after the Oracle lawsuit.

Oracle has done the right thing to smash Google's own J++.

Google had a easy way out after screwing up Sun, buy it.

Kotlin is taking off on the backend. It took a little longer than some people might have hoped but all the big boys are doing backend development in Kotlin now. Square/Netflix/Uber/Twitter/AirBnB all traditionally Java houses have adopted Kotlin in one way or another.

Scala on the other hand is facing a decline. Less so in Big Data where it is still doing well but I find increasingly it's not being chosen for new backend development.

By the same big boys that were so big into Scala 5 years ago,.....

Kafka (or rather Confluent) is actually moving parts of its code base to Java.

I work in a fintech company, most of our backend is in Kotlin with "legacy" functionality in Java.

Can't think of a single developer that would choose Java over Kotlin.

I'd choose Java over Kotlin. The benefits of Kotlin seem minor - mostly syntactic sugar - and the tooling is more limited than Java. They seem to solve problems with kludges (like their coroutines are really just state machines in JVM bytecode, which creates issues like irreducible control-flow) rather than properly engineering solutions like Java try to do.

Just sharing my experience, to each his own.

How did Java (as opposed to JVM) try to properly engineer solution to the problem coroutines were created to solve?

Project Loom: https://openjdk.java.net/projects/loom/

The view being that async-await leads to a "What color is your function" problem ( https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ).

"As opposed to JVM"

You don't have to convince me that green threads are far superior to async-await - I already believe that.

But that's not something Kotlin (nor Java, on the language level) could have solved.

You're correct but you're forgetting that the jvm IS java. When it isn't trivial to solve at the language level they have the power to change the runtime.

And on top of that Kotlin is now basically stuck with async-await forever. Removing async-await from the language and designing a more superior model the JVM now allows for with Loom is probably not going to happen. Adding a new model based on the new possibilities Loom provides will probably cause too much fragmentation (unless they come up with some really clever interop) so thats also unlikely.

Kotlin could be stuck here with a inferior co-routine model; Handicap of a headstart. Tough of course time will have to tell if the model Loom introduces in Java is going to be as great as it sounds.

> How did Java (as opposed to JVM)

Well that’s the point - they solved it in the JVM not as a kludge of bytecode.

Well, once that happened Kotlin also gets the solution.

It's rude and unfair to call out a language as "solving the problems with kludges" when they literally could not have done anything better.

Anyone can propose changes to the JVM. The Java people did. The Kotlin people didn't. And the Kotlin approach generates bad (irreducible) bytecode.

Yet the JVM had `invokedynamic` before it had any use in Java, specifically to support more dynamic languages.

But... When Java gets "properly engineered solution" for async code... Kotlin got it as well!

So why bother using Kotlin?

Seems like it fixes trivial things (makes simple classes a bit more terse) but retains the more fundamental problems and hangs on for Java to actually fix those.

It's way more than terse classes. The syntax everywhere is cleaner. Higher order functions look so much nicer. Using val/var is superior to having to remember to write 'final' all the time. Kotlin also handles nullability way better. Ah, also, default arguments for constructors/methods. These features prevent a lot of developer mistakes, and thus better code is often achieved.

Also, Kotlin usually forges ahead on features, and the Java is playing catch up. Take data classes for instance. If anything it seems like Kotlin gave Java a good kick in the pants to get it to start developing faster and adding modern language features.

Java and JVM are developed together, Kotlin just adds syntax sugar on top.

If Kotlin is so much better, why doesn't JetBrains just port everything into Kotlin/Native?

Because there are benefits to the JVM and interoperability with Java

Apparently not, given the cargo cult hate against Java on Kotlin community, glad to "leave Java behind".

Kotlin fixes just trivial things - like nullability for example. Java still doesn't have a good solution, only about 5 bad ones and nothing is in sight. It even looks like Java designers simply don't consider it a problem anymore ...

Instead, they focus on things like value types. Which are definitely cool, but they don't actually solve any of my problems. Typical business apps written in Java don't suffer from performance issues, they suffer from (accidental) complexity explosion and subsequent buginess (of which NPEs is a symptom).

When teams go so far as to consider alternatives to the JVM, memory footprint and poorly tuned GC are typical reasons.

If Kotlin's only improvement over Java were its scope functions, that alone would be an overwhelmingly good reason to migrate. Scope functions are awesome, cannot stress that enough.

Kotlin syntax makes writing functional code beautiful and simple... map and fold and filter are so much easier to write than in any other language that also have the same functions, such as JS. Again, that alone would be enough to migrate.

But there are still so many more simple, but incredibly useful functions like SubstringAfterLast which takes a nasty, ugly Split function into a beautiful, precise line of code. Just one example of many.

import static

Not at all, because Kotlin wants to take it all, so they need to make the choice if they want to expose JVM features, or keep the language portable across all platforms that JetBrains wants to target with Kotlin.

A good example is Kotlin/Native, by choosing a memory model incompatible with JVM code they failed, and were forced to go back into the drawing board for Kotlin/Native with a proper tracing GC.

If I were to use Kotlin server-side on JVM and didn't care about portability to other Kotlin platforms, could I not just use JVM green threads?

Depends on how Kotlin decides to expose them at the language level.

For example, you need special syntax to use SAM types and Kotlin cannot use all use cases from interfaces with default methods.

That is the thing with the Java Virtual Machine, the bytecodes and runtime are designed for Java, all guest languages have to pretend to be Java.

Just disassemble the amount of boilerplate generated by the Kolin compiler.

This is not always the case. One example is checked exceptions which are purely Java thing and do not exist in JVM (outside of metadata). That always amused me, it's like a switch to remove checked exceptions from language, you can turn it any time without backward compatibility issues.

Another example is inner classes. Inner class can access private fields of outer class in Java. But in JVM there's no inner class concept, so compiler generates synthetic accessors for outer class private fields and inner class uses those methods to access private fields. That was fixed recently, though, but it was the case for many decades.

Also I remember some funny bytecode with try-finally, I think it's implemented with gotos.

Of course Kotlin generates a lot more boilerplate, that's for sure.

How is the tooling more limited? I have never had a problem using any java library/framework with Kotlin.

Here is one, outside Android, Kotlin is other guest language that will fail to take Java's place on the Java Virtual Machine.

Why do you say so?

I do think kotlin isnt only aiming to the Java Virtual Machine, it is mucho more.

Life experience of seeing guest languages come and go, during the last 30 years, and never succeeding in the goal to replace platform languages.

On the contrary, platform languages slowly acquire the relevant features of the shiny languages, which eventually either fade away or find a niche for survival.

Kotlin will be relevant as long as Android exists, that is all.

Scala, Clojure, and Groovy are all mature languages that haven't gone anywhere. No one has a goal of replacing Java, and they all benefit from improvements to the JVM.

Mere blips on the Java eco-system, why do you think Typesafe has pivoted into Lightbend and now also does Java projects?

Gradle and Google choosing it for Android are the only things that keeps Groovy still relevant.

As for Clojure, it is its own thing, plugging into the host platforms.

Of the JVM languages, AFAIK only Kotlin is making a serious push to get off the JVM using something like LLVM. Interesting idea, though I wonder how long they can preserve compatibility between JVM and native targets.

Scala native doesn't feel like it has the same impact, perhaps in part due to a lack of momentum (as I perceive it).

Clojure exists outside the JVM as well (ClojureScript, Babashka, ClojureCLR)

It does, but not in the same platform-antagonistic way. Clojure instead embraces many different platforms and runs on them through various dialects; Kotlin wants to become a platform.

Scala preceded it with both Scala Native and ScalaJS.

Entirely replacing estabilished languages doesn't really ever happen, it's just the nature of the game.

Server software for unixy systems used to be near universally written in C and it's still "the" platform language. And it can be certainly be said that alternative languages have come and gone.

But: C has become a niche.

Other than Android, where Google is pushing Kotlin no matter what, I would use the platform's official language, Java.

No need for FFI, additional IDE plugins, it works across all Java IDEs, no need for idiomatic plugins, annotations to make code understandable by the JVM, full access to JVM opcodes without constraints or special cases, and it will be around as long as the Java Virtual Machine matters to the industry.

You can't go wrong with either choice. Both languages are mature enough to be used in production. I, personally, would use Java, but that's just my preference.

Actually you don't really need any new features to write useful programs. They might help, but they are not necessary.

My advice would be to learn both languages and use your own judgement which one you would like more.

I'm doing a kotlin project. You won't find it hard or unfamiliar if you're used to Java. You still got gradle, and you still can use whatever java lib you want. It just feels much nicer in kotlin. Just jump into it, you can swap back if it doesn't suit you.

I've been using Kotlin in the backend since 1.0 (4 years now??) and it's great, but it does have a few small annoyances. We still have most of our codebase in Java and routinely, we create new Java code instead of Kotlin for everything, interestingly enough (mostly because when a module is already written in Java, it's mostly a source of confusion to add a few Kotlin files - so we tend to only use Kotlin when creating new modules that are fully Kotlin). Also, some of our developers just don't seem to have enough abstraction power for the higher level of code you can write in Kotlin (specially when you start using things like Kotlin builders to make code "prettier", or just abust a little bit the "everything is an expression" feature to completely avoid separete statements - e.g. functions without braces).

People moving from Kotlin back to Java is not unheard of: https://blog.allegro.tech/2018/05/From-Java-to-Kotlin-and-Ba...

I've been writing Kotlin professionally for the past 2 years. I'd highly recommend it as a worthy successor to Java. It's very powerful and thoughtfully designed. Java just feels so old and clunky after using it.

I've not had the pleasure but I hear Scala is great too.

So is there a Kotlin Virtual Machine already available?

It runs on the JVM. That's one of its selling points. :)

So Kotlin is useless without Java then, unable to stand on its own.

It’s a great language to use instead of Java...especially for things that have to run on the JVM, or Android.

Syntax sugar on the JVM, as it is never to be more than a blip on the Java Virtual Machine.

As for the Android Runtime, Android team is gatekeeping Android Java on Java 8 subset on purpose, as means to serve their political games to push Kotlin no matter what.

Kotlin without godfather Google will just fade away.

I have no idea about any politics involved, but Kotlin is a really well designed language. Fixing Java piecemeal as has happened so far just seems like an impossible task, while the JVM is flexible enough to support it.

You have no idea? Missing the news?

Google lets Android Java stagnate on purpose on Java 8 subset, with cherry picked APIs from newer OpenJDK versions, uses this language subset to sell Kotlin features over Java features on code samples comparisasions.

Nowadays, all Android developer channels, regardless on which form, are all inundated with Kotlin material and how great it is over "Java" (actually Android Java).

As for JVM being flexible enough to support Kotlin, doesn't seem to be appreciated by the Kotlin community that spits on the hand that has made the language possible to exist in first place.

Language wars don't have a place when languages share the same platform, as such I have zero tolerance for communities that cargo cult otherwise.

When Kotlin is so great and doesn't need Java for anything, they should port everything into Kotlin/Native and succeed on its own merits.

The JVM is just a detail, as a language designer, an utterly boring one. Who cares if your language is running on that or via native compilation. In fact, after seeing what happened at Microsoft with UwP, I’ll take convenience over ahead of time compilation any day.

I also find language politics to be incredibly boring. Maybe you have a point, but I just want to write code in a language that isn’t 10 years out of date.

Languages without platforms fade away, history is full of examples.

For better or worse, Kotlin designers have decided to make a deal with Android for turning it into Kotlin's plaform, and they definitely do not care what happens with the JVM.

Kotlin designers will eventually, like everyone else, find out that one cannot stand on both sides when things start heating up.

Then there is the whole matter of ChromeOS vs Android vs Fuchsia of Google's internal politics, and Kotlin is only relevant in one of them.

I don't know why you are replying with this like some kind of gotcha...

First of all Java and the JVM are two different things. One is a language and one is a runtime.

Yes Kotlin requires the JVM. So does Scala and a lot of other languages. Leveraging the JVM runtime means that Kotlin can inter-op with Java libraries and the ecosystem at large without having to build all those things anew. Its all upside. You get the niceties of the language plus the rich ecosystem. I can for instance leverage Apache POI in Kotlin to generate some excel workbooks despite the fact that that library is old af and doesn't know anything about Kotlin. I have in fact. It works great.

Your argument doesn't have legs to stand on. Languages like Elixir leverage existing runtimes as well. Its not uncommon and its a feature not a bug.

Kotlin outside of Android is still a fancy new thing. I am not commenting on its capability but the trend.

(On Android however it seems it's pretty much the only thing now. I am finding it the hard way now when I am looking for a job after staying on a project too long where things are still 98% Java)

It's an amazing language. Just try not to write "Java code" (as in the Java way) in Kotlin (like many Android devs I see doing).

Try it out! I’ve been building with Java for about 13 years and just started playing around with Kotlin last year, and I must say that I fell in love immediately.

I did a dropwizard and kotlin project around 1.2.20 (3 years ago) and it was fine even then, with some minor rough edges.

I would imagine everything is fine now.

I would, main reason being calling Java from Kotlin is seamless. It makes most things easier by being expression oriented and having less verbose yet familiar syntax also saner type system. So you can just use it as better Java.

If you want to go further you can also use other nice features like suspend functions, hot/cold channels, sealed classes.

I recommend having a look at http4k as an alternative to Ktor and Spring as well.

Kotlin on the server is the dream

For your use case just use PostgREST.

Reply on news.ycombinator.com