Zig's new bitCast semantics and LLVM back end improvements • Hacker News Board

Re: Zig's new bitCast semantics and LLVM back end improvements

#111

Post by shakna » Fri, Jun 26, 2026, 5:16 AM UTC

KingMob wrote: post #108

piker wrote: post #67

Earlier quoted context omitted.

It's so interesting to read comments like this and contrast them with the "don't read the code" type of vibes out right now. It feels like half of the developer world is optimizing low-level struct packing and the other half is YOLO'ing 300 KLOC Electron apps. Very confusing.

I think it makes sense, if one sees that LLMs exposed various pre-existing splits in the developer world. Those who viewed code as a means to build something else, are happy to switch to LLMs if they can build that something faster/cheaper. Whereas, those who liked coding for its own sake, don't want to use LLMs, and fear for their jobs and their happiness. Unfortunately for the latter group, we're moving to a world…

I used to be paid to go in and fix messes of code, created by juniors who were forced to build things they didn't understand.

Now I get to fix things created by managers who enjoyed building things they still don't understand.

Re: Zig's new bitCast semantics and LLVM back end improvements

#112

Post by audunw » Fri, Jun 26, 2026, 5:16 AM UTC

ozgrakkurt wrote: post #9

> Consider, for instance, bitcasting a [2]u8 to a u16. Under the old semantics, the result of this operation depends on the target endian: on big-endian targets, the first array element became the 8 most significant bits, whereas on little-endian targets, the first array element became the 8 least significant bits. Under the new semantics, because we only care about logical bit representation (which is endian-agnosti…

I may be damaged from working on IC hardware design and various weird architectures, but I truly can’t comprehend why you’d think this doesn’t make sense.

Yeah, if your architecture doesn’t support 24-bit int it maps to 32-bits. But it also declares that the numbers you’re storing should never be larger than 2^24. It’s about type safety, and also run time checks in safe mode I believe. Bitcasting three bytes to a 24-bit type makes just as much sanse as casting 4 bytes to 32-bit. Theres zero reasons to introduce arbitrary artificial constraints on what you can do based on details of (most of) the underlying architectures, which doesn’t even matter for the operation you’re performing.

Re: Zig's new bitCast semantics and LLVM back end improvements

#113

Post by gnubison » Fri, Jun 26, 2026, 5:17 AM UTC

Someone wrote: post #105

FTA: “Under the new semantics, because we only care about logical bit representation (which is endian-agnostic), the operation behaves identically on every target: the first array element becomes the 8 least significant bits” I wouldn’t call that endian-agnostic. It’s explicitly picking little-endian. It also makes things look weird for beginners. I know how it works, but in the test "bitcast [2]u3 to @Vector(3, u2)"…

The behavior is agnostic of the endianness of the target platform.

Re: Zig's new bitCast semantics and LLVM back end improvements

#114

Post by audunw » Fri, Jun 26, 2026, 5:23 AM UTC

f13f1f1f1 wrote: post #59

epolanski wrote: post #19

OT: I'm always surprised at how popular Zig discussions get here, or Youtube and other medias. Don't get me wrong, I love Zig and I think it's a great C replacement, but I'm very confused on why C3 or Odin rarely get any attention at all, despite being in the same C-replacement crowd. But still surprised at what Zig does better than these other projects? Is Andrew much better at marketing/promoting the language? He's…

Andrew pushes lots of "social issues" so he has that crowd and they push zig as a way of pushing their social views.

I’ve followed Zig fairly closely and this is the first I’ve heard of Andrew pushing “social issues”. I don’t believe for a second that it’s a factor at all.

Re: Zig's new bitCast semantics and LLVM back end improvements

#115

Post by rmunn » Fri, Jun 26, 2026, 5:36 AM UTC

nromiun wrote: post #109

rmunn wrote: post #97

Earlier quoted context omitted.

> ... utf-8 that covers all the languages but excludes the emojis ... Ah, but the U+0000 to U+FFFF plane does not cover all the languages. You might think that only historical and archaic languages are found in Unicode's astral planes (e.g., U+20000 to U+2A6DF is used for historical Chinese characters no longer used today), but in fact there are modern languages found in the U+10000 plane. You might not care about Os…

> You don't lose half a million people from an ethnic group in just ten years without some kind of war or genocide. Nothing happened to the people, they are growing year on year. But languages can die very easily if governments don't put efforts on teaching it to children. That is exactly what happened to the Ho language. There is no advantage on learning these small regional languages so children put their effort on…

I'm familiar with the phenomenon, as my wife is a linguist who did her master's thesis on the phonology of a small language spoken by about 7000 people: many of the kids don't want to learn it, and just want to learn the majority language of the country since that's what they have to use in school. But I didn't think that could be the explanation for a 25% decline in ten years: new people may not be learning the language, but the only way people stop speaking their mother tongue is if they immigrate to a new country and fully adapt to it (happens to a few people, usually who immigrated as children) or if they die (by far the most common reason for language-use decline: the old people are dying and the young people aren't learning it). If the decline was a couple hundred thousand that would be the outside limit of probability, as far as I know.

