Comment by ta988 | Hacker News Reader

Comment by ta988 | Hacker News Reader

Parent Full thread

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...

Reply on news.ycombinator.com