> 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 representations? Their `Point` is at least 65 bits (two 32-bit ints plus the null flag). The "plus a possible null flag" and oddly short following statements seem to suggest this was some AI that got sidetracked by trying to make emphatic statements... oh and also the "[IMAGE: the same Point[] array in two variants..." block halfway down the page is unfortunate.
> 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.
Don't be all-in. It's important for humans to be able to write for themselves, and also to stand by what's been written in their name, which is much less likely if someone/something else has done the writing.
I learned that exact style of writing in a marketing workshop, pre-AI. It's effective, satisfying, and a random third thing I can't be bothered to come up with right now.
As a proportion of all easily crawled text on the internet, a lot of it will be random marketing copy. That influenced the writing style of early AIs, and since then everyone has trained at least partially on transcripts from every other AI chatbot
Thank you for sharing this. It brought together things I had suspected but not from his perspective. Also pleasant to read something that used rhetorical devices in a cohesive way instead of just as sprinkled on flavor packets.
There was nothing inadvertent about it. A decade of cultivating and harvesting millions of examples of this kind of pseudo-writing from underpaid internet piece-workers preceded LLMs.
Exactly! But AI is here to stay. Sooner or later, even comments on HN will be 100% AI generated. And we won't be here to read them - our AI agents will. /s
That’s right. Because at some point, the volume of AI-generated posts and comments on sites like Hacker News or Reddit will overwhelm the ability of humans to read them all. So the only reasonable way for humans to participate will be to have our own AI readers summarising them, and posting furiously on our behalf!
I really wanted to read this, it seems like a really interested subject. I can even forgive the AI generated images. But after a few paragraphs it became clear this was either fed through an LLM or worse.
Please, if you write a technical blog, or anything really: Stop. Stop letting the AI write for you. Nobody wants to read this.
Especially because signed integers aren't symmetrical. Reserve INT_MIN and you get 8 billion NaN values and multiplying by -1 always gives you a valid location.
Ah, INT_MIN. If I had a nickel every time I saw an implementation of inttostr/strtoint that don't properly handle it, I'd probably have about $5. So I too thought about possibility of it serving as a NaN of signed integers... but I doubt we'll see it any time soon.
Also, apparently, shifting a negative number to the left is UB in C.
Java has always had this juxtaposition in language design where they don't want you to think hard about value types (hence no unsigned types), but the types themselves are precisely defined down to the specific bit pattern representation in bytecode. This is essentially hardcoded into the JVM and its bytecode specification and is too hard to change for compatibility concerns.
Luckily we have Valhalla, which is an admission that Gosling was partially wrong, and programmers who want to have an unsigned nullable non-zero 64-bit integral value type can just make one, and not have to pay outsized memory costs to do so.
If we're done paying homage to Gosling, can we get operator overloading for our fancy value types please? I have no idea if this is on the radar for Valhalla.
In many cases, NonMaxU64 and NonMinI64 (aka SymmetricI64) would be much more useful though. But Rust is aiming to eventually add a more general way to create types with user-defined ranges, such as the "pattern types" feature currently being prototyped.
> 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 lines of code across 1,816 files.
These days I'm having second thoughts about pictures that I am pretty certain can't be AI but just have that look. It's strange but I've noticed it happening more and more.
I mean I’m only answering that because you’re asking, nothing set me off personally there, but now that you ask:
« 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
Yeah its definitely inconsistent level of specificity. It's "roughly" 197 thousand files, and yet at that scale a human would call it 200 thousand lines of code, and then an exact count of files at 1,816 instead of a similar level of estimation.
For instance I might write this "The pull request alone adds nearly 200 thousand lines of code spanning almost two thousand files", or even better just "The pull request alone adds nearly 200 thousand lines of code" because really who cares how those are broken up into files.
As a human (as far as I know...) there is a decent chance I'd write it like that, depending on the exact numbers.
It said "over 197 thousand". That's what I'd probably say for a number in [197000, 197999], or maybe "under 198 thousand depending on where it is in that range.
Saying "nearly 200 thousand" is still 3 digits so doesn't save any space over 197 or 198, and I think with it only being 3 digits most people will assume only the last digit is rounded. 200 ending in a string of 0s does suggest it might be rounded to the nearest 10 or nearest 100, but it just could easily not be.
I'd almost certainly fully write out 1816. If it were common to spell out groups below 1000 like 100s and were going to that I might write it as something like "just over 18 hundred" or "almost 19 hundred", but I almost never see anyone use grouping sizes of less than 1000.
I understand ai hate but I would rather avoid a future where everybody talks in purposely weird and unstructured sentences to avoid being similar to ai
By necessity a lot of people write very similarly to how llm do
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.
> Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit representations
In this initial commit. As was made clear in the JEP, this is just the first deliverable of a huge feature that, like all Java features in recent years, is being delivered piecemeal. Obviously, the point is to flatten larger values (the mechanism is already in the JVM; what remains is exposing the intent of "I allow tearing" in the language).
I'm confused about the 2008 Bloomberg article image in the first slot... right after implying the effort started in 2014. With nothing mentioning anything in there.
Is there a way we can request a "flag as AI garbage" downvote for articles? Or should we just flag them?
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 representations? Their `Point` is at least 65 bits (two 32-bit ints plus the null flag). The "plus a possible null flag" and oddly short following statements seem to suggest this was some AI that got sidetracked by trying to make emphatic statements... oh and also the "[IMAGE: the same Point[] array in two variants..." block halfway down the page is unfortunate.