7 ms·
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 Ja
by valenterry 6y ago
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.
- halfmatthalfcat 6y agoScala is usually omitted for one reason or another when Kotlin is compared against Java as a better alternative, which is a shame.
- aero142 6y agoScala has to the solution to every problem except the problem of too many features.
- AzzieElbab 6y agoMaybe but scalas case classes are super easy to grasp and require no magic like annotations
- xenomachina 6y agoWhat annotations are you referring to?
- scubbo 6y agoI'm not the person you were asking, but, presumably, Lombok's annotations.
- AzzieElbab 6y agoLomboks. Seriously, scala case classes are like the very first thing people start using when learning the language. Scala3 enums are even more straightforward
- xenomachina 6y agoThe ancestors of your comment mention Kotlin, not Lombok, which is why I asked. Kotlin's data classes are probably the analog to Scala's case classes, and they do not require annotations.
- ernst_klim 6y ago> 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 are examples of that.
- kerblang 6y ago> 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.
- ernst_klim 6y ago> 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.
- kjeetgill 6y agoI 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.
- valenterry 6y agoI 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).
- adambatkin 6y agoLombok and Kotlin are both much easier to integrate into existing Java applications and libraries than Scala.
- krzyk 6y agoLombok is the problem not a solution (see https://github.com/projectlombok/lombok/issues/2681 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.
- gher-shyu3i 5y agoIt's been resolved though.
- kelnos 6y agoI 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 learn, sure, that might be the case (I really don't know), but that's not really an integration task.
- throwpupper 6y agoWhat about the fact that Kotlin collections are fully interoperable with Java collection? That makes the transition significantly easier.
- halfmatthalfcat 6y agoI believe Scala's are as well, this seems to be a pretty complete list: https://www.scala-lang.org/api/2.13.5/scala/jdk/javaapi/CollectionConverters$.html https://www.scala-lang.org/api/2.13.5/scala/jdk/javaapi/Coll...
- MichaelMoser123 6y agoi think Kotlin might be winning over Scala because of better ineroperability with java. https://jelmini.dev/post/java-interoperability-kotlin-vs-scala/ https://jelmini.dev/post/java-interoperability-kotlin-vs-sca...
- mumblemumble 6y agoI 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.
- valenterry 6y agoNot 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.
- snuxoll 6y agoThe 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.
- valenterry 6y agoYes, that's correct. But instead of catching the error at that point, you would probably rather want to disable these methods from the beginning so that someone cannot even make the mistake of using them and has to go through some custom defined method instead.
- jillesvangurp 6y agoA good rule is that constructors MUST not do work. Writing constructors in Kotlin is possible but not that common. Data classes are typically initialized with just value assignments. Having support for default values also means that it largely removes the need for having multiple constructors (which is very common in Java). If you need to do validation, there are very decent frameworks that you should use for both Java and Kotlin. We are using a thing called Konform currently. Very nice. For non negative numbers, you can use the new unsigned numeric types they added in Kotlin with the last release: https://kotlinlang.org/docs/basic-types.html#unsigned-integers https://kotlinlang.org/docs/basic-types.html#unsigned-intege...
- pron 6y agoI 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).
- valenterry 6y agoWell 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).