Hi everyone. I am in desperate need of your help. ...

# server

[Tim Schraepen]

Hi everyone. I am in desperate need of your help.

Who @here has references for (belgian) projects done in Kotlin and wants to share these references?

I’m trying to build a stronger case to start using Kotlin as a strategy for the company I’m working for.

Looking ideally at Kotlin projects as replacement for (typical) Java backend projects.

[muliyul]

We're working with Kotlin, Dropwizard & Jersey to much success here at Next-Insurance. Most of our backend codebase is written in Kotlin. I think the language features, ease of use and onboarding for new Java hires, seamless integration with the Java ecosystem and maintainability of the code are the best assets of Kotlin. I'd start out by laying out the obvious benefits (like shorter code, [im]mutability and superb type safety features) and then laying out how your company can benefit from these (less bugs, easier maintainance etc...).

[Tim Schraepen]

Thank you for the suggestion. This I’ve done already.
Main arguments I’m getting right now are :
from a dev perspective - kotlin only brings marginal gains (, and it’s an entire new language so I have to learn a whole other new language, ... this I classified under lack of knowledge and fear of the unknown, it’s approachable and within my circle of influence)

harder to defend to customers - in the plethora of items we need to defend, like pairprogramming, TDD, devops, ...), having another battle to win might be one too many. This one is much harder to relay or fix and mostly outside my circle of influence.

[corneil]

If the quality and speed of delivery is a problem then changing the programming language isn't going to make things better.

[Renato Dinhani]

I migrated a GraphQL API gateway from Java to Kotlin. For me, Kotlin was an easier and more natural way to write "modern" Java.

In Java I always had to remember to mark classes, variables and parameters as final, to pass and return Optionals, to have a lot of method overloads to handle optional parameters, to use external immutable collections, etc.

The Java code was good, but it was not natural for other developers that are not used to these things. In Kotlin, all these things are the default in the language.

[Tim Schraepen]

Thank you for that addition and the use of the word “natural”.

[corneil]

I tell Java programmers at first: In your mind you lowlight certain Java code in order to understand the code. The parts that remain is basically Kotlin. Then you follow hints for more idiomatic Kotlin and quickly you are in a new safer world where you smile while coding.

[Tim Schraepen]

Thanks for that!

[corneil]

You're welcome!

[pniederw]

I'd question "marginal gains". in my experience, the gains are substantial, even compared to java 13+.

[pniederw]

if you keep coding in java style or keep using java frameworks that don't exploit kotlin's features, the difference may be less dramatic. personally I think that choosing kotlin over java for backends is a no-brainer in 2020, and that starting a new java project is almost irresponsible (because delivering the same project in java takes way more work).

[pniederw]

backends increasingly use async i/o, and kotlin coroutines are a life saver there. dramatically simplified programming model compared to callbacks/futures/streams.

[corneil]

For me Kotlin implies a reduction in cognitive load and complexity without giving up any power.

[Tim Schraepen]

Ooph! That is very eloquently put Corneil du Plessis.
Thanks for your addition to this thread @pniederw. Do you have any examples of coroutines vs. rx/callbacks/futures/streams that really show the pain in Java and the bliss in Kotlin?
I personally don’t have proper experience with that so I didn’t feel like I could honestly use that as a good argument but I’ve been given the coroutines argument a couple of times now.

[pniederw]

I don't have a pointer, but everyone who's written both blocking and non-blocking code in java knows that the latter is much harder to read and write (and debug). with coroutines, you write blocking code and get the scalability of non-blocking code. java will eventually catch up (project loom) but that's likely a few years off, especially if you stick to LTS versions.

[corneil]

I imagine that the JVM version of coroutines will start leveraging Loom once it is available

[pniederw]

so far, kotlin folks have answered this question with "we'll look into this once loom is ready".

[corneil]

Obviously they need to make sure Loom is ready and stable and then decisions can be made. It could just make coroutines even more efficient if loom is delivering on the promises.

[Tim Schraepen]

Thanks again folks. 🙏