4 ms·
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
by ta988 6y ago
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).
- BoorishBears 6y agoStrictly 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)
- scaladev 6y agoI 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-Party-Software-Used-by-YouTrack.html#YouTrack_Back-End_Libraries https://www.jetbrains.com/help/youtrack/standalone/Third-Par...
- isbvhodnvemrwvn 6y agoIt'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.
- eweise 6y agoMy 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.
- BoorishBears 6y agoSpring 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)
- brabel 6y agoJava developers are spoiled for choice. There's everything, from the simplest possible https://sparkjava.com/ https://sparkjava.com/, to the a little bit nicer https://javalin.io/ https://javalin.io/ (which has a Kotlin wrapper), to the high performance and full framework https://vertx.io/ https://vertx.io/ (which always had great multi-lingual support within the JVM), to the newer and GraalVM-friendly https://micronaut.io/ https://micronaut.io/ and https://quarkus.io/ https://quarkus.io/ ... for the Enterprise-only crowd, you still have the JEE successor, https://jakarta.ee/ https://jakarta.ee/ and Oracle's own https://helidon.io/#/ 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/ https://www.eclipse.org/jetty/ and https://netty.io/ 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!
- mkurz 6y agoYou forgot https://www.playframework.com/ https://www.playframework.com/
- ta988 6y agoIt 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.
- BoorishBears 6y agoWho 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.
- shock-value 6y agoSpring (and particularly Spring Boot) requires no XML for configuration — everything can be done with annotations and plain Java (or Kotlin).
- BoorishBears 6y agoThe 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 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...