DEV Community

loading...

Discussion on: Python vs Java

Collapse
erikthered profile image
Erik Nelson

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.

Thread Thread
greenroommate profile image
Haris Secic

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.

Thread Thread
erikthered profile image
Erik Nelson

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.

Thread Thread
greenroommate profile image
Haris Secic • Edited

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.