61–70 of 185 posts
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.
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 think Temporal API added in latest preview version of safari.
https://webkit.org/blog/18182/release-notes-for-safari-techn...
Earlier quoted context omitted.
Is there a theoretical reason why they can’t? As a layman I would assume nothing is preventing it, other than the large amount of effort it would take to implement.
From what I gathered the core problem is flattenability. It is backed by a dynamic array and you would need real templating to remove the indirection.
2934 commits OMG... huge work.
Yes, massive respect for that type of perseverance on long term, important changes.
Also, now on the Java side: I think they made a great job avoiding async/await and using virtual threads. Amazing results.
I also like all the work done around structured concurrency.
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 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.
I used to love Java mostly for its batteries-included well designed standard library. Despite the verbosity of the language itself. But over time the language has really evolved a lot and gotten a lot more pleasing to the eye (in my opinion).
But nowadays I see the language improved a lot, avoided async/await and added virtual threads, added records, now Valhalla, decent lambdas and tons of quality of life improvements.
In the meantime C# became a monster of 2000 ways to declare properties init get, set, backed, not backed, stackalloc, structs, etc.
And I know it is done for performance: but Java is still you have a value type or a reference type. That simple. And now, on top of it Valhalla.
I think Java stayed overall more stable and simple.
C# is still pretty good, but it is just more complicated.
Earlier quoted context omitted.
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…
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.
"std::allocator is to allocation what std::vector is to vexation".
There was another transparency inside:
"std::allocator is to allocation what alligator is to allegation".
Earlier quoted context omitted.
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.
Not for atomic writes, which is the important bit here. When dealing with concurrency the choice to make us will you allow tears when writing i.e. thread A writes aa and thread B writes bb. Will you allow the option of seeing ab or ba or only aa/bb. This is the thing that costs performance. Plus do you allow null which makes it harder too.
Probably still not widespread enough for OpenJDK to unconditionally assume it's supported, but I think we're getting there. (Is there "caniuse" for CPU features?)
Earlier quoted context omitted.
I personally would never compare the two. Someone said: java to JavaScript is like car to carpet. And I completely agree with that.
> Someone said: java to JavaScript is like car to carpet. You mean the sibling who commented five minutes before you?
https://www.keycdn.com/support/difference-between-java-and-j...