4 ms·

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 t

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.
    - deleted 2y ago
      [deleted]
    - mrudolph22 2y ago
      I first learned Java in 1997 and have been using it professionally since 2005. If your Kotlin code is pretty indistinguishable from your Java code, you aren't using Kotlin properly. Here is what I wrote on this topic in 2022: Here are some of my favorite Kotlin improvements over Java that I leverage all the time: * Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments) * Local variables are final by default ("val") * Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java) * Much improved collection API * Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions) * Extension functions (incredibly useful in practice) * Much better DSL capabilities (great for UIs, generating HTML, etc.) * Lazy properties (more generally: delegated properties) * Coroutines (looking forward to Java's Loom; by then coroutines will have dramatically improved my async code for 5+ years) * Great serialization support (kotlinx.serialization) * Pragmatic macro-like capabilities via inline functions and compiler plugins (removes lots of boilerplate) * Multiplatform support (JVM/JS/WASM/native; Graal native image is a good alternative to Kotlin/native and also works for Java)
      - stickfigure 2y ago

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.
  - deleted 2y ago
    [deleted]
  - mrudolph22 2y ago
    I first learned Java in 1997 and have been using it professionally since 2005. If your Kotlin code is pretty indistinguishable from your Java code, you aren't using Kotlin properly. Here is what I wrote on this topic in 2022: Here are some of my favorite Kotlin improvements over Java that I leverage all the time: * Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments) * Local variables are final by default ("val") * Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java) * Much improved collection API * Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions) * Extension functions (incredibly useful in practice) * Much better DSL capabilities (great for UIs, generating HTML, etc.) * Lazy properties (more generally: delegated properties) * Coroutines (looking forward to Java's Loom; by then coroutines will have dramatically improved my async code for 5+ years) * Great serialization support (kotlinx.serialization) * Pragmatic macro-like capabilities via inline functions and compiler plugins (removes lots of boilerplate) * Multiplatform support (JVM/JS/WASM/native; Graal native image is a good alternative to Kotlin/native and also works for Java)
    - stickfigure 2y ago