The very fact that Project Valhalla had to create new opt-in syntax for value classes, in order to get what Go does by default on all its types, is the admission of defeat of a herculean battle of attempting to optimize desite fundamental problems with Java's design.
Value classes won't make criticism outdated, because they don't fix any fundamental problems, they just provide an opt-in feature with significant restrictions.
It will make criticism outdated with regards to “you can’t do X” when you actually can do X. Your argument still doesn’t refute that that Java’s GC’s are leagues ahead of Go’s.
If your argument is that optional syntax is bad, sure, we can do that, but it has nothing to do with GC performance.
My criticism was not "you can't do this" - my criticism was that Java requires an overengineered GC to compensate for its fundamental language flaws that make optimization all but impossible.
Go's GC is nowhere near as complex, and yet it performs much better, because Go decided not to shoot itself in the foot.
I explained in detail why value classes will not outdate this criticism. The syntax is not the point - the point is the very fact that they had to add new syntax means that they couldn't retrofit the semantics into the old syntax. Which means it's nowhere near as general and universal solution as would be required to truly make the criticism outdated - in fact it's quite limited. You can't even modify the fields, which is required for almost every scenario where value classes would be useful. For anything non-trivial, you either need to pay the immutability tax or the GC tax.
> Benchmarks prove otherwise
Well, good luck running the benchmarks on your production servers.
