Java's records, Lombok's data, and Kotlin's data classes • Hacker News Board

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

#291

Post by ernst_klim » Sun, May 09, 2021, 11:05 AM UTC

kjeetgill wrote: post #289

ernst_klim wrote: post #284

Earlier quoted context omitted.

> 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. Yeah, but don't you feel the same pain when using Spring's autowiring? Or python's (or C++ template) default arguments? Or dynamic method dispatching in any OO language, where you don't know what method you actually call? Or late bindings? I don't see how implicits' implicitness is sign…

I mean me personally? I'm very boilerplate tolerant. I'm not a fan of Dependency Injection/Auto Wiring for similar reasons and I've never found wiring boilerplate to be too painful. In fact I'd love even more explicitness and manual wiring for almost everything like disk, network, or even clock access aka passing capabilities! Default params are generally fine since they're hidden on the implementation side but expli…

> I'm not a fan of Dependency Injection/Auto Wiring for similar reasons

I see. My point was that such things are pretty common in most contemporary languages and I don't see how Scala is special in this regard.

Yes, unlike Go or Java, implicits are part of the language spec and not some metaprogramming magic on top of it, but I'm not sure it's a bad thing.

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

#292

Post by joshlemer » Sun, May 09, 2021, 8:50 PM UTC

valenterry wrote: post #290

joshlemer wrote: post #285

Earlier quoted context omitted.

Except Kotlin enjoys the compatibility with Java, plus it outfits those java collections with extension methods and some compiler tricks to achieve all the same functionality as the Scala collections (in fact, I would say even more self-consistent and useably than in Scala). Just as in Scala, in Kotlin you can use functional transforations that Scala users are so accustomed to: Kotlin: listOf(1,2,3,4) .map{i -> i + 1…

> The only think missing is persistent immutable collections, which are implemented in kotlinx. You said: > You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc. So how does kotlinx achieve zero-cost compatibility with Java collections without having something like `.asKotlin` and `.asJava`? Because otherwise there is no difference between Scal…

because the persistentList/Collection/etc in kotlinx implement the appropriate java collection interfaces:

    import java.util.List;

    public class Foo {
        public static void blah(List list) {
        }
    }

Kotlin:

    import kotlinx.collections.immutable.persistentListOf

    fun main(): Unit {
        Foo.blah(persistentListOf(1,2,3))
    }

This compiles fine

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

#293

Post by esarbe » Tue, May 11, 2021, 7:40 PM UTC

joshlemer wrote: post #279

esarbe wrote: post #274

Earlier quoted context omitted.

It's only a problem if you can't decide which part of your project to write with which language. If I have to use Java, I put it into a separate sub-project and make sure that I have a nice API to interface between the subprojects. `.asJava` and `.asScala` then only appear at very specific places where the interop happens.

What you're describing is in and of itself a severe cost and barrier to the very thing we're describing: interoperability between Java and Scala collections. On the one hand you have Scala where you either have to constantly `.asScala` and `.asJava`, or go your route of ensuring that in any given module only deals with either Scala or Java collections. This may involve additional abstractions or classes to achieve. O…

> Or an other way of saying it is that your approach of walling off modules as either java-collection or scala-collection is kind of like saying "Java and Scala collections work well together, so long as you don't have to use them together too much. If you minimize how much they need to interoperate, the problem is not so bad."

Yes, that's actually a very good way to rephrase it. That being said; I myself wouldn't limit that to just the collections; Java and Scala on the language level have excellent interop. For Scala-the-ecosystem the story is a bit different.

Java is not the primary target for most of the Scala libraries. Not even a secondary one, I dare say. (I'm not even sure how you would model a Java API for a library - say; Cats - that uses implicits for the heavy lifting.)

That of course stems for the fact that Scala makes use of concepts that have no correspondence in neither Java or Kotlin, so there will necessarily be something lost in translation.

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

#294

Post by gher-shyu3i » Thu, May 20, 2021, 2:57 PM UTC

krzyk wrote: post #158

adambatkin wrote: post #111

Earlier quoted context omitted.

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

Lombok is the problem not a solution (see https://github.com/projectlombok/lombok/issues/2681 regarding support for JDK 16 to understand why) and a ticking time bomb in every project that wants to move past JDK 15/16. But why do you think Kotlin is easier to integrate than Scala? Both work on JVM.

It's been resolved though.