loading...
re: Groovy if you want same frameworks, or Scala if you just need JVM. Kotlin has suspend. That's all it has. I had more troubles with data classes and...
 

I've never hit an issue with Kotlin's null safety when using it properly, I'd be curious what problems you ran into with it.

As for data classes, the only place I had issues with this was with Spring but this was years ago when their Kotlin integration was very immature.

Lombok can be problematic as it does a lot of code generation and requires an IDE plugin to even use it with IntelliJ. The excessive amount of annotations gets noisy very quickly too.

Using it properly? Theres just one way to use it, either it's nullable or not. And many cases demand nulls when it came to implementing different domains which I realised once started to work with Kotlin. This was unknown fact to me until I refactored code many times and saw it look like this? that? other? In data classes and calles looked 1000 cahrs long because I waz suggested by IDE to put = if..else with?.?. or ?: throws etc. Then I stared noticing how much time I need Groovy trait and not an interface. I ended up writting double the code in comparison to Java or Groovy because of restrictions which sounded good at a time. And there's no "properly" argument that makes any sense here. I basically hit the domain which has no benefit from Kotlins way of doing things. The only valid thing was suspend works with RxJava/Reactor so it looks more clean without .map().map Mono<> and so.

Your initial post didn't have much context and I don't know your familiarity with Kotlin so I was just checking it wasn't a common mistake someone coming from Java can make like using double bang (!!) all over the place.

That happens to. However null safety has no need for context, by default you have non-nullable stuff. Then you add ?. Then you know some things will be 100% there like val id? will not be null when getting it from DB and there you go with !! . So null safety is not having things nullable but rather the opposite - the Kotlin way of not having anything by default as nullable. At least this is how I make things shorter an easier for myself when using no context.

code of conduct - report abuse