7 ms·

Why wasn't this included in the initial records implementation? I tried records and quickly gave up after realizing there was no copy method. There's plenty of

by eweise 3y ago

Why wasn't this included in the initial records implementation? I tried records and quickly gave up after realizing there was no copy method. There's plenty of prior art. Scala has had this for twenty years. Java needs to stop shipping features that don't work as well as in other languages.

pjmlp 3y ago
One step at a time, that is why. Scala is also on the edge of turning into Coffee Script, its relevance wanning. 20 years is pushing it, by the way.
- eweise 3y ago
  Oh yes, 18 years. Guess that's not enough time. And yes, Scala's relevance is waining but not sure what that has to do with this topic. Kotlin also has a copy method if you need an example of a language doing well.
  - pjmlp 3y ago
    Kotlin is only doing well on Android, because mama Google tells so to all the kids targeting Android that they have to eat Kotlin no matter what. Java is doing quite well on the Java Virtual Machine, it isn't going anywhere for not adopting every feature from Beanshell, Groovy, jTcl, jython, Frege, Ruby, Scala, Kotlin, and whatever else comes that needs to implement on top of Java to exist in first place.
    - eweise 3y ago
      No need to get defensive about Java. I developed with it for over 20 years. But personally, I left it because I find it too painful to code in. Every once in a while I try the latest version and it continues to disappoint, records are a good example. I've also been working in fintech for the past 7 years and the companies I worked for, don't want to use Java. Its either been Kotlin/Spring because the syntax is much nicer, or Go because it doesn't have all the JVM baggage. Maybe Java is still really popular but fortunately, its also easy to avoid now.
      - pjmlp 3y ago
        If they are doing Kotlin/Spring, they are using Java no matter what. It is like using Web and avoiding JavaScript, or UNIX and avoiding C/C++. Sure it is possible to pretend it isn't there, until one needs to do serious stuff that requires understanding the platform and its ecosystem. By the way, once upon a time Spring was also all hot on Groovy, then it was Scala, now it is Kotlin. There is a certain irony complaining about Java programming language features and them going into Go, the epitome of programming language design.
- marwis 3y ago
  The problem with this approach is that in the mean time the people will have to adopt crutches like https://github.com/Randgalt/record-builder https://github.com/Randgalt/record-builder and by the time Java adds missing features all the codebases will be forever polluted with legacy workarounds that nobody will dare to remove because of backwards compatibility. It also hinders adoption of new features as people will prefer to maintain consistency in their codebases.
  - pjmlp 3y ago
    Some people, I never liked such kind of crutches. Stuff like Lombok are persona non grata when coding in Java, other than when imposed on us via 3rd parties without alternatives.
    - marwis 3y ago
      Well this isn't really like Lombok since it doesn't hack compiler internals but just generates some code using very standard annotation processor. The alternative is to write this code by hand which isn't any better.
  - davidalayachew 3y ago
    I think you have correctly identified the cost of aiming for long term, evergreen success -- you must sacrifice short term gain to get it. Yes, because records are still slowly being improved, it means that people will put together workarounds and temporary solutions so that they can get their desired feature as soon as possible. It also means that some will just throw up their hands in frustration and say "It's half-baked!", then disregard the feature entirely. It's a tradeoff that the Java team considers on a regular basis. It was a similar tradeoff that led to them releasing Virtual Threads before they had a solution implemented for the pinning problem. That one wasn't so much that they needed feedback before they could fix the problem, but moreso that they didn't want to miss out on potential feedback while they were fixing the pinning problem. So, they released VT with this (temporary) deficiency, and they are working on it now while gathering as much insight as possible into how VT's are being used across the ecosystem. Tradeoffs like this are painful, but they make for a better language. Not to mention, for faster long term progress. A well designed feature becomes easy to extend. A poorly designed one is easy to extend initially, but becomes far more difficult in the long run.
davidalayachew 3y ago
The biggest reason why is because the Java team works as hard as possible to get as much user feedback before putting a feature out there. Part of that means that they will release minimal versions of a feature (records), and then observe how people use them before they start adding the "obvious" Quality-of-Life changes. It's painful for those of us who are here when these features are just now releasing. But the end result is a feature that has less chance of screwing over other potential features. It's best to think of it as a short term cost for a much longer term gain. Moving slow like this means that they will release a feature that is more cohesive than it otherwise could be.

