111–120 of 294 posts
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.
Scala is usually omitted for one reason or another when Kotlin is compared against Java as a better alternative, which is a shame.
Earlier quoted context omitted.
1 million is not a lot. I'd begin by asking myselves "can I afford to chase those pointers?", because maybe you can.
That's a good question to ask when faced with a problem that could be solved that way, but a real answer to the question would be useful too.
I'm not sure what it's taking about for the "with" feature: https://nipafx.dev/java-record-semantics/#with-blocks In Kotlin data classes, it's already implemented (just called copy) https://kotlinlang.org/docs/data-classes.html#copying
It was included because changing data using records (copying it except changing the fields you need to change) is a shitty experience, so rather than showing the code you have to write, they showed you code you may or may not in the future be able to write.
Not sure why immutable data structures have surfaced as something important. Typically you never change fields so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change.
> so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change. I'm not sure if you've debugged much, or inherited any large legacy projects, but knowing it is immutable vs "typically it isn't" is a pretty big distinction in that moment.
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?
Not sure why immutable data structures have surfaced as something important. Typically you never change fields so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change.
"Typically" this means you can never be sure, which is a problem.
Earlier quoted context omitted.
Instead of changing few bytes, now I have to copy hundreds of bytes around and add more stuff for GC to collect. Well, they have to obey Wirth's law, I guess.
Or you know, the JIT will trivially optimize away the old class if it is reassigned to the same variable, as you would use it inside a loop. How do you think the litany of FP languages work? Like Haskell, Scala, Clojure?
Earlier quoted context omitted.
1 million is not a lot. I'd begin by asking myselves "can I afford to chase those pointers?", because maybe you can.
No, because my competitors who are attempting to fill the same orders I am attempting to fill are not chasing pointers.
Earlier quoted context omitted.
If C# didn't exist, we would certainly be a Java shop. Not only because of the ecosystem & tooling, but also because it is a language that has historically proven its ability to model incredibly complex business domains as well as support mission critical workloads without falling over on itself.
How's your experience with C#/.NET been? Does it have an analogous offering to Java's JFR[0] for always-on profiling? [0] https://blogs.oracle.com/javamagazine/java-flight-recorder-a...
Earlier quoted context omitted.
In languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Y…
> go back later and add logic to getting and setting Which, realistically, you're virtually never going to do - at least not often enough to justify the boilerplate and especially in the case of things like "records" which were probably auto-generated from a schema (with obligatory getters and setters) anyway. If you did , you'd end up confusing all of your callers who probably wrote client code presuming that what t…
If you can't guarantee you're not going to break someone else's code by changing:
foo.x to foo.getX();
then you should stick with properties. Now, for staying inside a single package, or a single compiled unit, then what you say is reasonable enough. I'd still prefer to write the getters and setters, though, especially in cases where it's free, like Kotlin.