Hacker News Reader

Comment by rf15 | Hacker News Reader

Functionally they don't - java is just catching up with (by now) ancient practice.

The false dichotomy of

> A struct in C# has identity and mutation, so the semantics of copying on assignment or passing have to be precisely defined, which gives a heavier model for the programmer and less freedom for the runtime.

Doesn't really match with what they're describing. While yes, it will not have identity in a java class ref sense, it of course will still have identity in being a unique structure in memory at a certain address. This is just splitting hairs about Java nomenclature.

View on HN

> it of course will still have identity in being a unique structure in memory

No, it will not. The design allows multiple objects to share one structure in memory across multiple records, or not have such a structure at all (see Scalarization in the article).

> The design allows multiple objects to share one structure in memory across multiple records, or not have such a structure at all

Yes. I fear you are missing the point.

I don't wanna badmouth Java people, but how they push the idea that this thing is some sort of genuine breakthrough that took multiple PhDs years of cutting-edge research to implement, when in fact they basically copied what .NET did from basically year 1, is not a good look.

Again, not trying to turn this into a .NET vs Java thing, I'd have been much happier if they reached some new and interesting conclusions.

> genuine breakthrough

Well, it is - because they had to make it with almost perfect backwards compatibility for one of the most popular languages with trillions of lines of code produced over decades.

Sure, adding it to a new language is not hard. Adding it to Java which has primitives, generics and boxing, finding ways that seamlessly cover the differences between objects and primitives, while trying to plan for the future is hard.

As a general note, if you come to the conclusion that one of the best designer teams on Earth "basically copied what .NET did from year 1 is not a good look", then maybe your mental model needs adjusting on how these stuff works? Java has a public mailing list, you can browse through the related discussions. Implementation is the least of these things. But I can assure you they most definitely know what they are doing.

> because they had to make it with almost perfect backwards compatibility for one of the most popular languages with trillions of lines of code produced over decades.

At what cost? A key benefit of value types is improved performance but AFAIK Valhalla doesn't even let you pass them by reference. Efficiently passing them through registers is great but won't help you out with larger value types.

idk maybe java should adopt something similar to rust's "edition"?

Correct me if I'm wrong, but Rust editions are a source code-level feature. So given you have the source code of newer and older rust code, you can compile them together.

That's materially distinct from Java's model of basically dynamic loading already compiled class files. Though class files do have "editions", and there are extra code to deal with different versions. But still, it should be possible to e.g. send a new value class to an old library's class that has never heard of them, and that should just work.

The important thing is that Rust editions affect semantics and name resolution. In such an analogy, JVM bytecode is the equivalent of Rust code - various semantics are baked in, but stuff like name resolution isn't (at least not completely).

Except of course they are breaking backwards compatibility, in relatively subtle ways, for anything that uses the standard library wrapper types. So every use of Integer, Boolean , etc is an opportunity for either a compilation error or a runtime bug.

Honestly, if you're relying on `new Integer(999) == new Integer(999)` to be false, you've earned your bug.

>I don't wanna badmouth Java people, but how they push the idea that this thing is some sort of genuine breakthrough that took multiple PhDs years of cutting-edge research to implement, when in fact they basically copied what .NET did from basically year 1, is not a good look.

Oversimplifying a big semantic and backend change to a huge codebase on which some of the most crucial customer and government and business systems depend on, and which has to be made as seamless, correct, and performant as possible, to "they just copied .NET", just because .NET has the same functionality, is an even worse look.

It's a "HN "Dropbox is just rsync + some scripts"-style bad look.

This is exactly what made it so difficult. It is much easier to have a feature like this from year 1 than to add it to a language that has grown and evolved for 18 years already.

I agree with this sentiment. The work they put in deserves a lot of respect, and took a lot of effort, no doubt. It's just the framing they push to the public that could use some work.

The article is shit, the actual concept and roadmap goes well beyond the capabilities of C# or the CLR.

Reply on news.ycombinator.com