by eweise 3y ago

pjmlp 3y ago

One step at a time, that is why. Scala is also on the edge of turning into Coffee Script, its relevance wanning. 20 years is pushing it, by the way.

eweise 3y ago
Oh yes, 18 years. Guess that's not enough time. And yes, Scala's relevance is waining but not sure what that has to do with this topic. Kotlin also has a copy method if you need an example of a language doing well.
- pjmlp 3y ago
  Kotlin is only doing well on Android, because mama Google tells so to all the kids targeting Android that they have to eat Kotlin no matter what. Java is doing quite well on the Java Virtual Machine, it isn't going anywhere for not adopting every feature from Beanshell, Groovy, jTcl, jython, Frege, Ruby, Scala, Kotlin, and whatever else comes that needs to implement on top of Java to exist in first place.
  - eweise 3y ago
    No need to get defensive about Java. I developed with it for over 20 years. But personally, I left it because I find it too painful to code in. Every once in a while I try the latest version and it continues to disappoint, records are a good example. I've also been working in fintech for the past 7 years and the companies I worked for, don't want to use Java. Its either been Kotlin/Spring because the syntax is much nicer, or Go because it doesn't have all the JVM baggage. Maybe Java is still really popular but fortunately, its also easy to avoid now.
    - pjmlp 3y ago
      If they are doing Kotlin/Spring, they are using Java no matter what. It is like using Web and avoiding JavaScript, or UNIX and avoiding C/C++. Sure it is possible to pretend it isn't there, until one needs to do serious stuff that requires understanding the platform and its ecosystem. By the way, once upon a time Spring was also all hot on Groovy, then it was Scala, now it is Kotlin. There is a certain irony complaining about Java programming language features and them going into Go, the epitome of programming language design.
marwis 3y ago
The problem with this approach is that in the mean time the people will have to adopt crutches like https://github.com/Randgalt/record-builder https://github.com/Randgalt/record-builder and by the time Java adds missing features all the codebases will be forever polluted with legacy workarounds that nobody will dare to remove because of backwards compatibility. It also hinders adoption of new features as people will prefer to maintain consistency in their codebases.
- pjmlp 3y ago
  Some people, I never liked such kind of crutches. Stuff like Lombok are persona non grata when coding in Java, other than when imposed on us via 3rd parties without alternatives.
  - marwis 3y ago
    Well this isn't really like Lombok since it doesn't hack compiler internals but just generates some code using very standard annotation processor. The alternative is to write this code by hand which isn't any better.
- davidalayachew 3y ago
  I think you have correctly identified the cost of aiming for long term, evergreen success -- you must sacrifice short term gain to get it. Yes, because records are still slowly being improved, it means that people will put together workarounds and temporary solutions so that they can get their desired feature as soon as possible. It also means that some will just throw up their hands in frustration and say "It's half-baked!", then disregard the feature entirely. It's a tradeoff that the Java team considers on a regular basis. It was a similar tradeoff that led to them releasing Virtual Threads before they had a solution implemented for the pinning problem. That one wasn't so much that they needed feedback before they could fix the problem, but moreso that they didn't want to miss out on potential feedback while they were fixing the pinning problem. So, they released VT with this (temporary) deficiency, and they are working on it now while gathering as much insight as possible into how VT's are being used across the ecosystem. Tradeoffs like this are painful, but they make for a better language. Not to mention, for faster long term progress. A well designed feature becomes easy to extend. A poorly designed one is easy to extend initially, but becomes far more difficult in the long run.

davidalayachew 3y ago

The biggest reason why is because the Java team works as hard as possible to get as much user feedback before putting a feature out there. Part of that means that they will release minimal versions of a feature (records), and then observe how people use them before they start adding the "obvious" Quality-of-Life changes. It's painful for those of us who are here when these features are just now releasing. But the end result is a feature that has less chance of screwing over other potential features. It's best to think of it as a short term cost for a much longer term gain. Moving slow like this means that they will release a feature that is more cohesive than it otherwise could be.