261–270 of 464 posts
Scalarization can fail in surprising ways just due to what a maximal atomic write can be on the target platform, and then it fall back to heap allocated objects.
Even if there's type erasure.
I much rather have the compiler balk at me than let me write something that may or may not work as expected.
> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap. How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit repre…
> No headers per element. No pointers. No jumping around the heap. that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it. [1] https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...
It stopped being infuriatingly sloppy and took time to ensure the article had integrity.
It did having said that I did burn through a lot of tokens trying to do a deep analysis cross data pipeline debug.
Earlier quoted context omitted.
Go was chosen mainly because it aligned more with how the existing compiler is designed. They did not want to redesign the compiler which eliminated C# as a choice. So Go is apparently just a better fit for quickly porting JavaScript code to.
That was the original motivation yes, although they acknowledged later that the weaker type system from Go required redesigning the data structures anyway. And as proven in the recent announcement, they had to rewrite parcel from C++ into Go, as they didn't found a comparable library in Go ecosystem. There is also another interview, where again they mention having used AI as tool for code rewriting as well. Also to n…
> Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one.
It's been working fine for a few years now. The only problem I know is there is little to no reflection allowed (by design) so a lot of code out there is not compatible with it yet. Not sure if that's what turned the TypeScript team away from it.
> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap. How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit repre…
> No headers per element. No pointers. No jumping around the heap. that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it. [1] https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...
Earlier quoted context omitted.
I'm tired of people jumping in to point out "AI, AI". The article is very good and informative. That is the only important thing. Geez.
No, it’s not the only important thing. The complaints about it should tell you that. People care about provenance a lot. Whether it’s a drawing my daughter did of her mother, a Picasso napkin sketch, a worn 1960s Stratocaster, or an blog essay, the provenance is value on top of the correctness of the item.
> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap. How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit repre…
18446744073709551616 possible values and you can't spare 1 for null? :) TIL that Rust has NonZeroU64 which you can combine with Optional to get the required behaviour with only 64 bits per entry. [1] [1] https://doc.rust-lang.org/std/num/type.NonZeroU64.html
Earlier quoted context omitted.
Embedded systems? Like sim cards? There's even real time Java, I think they used it for some missile guidance stuff aswell at some point
> Embedded systems? Like sim cards? Serious question: I remember the old installer, six billion devices or whatever. I’ve heard about Java ME, old set-top boxes and DVD players, etc. But how much of that is active today. I can’t say I’ve ever seen a job listing for an embedded Java developer or even Java ME in my entire career. Are people actually still using it?
Earlier quoted context omitted.
The obviously used too much AI, I stopped after 2 paragraphs
The first two paragraphs are > On June 15, Oracle engineer Lois Foltan confirmed what a good chunk of the industry had stopped believing: JEP 401: Value Classes and Objects will be integrated into the main OpenJDK repository and is targeting JDK 28. > The change is so large that the remaining committers were asked to hold off on bigger commits during the integration. The pull request alone adds over 197 thousand line…
« The pull request alone adds over 197 thousand lines of code across 1,816 files. »
I noticed that both Claude and GPT are fond of those kind of stupid accounting statements that don’t mean a lot in and of themselves, but look impressive in a « wow numbers » way. Which is kind of ironic since counting remains one of their weak points
Earlier quoted context omitted.
The whole point of using Optional/Maybe is to prevent the possibility of accidemtally creating nulls. If you don't make mistakes, then nullability is not a problem. If you do make mistakes, then a class that only helps when you don't make mistakes is basically useless. This also has significant impact for serialization/de serialization - a classic place where you get unexpected nulls, that Java Optional/Maybe don't h…
Since they plan to have null-restricted types, then I don't see any issue.
Well wasn't that the argument above, that the stuff they added so far isn't proper at least in part because they didn't fix that problem yet?
Earlier quoted context omitted.
> No headers per element. No pointers. No jumping around the heap. that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it. [1] https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...
You see this in all the AI generated Tik Toks. What causes AI to use such a weird construction.