3 ms·

> * data class Foo(val theImplementationAndStyleOfDataClasses: String) For the purists there are records now in Java (which can be combined with destructuring

by haspok 2y ago

> * data class Foo(val theImplementationAndStyleOfDataClasses: String) For the purists there are records now in Java (which can be combined with destructuring / pattern matching - there were significant improvements in this area in the last few JDK releases, and more are coming!). In this regard Java had surpassed Kotlin by some margin. For the enterprise coders, there is the Immutables project (https://immutables.org https://immutables.org) which you can say is Lombok on steroids (but implemented correctly, that is, by generating classes which you can inspect as regular source code, instead of relying on hacking the compiler...). > * elvis?.operator?.chaining This will hopefully be finally resolved by one of the subprojects of project Valhalla, as a prerequisite for value class support (which cannot be null, so...). The others on your list are small and subjective stylistic differences, of course your preference may vary, but should not weigh heavily in any Java vs Kotlin discussion.

t-writescode 2y ago
> pattern matching ... In this regard Java had surpassed Kotlin by some margin. I did just glance at Java's pattern matching; and yeah, it does look like it is a bit more powerful than Kotlin's pattern matching in that it can, at the same time, look for both type and a conditional. That's relatively neat - not something I've personally needed / wanted; but neat just the same :) The JVM is a really nice virtual machine in how it lets us use both of these languages fully interchangeably to pick the one we like more. I'm glad Java has been investing in some of these areas, too. Everyone improves when paradigms and new learnings are distilled.
- houli 2y ago
  Kotlin 2.1 has added "Guard conditions in when with a subject" as an opt-in feature https://kotlinlang.org/docs/whatsnew21.html#guard-conditions-in-when-with-a-subject https://kotlinlang.org/docs/whatsnew21.html#guard-conditions...
unscaled 2y ago
Java records do not have a copy method (or with clause or whatever equivalent), and there are no keyword arguments. This makes Java records extremely painful to use for any data has more than 3 fields or so. You could use them together with an annotation processor like RecordBuilder (or Immutables or Lombok, but I don't think they support records?), but that's just not pure Java. Annotation processors that generate byte code always come with their own complexity. Kotlin data classes have their own warts (order-based destructuring can be dangerous and the copy() method is a bit hacky) but the overall ergonomics for large value objects are better than Java records at this point.
- stickfigure 2y ago
  Lombok supports `@With` on records, which adds wither methods. And there are ongoing JEP discussions on how to support this natively in Java. Lombok is so ubiquitous today that I effectively consider it part of the language. And even with Lombok, the Java toolchain is so much faster, easier to use, and more stable than Kotlin. Kotlin is a great language, marginally better than Java, but I'm not sure it's worth enduring the toolchain. And Java keeps improving.
  - mrudolph22 2y ago
    If you think Kotlin is marginally better than Java, you probably have a superficial understanding of Kotlin. Kotlin is vastly better than Java, which isn't surprising because Kotlin was designed 15 years later with the explicit goal of being a better Java and fixing as many of Java's design mistakes as possible. For example, the designers of Kotlin went through the book "Effective Java" and tried to avoid the listed pitfalls by design. Java will never get close to Kotlin because even though Java can, and thankfully does, still improve, it's too late to revise many of it design decisions, and large language features often need to be considered in a language's design from the start. On Android, Kotlin is an even bigger win because Android uses an old Java version and has become Kotlin-first. In my opinion, Java will remain the best choice for libraries that target multiple JVM languages. For everything else, I use Kotlin without thinking twice. Kotlin 2.0 laid the groundwork for toolchain improvements, which have indeed been a long-standing pain point.
    - stickfigure 2y ago
      Nah: If you think Kotlin is vastly better than Java, then you have a poor grasp of Java. I offer the same evidence you did. Having worked professionally in both, I find that good programmers can write excellent code in both languages; bad programmers can write terrible code in both languages. The average cultural practice of the Kotlin community is perhaps better than the average cultural practices of the Java community (which huge and defies averaging anyway). But Java code which emphasizes immutability, uses Optional instead of nulls, uses streams, etc is pretty indistinguishable from Kotlin.
jeroenhd 2y ago
> This will hopefully be finally resolved by one of the subprojects of project Valhalla I think we'll see them come in through https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099 although I'm not a huge fan of the approach chosen (tri state nullability: explicitly nullable, explicitly non-nullable, legacy code that should just be treated as nullable). Except for native support for reification, almost all of Kotlin can be reimplemented by Java if you wait long enough and stack enough class annotations. It's all stylistic up to a certain point, but the classic Java style combined with the glacial improvement process is one reason why some people want to use a different language. I think I'll have an easier time convincing someone to consider Kotlin than I'll have convincing someone to add Immutables+Manifold to the dependency chain. You end up writing Java that's not really Java like, but also not something that there's a good standard style for, and that usually ends up in a mess. I'm glad with pattern matching, Java is now pushing Kotlin to improve rather than the other way around. I'll hope to use those features one day, when companies finally upgrade from Java 11 to Java 17 in five or ten years.

by haspok 2y ago

t-writescode 2y ago

> pattern matching ... In this regard Java had surpassed Kotlin by some margin. I did just glance at Java's pattern matching; and yeah, it does look like it is a bit more powerful than Kotlin's pattern matching in that it can, at the same time, look for both type and a conditional. That's relatively neat - not something I've personally needed / wanted; but neat just the same :) The JVM is a really nice virtual machine in how it lets us use both of these languages fully interchangeably to pick the one we like more. I'm glad Java has been investing in some of these areas, too. Everyone improves when paradigms and new learnings are distilled.

houli 2y ago
Kotlin 2.1 has added "Guard conditions in when with a subject" as an opt-in feature https://kotlinlang.org/docs/whatsnew21.html#guard-conditions-in-when-with-a-subject https://kotlinlang.org/docs/whatsnew21.html#guard-conditions...

unscaled 2y ago

Java records do not have a copy method (or with clause or whatever equivalent), and there are no keyword arguments. This makes Java records extremely painful to use for any data has more than 3 fields or so. You could use them together with an annotation processor like RecordBuilder (or Immutables or Lombok, but I don't think they support records?), but that's just not pure Java. Annotation processors that generate byte code always come with their own complexity. Kotlin data classes have their own warts (order-based destructuring can be dangerous and the copy() method is a bit hacky) but the overall ergonomics for large value objects are better than Java records at this point.

stickfigure 2y ago
Lombok supports `@With` on records, which adds wither methods. And there are ongoing JEP discussions on how to support this natively in Java. Lombok is so ubiquitous today that I effectively consider it part of the language. And even with Lombok, the Java toolchain is so much faster, easier to use, and more stable than Kotlin. Kotlin is a great language, marginally better than Java, but I'm not sure it's worth enduring the toolchain. And Java keeps improving.
- mrudolph22 2y ago
  If you think Kotlin is marginally better than Java, you probably have a superficial understanding of Kotlin. Kotlin is vastly better than Java, which isn't surprising because Kotlin was designed 15 years later with the explicit goal of being a better Java and fixing as many of Java's design mistakes as possible. For example, the designers of Kotlin went through the book "Effective Java" and tried to avoid the listed pitfalls by design. Java will never get close to Kotlin because even though Java can, and thankfully does, still improve, it's too late to revise many of it design decisions, and large language features often need to be considered in a language's design from the start. On Android, Kotlin is an even bigger win because Android uses an old Java version and has become Kotlin-first. In my opinion, Java will remain the best choice for libraries that target multiple JVM languages. For everything else, I use Kotlin without thinking twice. Kotlin 2.0 laid the groundwork for toolchain improvements, which have indeed been a long-standing pain point.
  - stickfigure 2y ago
    Nah: If you think Kotlin is vastly better than Java, then you have a poor grasp of Java. I offer the same evidence you did. Having worked professionally in both, I find that good programmers can write excellent code in both languages; bad programmers can write terrible code in both languages. The average cultural practice of the Kotlin community is perhaps better than the average cultural practices of the Java community (which huge and defies averaging anyway). But Java code which emphasizes immutability, uses Optional instead of nulls, uses streams, etc is pretty indistinguishable from Kotlin.

jeroenhd 2y ago

> This will hopefully be finally resolved by one of the subprojects of project Valhalla I think we'll see them come in through https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099 although I'm not a huge fan of the approach chosen (tri state nullability: explicitly nullable, explicitly non-nullable, legacy code that should just be treated as nullable). Except for native support for reification, almost all of Kotlin can be reimplemented by Java if you wait long enough and stack enough class annotations. It's all stylistic up to a certain point, but the classic Java style combined with the glacial improvement process is one reason why some people want to use a different language. I think I'll have an easier time convincing someone to consider Kotlin than I'll have convincing someone to add Immutables+Manifold to the dependency chain. You end up writing Java that's not really Java like, but also not something that there's a good standard style for, and that usually ends up in a mess. I'm glad with pattern matching, Java is now pushing Kotlin to improve rather than the other way around. I'll hope to use those features one day, when companies finally upgrade from Java 11 to Java 17 in five or ten years.