Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java's records, Lombok's data, and Kotlin's data classes

nipafx.dev

Post reply on HN
Print view View original

241–250 of 294 posts

Re: Java's records, Lombok's data, and Kotlin's data classes

#241

Post by valenterry »

slver wrote: post #29
valenterry wrote: post #6

> Actually, records are even better* than tuples. EP 395 says: > > Records can be thought of as nominal tuples. They are certainly not better, that's just a sad click-bait (the author even admits that). Sometimes nominal typing is better and sometimes structural typing is better. Forcing people to always use nominal types just ends in a lot of generic or long/meaningless names - one can already see this in Java.

I've been thinking about structural vs nominal. As you say, both have use cases. How would you combine both in one language so it's not confusing?

I'm not sure, but I think I would make a language based on structural typing only, including to allow a structural type to contain names. (Scala actually already has literal types that come close)

Think about the following type-level (not runtime) representation for a structural type (tuple):

    (String -> Integer)
And the following for a structural type with where each "member" has a name:

    (("name" -> String) -> ("age" -> Integer))
And the following for a named structural type where each "member" has a name:

    ("User" -> (("name" -> String) -> ("age" -> Integer)))
The last structural type here would be equivalent to a class/record in Java. I would then add syntax that makes working with these special kinds of structural types more easy. So

    record User (String name, Integer age)
would translate to the structure above. But one could also do something like that _if they wanted to_:

    ("User" -> (("field1" -> ("name" -> String)) -> ("field2" -> ("age" -> Integer))))
The closed equivalent would be a Java record where each member is annotated. This could be used to serialize/deserialize it into json.

I think that's what I would try :) but I'm not a PL designer.

Re: Java's records, Lombok's data, and Kotlin's data classes

#242

Post by lmm »

kerblang wrote: post #181
ernst_klim wrote: post #161

Earlier quoted context omitted.

> except the problem of too many features Scala is a pretty simple, concise and coherent language though. Never understood why people deem it has too many features, I write it professionally and never felt so. At least comparing it to C, C++, Python. Java may be more simple, but you have tons of features added with metaprogramming via dozens of annotations generating lots and lots of boilerplate, Lombok and Spring ar…

> Never understood why people deem it has too many features I'll start with one (key)word: `implicit` I agree with your distaste for metaprogramming though.

Implicits are one feature that replace many features in other languages (Kotlin has probably 5 or 6 special features that each do limited subsets of what implicits can do, and still misses important parts of their functionality). There is some legitimate criticism to be made of Scala implicits (though I have yet to see a better alternative), but "too many features" isn't it.

Re: Java's records, Lombok's data, and Kotlin's data classes

#243

Post by lmm »

adambatkin wrote: post #111
halfmatthalfcat wrote: post #23

Earlier quoted context omitted.

Scala is usually omitted for one reason or another when Kotlin is compared against Java as a better alternative, which is a shame.

Lombok and Kotlin are both much easier to integrate into existing Java applications and libraries than Scala.

Not so IME. Kotlin's nullable types don't play nice with option-oriented APIs (e.g. Java Streams), and you can't make Java types transparently implement Kotlin interfaces (and there's no equivalent to typeclasses), so using Java types with Kotlin libraries is harder than with Scala libraries.

Re: Java's records, Lombok's data, and Kotlin's data classes

#244

Post by lmm »

throwpupper wrote: post #179
kelnos wrote: post #167

Earlier quoted context omitted.

I don't see how Kotlin is easier to integrate into an existing Java app than Scala is. They both require adding new dependencies and changing your project build config, and require developers who know the respective new language. That's... about it. They both offer similar levels of interop with Java libraries. If you want to assert that finding Kotlin developers is easier or that Kotlin is an easier language to lear…

What about the fact that Kotlin collections are fully interoperable with Java collection? That makes the transition significantly easier.

You can use Java collections in Scala just as you do in Kotlin, and in fact interop is easier in Scala since you can write typeclass instances for the Java types whereas there's no equivalent for that in Kotlin.

The real difference is that more of the Kotlin ecosystem uses Java's fundamentally mutable collections compared to the Scala ecosystem, and using actually immutable collections in Kotlin is extremely difficult to the point that essentially no-one does it. IMO that's a bad tradeoff in the long term, but you can absolutely take the same approach in Scala if you really want to.

Re: Java's records, Lombok's data, and Kotlin's data classes

#245

Post by vbezhenar »

ctvo wrote: post #9