More likely, in my opinion, is that both are happening: yes, the language is declining, but either the earlier census overcounted speakers (e.g. counting children as speaking it when they weren't actually learning it) or else the later census undercounted speakers; either way the language decline would look larger than it actually is. Given that Ethnologue (https://www.ethnologue.com/language/hoc/) rates the language vitality as "Stable" — "The language is not being sustained by formal institutions, but it is still the norm in the home and community that all children learn and use the language" — and they usually know what they're talking about, I suspect the language decline isn't that fast and a census counting mistake is a more likely explanation for the discrepancy over ten years.

Re: Zig's new bitCast semantics and LLVM back end improvements

#116

Post by rmunn » Fri, Jun 26, 2026, 5:44 AM UTC

nyrikki wrote: post #110

rmunn wrote: post #98

Earlier quoted context omitted.

> ... but almost all of them are historical or emoji's in utf-8. I just posted a comment, five minutes after you wrote that, which I won't repeat here since it was quite long. But one of the languages whose alphabet is found in the higher multilingual plane is Fulani, spoken natively by 37 million people (plus another two and a half million who have learned it as a second language). While it can be written in other a…

To be clear, I was talking about a use case, not all use cases. There are very real times where you have to support all 4 bytes, there are others where other drivers require you to restrict the domain of discorse. It doesn't change the value/cost of bit casting in a language with arbitrary bit width languages, especially when combined with the fact that int overflows are detectable illegal behaviour and you have satu…

Yes, there are certainly use cases where you know the data you're parsing will only come from a narrow range of Unicode, such as U+0000 to U+007F — or from just the letters GCAT, as you mentioned. The overhead of converting 8-bit input to 7-bit might not be worth the cost, but the benefit of storing your input in just 2 bits per "letter" is definitely worth it.

I mostly wanted to make sure people know that the upper multilingual planes are a very real use case, and you need to test them. This is more important for languages such as C# where UTF-16 is the norm: many programmers don't know that they're handling surrogate pairs wrong until someone tries to backspace over an emoji character and it turns into something weird. It's probably less relevant to Zig, which didn't make the mistake that C# and Java did by starting out with UCS-2 (to be fair to them, they were designed in the era where people still thought that 65,536 codepoints would be enough for every language and Unicode would never need more than 16 bits). But the upper planes are important, and need to be tested no matter what language your code is written in.

Re: Zig's new bitCast semantics and LLVM back end improvements

#117

Post by messe » Fri, Jun 26, 2026, 5:44 AM UTC

Someone wrote: post #105

FTA: “Under the new semantics, because we only care about logical bit representation (which is endian-agnostic), the operation behaves identically on every target: the first array element becomes the 8 least significant bits” I wouldn’t call that endian-agnostic. It’s explicitly picking little-endian. It also makes things look weird for beginners. I know how it works, but in the test "bitcast [2]u3 to @Vector(3, u2)"…

That's only because we write numbers in big endian.

Re: Zig's new bitCast semantics and LLVM back end improvements

#118

Post by zenpe » Fri, Jun 26, 2026, 5:49 AM UTC

Someone wrote: post #105

FTA: “Under the new semantics, because we only care about logical bit representation (which is endian-agnostic), the operation behaves identically on every target: the first array element becomes the 8 least significant bits” I wouldn’t call that endian-agnostic. It’s explicitly picking little-endian. It also makes things look weird for beginners. I know how it works, but in the test "bitcast [2]u3 to @Vector(3, u2)"…

[dead]

Re: Zig's new bitCast semantics and LLVM back end improvements

#119

Post by wolvesechoes » Fri, Jun 26, 2026, 6:27 AM UTC

nickmonad wrote: post #24

epolanski wrote: post #19

OT: I'm always surprised at how popular Zig discussions get here, or Youtube and other medias. Don't get me wrong, I love Zig and I think it's a great C replacement, but I'm very confused on why C3 or Odin rarely get any attention at all, despite being in the same C-replacement crowd. But still surprised at what Zig does better than these other projects? Is Andrew much better at marketing/promoting the language? He's…

Andrew doesn't strike me as someone who does any marketing at all. He just wants to make the language he wants to use, and does it well. Sometimes its just right time, right place. But also, Zig has received attention via projects like Ghostty, TigerBeetle, and Bun (prior to rewrite of course)

Successful marketing is like successful propaganda - it cannot look like it.

Re: Zig's new bitCast semantics and LLVM back end improvements

#120

Post by wolvesechoes » Fri, Jun 26, 2026, 6:29 AM UTC

epolanski wrote: post #19

OT: I'm always surprised at how popular Zig discussions get here, or Youtube and other medias. Don't get me wrong, I love Zig and I think it's a great C replacement, but I'm very confused on why C3 or Odin rarely get any attention at all, despite being in the same C-replacement crowd. But still surprised at what Zig does better than these other projects? Is Andrew much better at marketing/promoting the language? He's…

> Don't get me wrong, I love Zig and I think it's a great C replacement, but I'm very confused on why C3 or Odin rarely get any attention at all, despite being in the same C-replacement crowd.

Doesn't matter as neither will see significant adoption.