It's pretty interesting that while both languages still receive new features, Java seems to stay ahead of JavaScript: - Java has long had a modern replacement for Date, while JavaScript's recently standardized Temporal API still isn't supported in Safari. - Java has switch expressions, while JavaScript, despite its Scheme influence, does not. - And now Java is getting value objects, while JavaScript's equivalent tupl…
I personally would never compare the two. Someone said: java to JavaScript is like car to carpet. And I completely agree with that.
I feel lonely in that: I mostly love Java as a language. The lack of value types is the biggest impediment to certain types of performance. I am really looking forward to this evolution of the language.
java the language is amazing the problem with it is entirely cultural. why is `IStatusChangeEntityCreationManagerFactory` everywhere? and why are the frameworks so huge and all encompassing? i think batteries included rails-style frameworks are great, but when i wrote Java, it didn't feel like rails at all none of these are language problems
I know and like Java for almost 30 years now. It is amazing how carefully the language is beeing refined. For the cultural aspect, yes, that is sadly true, but I have the feeling that the culture changes. More and more developers realize that there is a better way now (e. g. records instead of dumb classes full of getters and setters). Maybe the main problem is bloated frameworks and their stickyness. The Helidon framework, for example, is a breath of fresh air compared to Spring. Go developers complaining about huge Java frameworks and boilplate could be happy with it.
If I understand this correctly then Integer becomes a value class and every instance of it loses its object identity. I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me.
As far as I understood this (plus future work) will make value classes work more like structs meaning it will save memory and align memory better for things like gRPC, etc.
That's great, even though specialized generics are still missing. I think these improvements will be especially beneficial for Scala, because it is such a powerful language, but abstracting on the JVM comes at a heavy price.
java the language is amazing the problem with it is entirely cultural. why is `IStatusChangeEntityCreationManagerFactory` everywhere? and why are the frameworks so huge and all encompassing? i think batteries included rails-style frameworks are great, but when i wrote Java, it didn't feel like rails at all none of these are language problems
I know and like Java for almost 30 years now. It is amazing how carefully the language is beeing refined. For the cultural aspect, yes, that is sadly true, but I have the feeling that the culture changes. More and more developers realize that there is a better way now (e. g. records instead of dumb classes full of getters and setters). Maybe the main problem is bloated frameworks and their stickyness. The Helidon fra…
+1 for Helidon (https://helidon.io/) - such a great framework, especially the SE variant. Powerful, modern, fast, modularised, and easy to understand.
I'm back on Spring for work reasons but use it for all my side-projects.
Unless CPU instructions become widespread that allow to process 128 bits in one step, then yes. Java will have the same limitations as any other language. Other languages simply don't make this explicit.
I don’t understand this comment - the .NET CLR supports arbitrarily large value types. Are you referring to something like “atomic flattening of those types” instead? Because the CLR doesn’t guarantee that, and therefore supports flattening.
You can opt out of atomicity and make your type tearable, achiving the same performance as on any other platform.
This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.
Unless CPU instructions become widespread that allow to process 128 bits in one step, then yes. Java will have the same limitations as any other language. Other languages simply don't make this explicit.
We've had MMX for a while now, I don't think we need to wait much longer. I don't really see why you would need specific hardware to express a type in a programming language, though.
It's about the semantic guarantees because you don't want to introduce a parallel programming bug just because you added a field to a type. Tearability is opt in and if you are serious about performance you will make the correct choice.
Unless CPU instructions become widespread that allow to process 128 bits in one step, then yes. Java will have the same limitations as any other language. Other languages simply don't make this explicit.
IIUC value objects can have any size, it's just that 'reference flattening' requires the object to fit into a machine word. But this is only due to how Java represents object references and its atomicity guarantees. Naturally, a language that properly supports value semantics does not have any of these limitations.
Java has the mantra of "Integrity by default" which means you can tear into non-integral value type with a flag.
This is the strength of Valhalla. Instead of a binary object/value choice you have different levels of semantic guarantees that will give you better performance characteristics, depending on what your type will be able to give up.
You can have tearability for a complex/quaternion number without problem. But if you have something such as a Range-type class, that gets more problematic because cross-field constraints can be violated.