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 null safety than help. If you write code differently than get/set or using lombock, data class usefullness goes away. Still don't understand why did people jump so much on it except that I see constant comparison with lombock stuff. I only use it to make rector/rxjava look pretty
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.
So ... the better part of Java is Kotlin.
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 null safety than help. If you write code differently than get/set or using lombock, data class usefullness goes away. Still don't understand why did people jump so much on it except that I see constant comparison with lombock stuff. I only use it to make rector/rxjava look pretty
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.
Kotlin is too much concerned about brevity (which is mostly irrelevant) and freedom to make chaos in codebase.
Freedom to make chaos. So that's what I'm looking at when I see my API now