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

231–240 of 294 posts

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

#231

Post by joshlemer »

darksaints wrote: post #220
balefrost wrote: post #205

Earlier quoted context omitted.

Kotlin's STDLIB collection types are essentially aliases for the Java types. So while the Scala adapters are low-cost, in Kotlin everything's zero-cost. One other benefit of that is you maintain object identity. I don't think that Scala's wrappers do that.

Scala has the full suite of Java collections without any conversion or overhead whatsoever. But it also has Scala collections. With scala collections you get the full power of the Scala type system, as well as a much richer and full featured collections api. So most scala programmers won't bother with java collections unless they have specific java interop requirements. The Scala adapters are merely ways of convertin…

I think it's a fair complaint that in Scala it is a pain in the ass to deal with Java collections. You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc.

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

#232

Post by valenterry »

diroussel wrote: post #218
asimpletune wrote: post #206

Earlier quoted context omitted.

You don’t have to use implicits though, but you’d be super happy they’re there should you ever be in a situation where they’re helpful

Doesn’t a monad or for comprehension use implicits to find the right CanBuildFrom? Are you suggesting to use scala without using for comprehensions? Or do you mean you don’t need to write your own? It’s been a long time since I wrote scala, so may be getting it wrong.

No it does not. A for-comprehension just requires that map/flatMap methods are available. No implicits or CanBuildFrom needed.

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

#233

Post by valenterry »

kjeetgill wrote: post #222
ernst_klim wrote: post #210

Earlier quoted context omitted.

> I'll start with one (key)word: `implicit` I don't think implicit counts as "too many features" or as something complex. Basically all it does is finding a canonical value in scope for a hole of certain type.

I only worked in Scala briefly so maybe it's coming from Java habits, but implicits were huge pain. When first reading through code you don't really know if that function call you eyed over really has the params you think it does. It makes it WAY harder to track what's derived from what. Either way, the local Scala guru there said the Scala community was starting to get over implicits.

I think that's were it comes from: people that briefly worked with Scala in the past.

At some point it was true, but nowadays the problem is solved because IDEs will show you were an implicit is used and where it comes from. Without that, it was indeed more difficult - but also not more difficult than Java's reflection or DI (where you had and have even less help).

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

#234

Post by valenterry »

pron wrote: post #201
valenterry wrote: post #16

Scala's case classes are missing in the comparison (only mentioned briefly at the very end). They offer everything that records do and more. Good to see that Java finally catches up a bit.

I don't think they offer more. Deconstructing patterns and "reconstructors" (generalised "withers") are on the way. And Java features are often designed as a complete whole: some of the feature is in the language, some in the core libraries, and some, even, in the VM. In the case of records, they're treated in a special way by the runtime (e.g. in serialisation).

Well I said "they offer more" and not "they will always offer more". So I stand by what I said.

> In the case of records, they're treated in a special way by the runtime (e.g. in serialisation).

Scala will use them as underlying implementation (just like it will do with value-types, functions and so on).

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

#235

Post by valenterry »

mumblemumble wrote: post #110
valenterry wrote: post #16

Scala's case classes are missing in the comparison (only mentioned briefly at the very end). They offer everything that records do and more. Good to see that Java finally catches up a bit.

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.

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

#236

Post by valenterry »

kelnos wrote: post #188
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.

My general rule (in Scala) is that if I need a tuple larger than two or three elements, I'm better of writing a case class. Tuples get unreadable real fast. I think tuples are an essential language feature (and it's ridiculous that Java doesn't have them yet), but I think they're often way overused.

My heuristics is much more based on how often the same structure is used and in which places. Sometimes type aliases are a more light way compromise too.

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

#237

Post by johnnycerberus »

jeroenhd wrote: post #133
smoldesu wrote: post #68

This might qualify as low-grade threadjacking, so I apologize if this is off topic, but who's actually using Java these days? Most devs I know avoid it like the plague, and only use it to maintain legacy codebases or get CS qualifications. Are there any real advantages to using Java in 2021, besides it's mature community/ecosystem/tooling?

The existence of Spring Boot makes Java a very good choice for loads of dev shops. Good balance between features, ease of use, performance and security, not difficult to pick up, and very well documented. In my personal opinion, C# is a superior language these days now that most of .NET has been ported into dotnet core. However, that's only been the case for a few years and before that, Java was in a league of its ow…

You forgot about the spaceship called Scala and how many startups are trying to parallel park a spaceship when they just need a Mini. Just to continue your line of analogies. Though, I still like playing with spaceships.

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

#238

Post by valenterry »

The_rationalist wrote: post #65
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.

Nominal !≠ named You can have named tuple members while maintaining structural typing, it's not mutually exclusive.

Did I say something that contradicts that?

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

#239

Post by __jem »

balefrost wrote: post #204
TJSomething wrote: post #196

Earlier quoted context omitted.

In traditional Java, you're probably using Jackson for your JSON. You can achieve those sorts of results by specifying the classes and type tags in annotations on an abstract Either class to use Jackson's polymorphic serialization feature.

The point of sealed classes is that you have a known number of possible representations. So you can have `when` blocks that exhaustively check all possibilities. Having an open class hierarchy would not work for that purpose.

this technique works with sealed classes, i’ve done it before. it throws a runtime exception if it can’t identify the discriminant.

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

#240

Post by johnnycerberus »

autodidacticon wrote: post #80
smoldesu wrote: post #68

This might qualify as low-grade threadjacking, so I apologize if this is off topic, but who's actually using Java these days? Most devs I know avoid it like the plague, and only use it to maintain legacy codebases or get CS qualifications. Are there any real advantages to using Java in 2021, besides it's mature community/ecosystem/tooling?

It would seem that the world of data engineering is largely dominated by Java.

I share the same view, based on the jobs in my area, everyone is using Python to prototype and Java/Scala to productionize, I've also seen Node.js increasingly being used, probably for things that are I/O-intensive and not compute-bounded. Rust could change the landscape for Node/Deno, critical code which is memory/cpu-intensive could be exported to a WASM library or an external dependency that can be called through FFI (though that would be very slow and you introduce the 2-language problem that Julia is trying to fix for Python). Anyway, even if we are in a way better state today than, let's say, 5 years ago when it comes to picking tools for data engineering, I strongly believe that JVM is here to say for a long, long time.
Post reply on HN