![]() We can see some of that happening already with the way Arrow handles effects. Probably the most interesting question is whether it's better than Kotlin forces you to deal with the "function coloring" problem (i.e., functions are normal or suspend, and you can't just call a suspend function from a normal function) or whether it's better that Java completely hides that inside the JVM.įor example, what's good about the Kotlin view of concurrency is that, by explicitly declaring it, and how it maps down to continuation passing, it's possible to build up sophisticated libraries for whatever abstractions you want. I suspect that somebody will eventually make a CoroutineContext or whatever that allows the Kotlin async features to use Loom under the hood. The short answer is that Kotlin can call any JVM function, so you could write a whole Kotlin program without using any Kotlin async / suspend features and make it work with Loom. ![]() Should I go with Java or is it worth investing in Kotlin given 'loom' is around the corner ? Im currently torn between Java and Kotlin for server side usage and I would appreciate some insights that would help me choose a future proof language. Would Kotlin be able to take advantage of the loom project in the future or will it be something that only Java will have ? I was seriously considering Kotlin for 2023 projects but then I stumbled upon Loom project in Java that would enable the use of lightweight Virtual threads. Null safety, Higher order functions, coroutines with support for async await seems really nice. However, coming from JavaScript/TypeScript background I find Kotlin quite impressive. Java is de facto industry standard for enterprise web apps (at least in India). My application depends on a few third party apis and hence my services would need to be non-blocking and async. I am coming from JavaScript/NodeJs background and was considering a JVM based language for creating microservices for my project.
0 Comments
Leave a Reply. |