Who is arguing otherwise? It's assumed that when a language adds a new feature that's historically been provided by libraries, it's probably better optimized. CompletableFutures, Streams, Date/Time. For many they've replaced libraries filling the gaps. But not all of us can use JDK 14, and will continue to use Lombok if we're writing in Java.

You need JDK 16 to use records without preview flags. And "with" syntax probably won't be available for JDK 17 which is next LTS, so for the next 3 years records will not be very useful for most projects, I guess.

Re: Java's records, Lombok's data, and Kotlin's data classes

#246

Post by aphexairlines »

crdrost wrote: post #183
billyjobob wrote: post #14

Kotlin data classes can use Java records as their implementation if running on JVM, so it’s not like you have to choose one or the other. https://kotlinlang.org/docs/jvm-records.html#declare-records...

This is great news! I was also kind of surprised to see the article talking about algebraic data types... table stakes for ADTs is sum types and I have missed them considerably in the Java ecosystem. Kotlin has something like them with sealed classes, although I'm a newcomer to the Kotlin and Spring Boot ecosystem so I don't see explicitly how I make some simple case like JSON {"type": "left", "abc": 123} {"type": "r…

You do it like this: https://github.com/Kotlin/kotlinx.serialization/blob/master/...

Re: Java's records, Lombok's data, and Kotlin's data classes

#247

Post by snuxoll »

valenterry wrote: post #235
mumblemumble wrote: post #110

Earlier quoted context omitted.

I think that case classes are roughly equivalent to Kotlin data classes for the purposes of this comparison. In particular, one of the extra features they offer is the ability to make fields mutable. Which, in some cases, may be useful, but also means that they aren't, strictly speaking, transparent carriers of immutable data .

Not only that, but they offer some other features that (to my knowledge) both records and kotlin's data classes don't offer. Which is control over accessibility. E.g. when you have a "NegativeNumber" type and you need to make sure the inner value is actually negative. Then just using having a check in the constructor isn't sufficient in the existence of copy methods (like kotlin) does it.

The copy methods that Kotlin generates construct a new instance of the class with the updated fields - so any validation done in the constructor would in fact be done again.

Re: Java's records, Lombok's data, and Kotlin's data classes

#248

Post by lolinder »

lmm wrote: post #242
kerblang wrote: post #181

Earlier quoted context omitted.

> Never understood why people deem it has too many features I'll start with one (key)word: `implicit` I agree with your distaste for metaprogramming though.

Implicits are one feature that replace many features in other languages (Kotlin has probably 5 or 6 special features that each do limited subsets of what implicits can do, and still misses important parts of their functionality). There is some legitimate criticism to be made of Scala implicits (though I have yet to see a better alternative), but "too many features" isn't it.

What Kotlin features do implicits serve to replace? I'm new to Scala and am having trouble imagining when I'd want to use an implicit, so I'm genuinely curious.

Re: Java's records, Lombok's data, and Kotlin's data classes

#249

Post by lmm »

lolinder wrote: post #248
lmm wrote: post #242

Earlier quoted context omitted.

Implicits are one feature that replace many features in other languages (Kotlin has probably 5 or 6 special features that each do limited subsets of what implicits can do, and still misses important parts of their functionality). There is some legitimate criticism to be made of Scala implicits (though I have yet to see a better alternative), but "too many features" isn't it.

What Kotlin features do implicits serve to replace? I'm new to Scala and am having trouble imagining when I'd want to use an implicit, so I'm genuinely curious.

Off the top of my head: Extension methods. "with" contexts. Scope functions (by letting you write your own). Many of the things done with kapt (e.g. typeclasses, not that there's a good way to do them in Kotlin). Spring-style autowiring (not part of Kotlin proper, but seemingly the idiomatic way to use it). The magic last parameter lambda syntax thing (by letting you implement the magnet pattern).

Re: Java's records, Lombok's data, and Kotlin's data classes

#250

Post by lolinder »

lmm wrote: post #244
throwpupper wrote: post #179

Earlier quoted context omitted.

What about the fact that Kotlin collections are fully interoperable with Java collection? That makes the transition significantly easier.

You can use Java collections in Scala just as you do in Kotlin, and in fact interop is easier in Scala since you can write typeclass instances for the Java types whereas there's no equivalent for that in Kotlin. The real difference is that more of the Kotlin ecosystem uses Java's fundamentally mutable collections compared to the Scala ecosystem, and using actually immutable collections in Kotlin is extremely difficul…

I write Kotlin all day and almost exclusively use immutable types. What difficulties with using them are are you referring to?
Post reply on HN