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).
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)
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)
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!
It also changes the development workflow from a maven-based project to a NPM-based project which should be more familiar to JavaScript developers.
https://www.jetbrains.com/help/youtrack/standalone/Third-Par...
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.
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...
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.
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.
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.
Google had a easy way out after screwing up Sun, buy it.
Can't think of a single developer that would choose Java over 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.
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.
If Kotlin is so much better, why doesn't JetBrains just port everything into Kotlin/Native?
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.
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).
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.
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.
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.
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-... ).
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.
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.
Well that’s the point - they solved it in the JVM not as a kludge of bytecode.
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.
I do think kotlin isnt only aiming to the Java Virtual Machine, it is mucho more.
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.
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.
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.
Scala native doesn't feel like it has the same impact, perhaps in part due to a lack of momentum (as I perceive it).
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.
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.
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 not had the pleasure but I hear Scala is great too.
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.
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.
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.
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.
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.
(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).
I would imagine everything is fine now.
If you want to go further you can also use other nice features like suspend functions, hot/cold channels, sealed classes.
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?