11 ms·
Zig's new bitCast semantics and LLVM back end improvements
- grayhatter 3mo ago> Quite long devlog coming up, apologies—I got a little carried away with this one! mlugg, please don't apologize for creating something I actually want to read. I'm drowning in low effort garbage, the in depth technical explanation is a refreshing breath of fresh air. Might as well apologize for creating a language without a garbage collector, sure most people are unwilling to think, but some of us like nice things and are actually willing to apply effort.
- jeffbee 3mo agoIt wasn't even long! It seemed much shorter than the typical LLM-expanded drivel that crosses the HN front page daily.
- frail_figure 3mo ago[flagged]
- deleted 3mo ago[deleted]
- grayhatter 3mo ago??
- ryan_n 3mo agoThink theyre just implying that the quoted text comes off as a bit pretentious..
- grayhatter 3mo agooh, I think it's mostly frustration over how eager everyone is to delegate their thinking to literally anything else, accelerated by [gestures at reality]. Is frustration with apathy really pretentious?
- mlugg 3mo agoI appreciate the kind words :)
- grayhatter 3mo agoBAH! and I forgot to say the most important part. Much more important, thanks for not just the devlog, and explaining the changes. But also; thanks for fixing/improving this! I appreciate all the work you've put in, I really enjoy watching the the language I like constantly improve.
- scuff3d 3mo agoWhy I've moved more to a couple of language/software dev discords and away from Hacker News. Way too much uninteresting AI nonsense on here for a while now.
- ind-igo 3mo agoWould like to join as well if you're willing to share
- scuff3d 3mo agoUsually I bounce between the Zig and Odin discords, as well as the Handmade Network discord.
- baranul 3mo agoThat and the continual pushing of Zig and Rust to ridiculous levels, like HN had investments in them or were getting payouts, and as if few to no other programming languages exist.
- simonask 3mo agoInteresting read, even as someone who isn't using Zig. I wonder, these arbitrary-width integers... Is it actually even really worth it? My intuition is to prefer manually packing/unpacking things instead (in any language, even C that has bit width for struct fields), because it gives me a better mental picture of the code that is actually generated. Particularly for something like an signed odd-bit integer - what kind of code gets generated for sign-extension, a presumably common operation? Does anybody have other experiences with them, one way or the other?
- ismailmaj 3mo agoIt's great for defining fancy floats used in machine learning e.g. https://github.com/zml/zml/blob/33ced8fa078b3c7c8c709bd526ae17f22ed7238f/zml/floats.zig#L281-L284 https://github.com/zml/zml/blob/33ced8fa078b3c7c8c709bd526ae...
- y1n0 3mo agoAs an fpga engineer dealing with bitwidths that are non-byte multiples is very normal and when I end up writing software for various reasons, I often miss it. Usually when trying to slice and parse or construct messages. Obviously there are ways around pretty much everything, but it’s nice to have first class language support for bit slices.
- NooneAtAll3 3mo agoexcept it isn't bit slice, it isn't indexing within a range - it's just integer type that only allows values up to 2^width, with same alignment rounding up as with the rest
- hmry 3mo agoIt's a bit slice if you put it in a packed struct. I like them, they're nicer than C's bitfields: The order isn't implementation-defined, and the types remember their range rather than being converted to a power-of-two size upon read. (Maybe that's possible with C23 _BitInt(n), I haven't tried if those work in bitfields)
- ozgrakkurt 3mo ago> 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-agnostic), the operation behaves identically on every target: This is a huge mistake. You would never expect something like bitCast to do this. I don't understand this approach. Why change something so simple and low level to be complicated and high level? Just don't allow casting to u24, as it makes no sense unless you define u24 to be u32 sized as I think c standard does. I think this approach as an idea is bad but at least just add another built-in that implements this higher level idea to not break a simple expectation and current behavior?
- tialaramex 3mo ago> This is a huge mistake. You would never expect something like bitCast to do this. Is there at least some sort of @transmute or something ? If Zig wants to say "bitCast" means this odd operation, but provides the thing most people actually want under some plausible name that's just an extra thing to learn which seems OK.
- dnautics 3mo ago@intCast
- tialaramex 3mo agoSo, since I don't write Zig I had to go look this up, to save anyone else the bother this is what Rust would call an 'as' cast or C programmers might think of as a value cast, it's going to try to make a value which has a similar meaning but of another type, which may be arbitrarily expensive. What people often want here is a transmute, Rust's core::mem::transmute which changes nothing about the bits except what those bits mean, since the bits didn't change and the machine only has bits anyway this is "free".
- zamadatix 3mo agoThis change + the existing packed struct logic will be great for working with bit packed binary headers w/o having to manually twiddle so much about the bit handling along the way.
- allthetime 3mo agoZig is already great for this with ‘packed struct’ and arbitrary size ints. Allows for very clean protocol creation between systems with known properties. This is another great step in that direction.
- ulbu 3mo agoyou need different packed structs for little- and big-endian data. and casting with little-endian data is a nightmare - you need to reverse-cascade your struct fields to be in accordance with the little-endian bit-pattern. (or have a comptime function that does it for you, of course. but then you lose all declarations for the struct). what should be a simple writing down of a protocol is now a pedantic and error-prone ordeal.
- hrydgard 3mo agoOr you just go ahead and forget that big endian ever existed. It's not coming back.
- ulbu 3mo agoit’s little-endian protocols that require that you juggle your struct fields. plus, there are still big-endian protocols that will stay for a long time. for example, MIDI clip files in MIDI 2.0 are big-endian.
- charcircuit 3mo agoThis has been largely solved by everyone agreeing to use little endian. There aren't really use cases for wanting to convert between them.
- epolanski 3mo agoOT: 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 very hard to dislike.
- nickmonad 3mo agoAndrew 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)
- csb6 3mo agoThey have definitely done a lot of marketing through social media and forums like HN. There have been large numbers of posts here by Zig's developers for years, and a few releases of LLVM even mentioned Zig prominently in their release notes.
- xydone 3mo agoMaybe people just like the language
- andyferris 3mo agoI believe I read a post by Andrew detailing how he intentionally did marketting in a way to attract users, the right contributers, and donations - he was quite intentional about making his full-time role sustainable (and now more roles).
- wolvesechoes 3mo agoSuccessful marketing is like successful propaganda - it cannot look like it.
- 3mo ago
- deleted 3mo ago[deleted]
- QuaternionsBhop 3mo agoIs pasting em-dashes everywhere some kind of inside joke?
- mlugg 3mo agoUh, no? My writing style just happens to include a lot of em-dashes, as is very common. And it's not like I'm pasting a weird Unicode codepoint all over the place, that's just (rightly) how my Markdown gets rendered...
- tomjakubowski 3mo agoMacintoshes have had mnemonic keyboard shortcuts for inserting en- and em-dashes since forever: option-hyphen and option-shift-hyphen. They've been in my digital repertoire since I first switched to a Mac around 2004.
- yellowapple 3mo agoI pity the fools who don't have compose keys for all their em—dash and “smart quote” needs.
- _flux 3mo agoYou too could have it easily accessible on your keyboard by using EurKEY: https://eurkey.steffen.bruentjen.eu/ https://eurkey.steffen.bruentjen.eu/
- fithisux 3mo agoThese posts make you want not only to use Zig, but also to marry it. No jokes aside, these posts are the best advertisements of the language. And I truly like their AI stance.
- Someone 3mo agoFTA: “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)" example, turning two 3-bit values [abc def] into three 2-bit values [bc fa de] is way less intuitive than turning it into [ab cd ef].
- teo_zero 3mo agoCan I convert a 300-byte message to Base64 with a single instruction? Like: in: [300]u8; out: [800]u3; out = @bitCast(in);
- mlugg 3mo ago`u3` would be base 8, i.e. octal---I think you meant to use `[400]u6`? Aside from that: I'm not familiar with how standard base64 deals with endianness, so I'm not sure if it would match that, but this `@bitCast` would certainly give you a base64 encoding. But it would probably emit pretty terrible code to do that---our lowering of `@bitCast` isn't really optimized for moving around huge amounts of data in one operation! (But maybe LLVM would surprise me.)
- teo_zero 3mo ago> I think you meant to use [400]u6 Of course! I guess it was too early to do the maths correctly... :)
- valentynkit 3mo ago[flagged]
- blinkingled 3mo agoWriting linkers must be incredibly rewarding - go has its own, there's mold, there's LLD, there's the OG GNU bfd LD and now Zig has one too! I am sure there's a Rust one too - Wild! Every one of them is faster than the others too lol! Mold for one tries really hard to be GNU ld and to be useful as an independent linker most have to - I guess Zig/Go ones are purpose built so at least those don't duplicate GNU ld compatibility.
- usrnm 3mo agoWait till you hear how many programming languages there are
- infogulch 3mo agoSure, but one might imagine that linkers are generic and reusable, so you can just pick one off the shelf instead of making a new one 1-1 for each language. Empirically this line of reasoning seems to be incorrect.
- blinkingled 3mo agoDifferent programming languages are very obviously not the same thing - different cp command implementations are similar conceptually to having different linker implementations that all do the same thing. But you knew that so not sure if there was a point you were trying to make there.
- usrnm 3mo ago> Different programming languages are very obviously not the same thing It isn't obvious to me at all. The difference between Java, C# and Go is about as important as the difference between Makita and Bosch for power tools. Yes, some people swear by one or the other, but by the end of the day it really doesn't matter
- listeria 3mo agoWhen I first found out about bit fields in C, I was left wondering what the order of bits was in a byte, eventually I convinced myself it doesn't matter, since the byte is the smallest I/O unit, and lived with the fact that casting between bitfields and bytes was UB (or unspecified, I can't remember), and as such, was another thing I wasn't suppossed to do when writing C. All this to say that Zig just keeps cleaning up and giving well-defined semantics to warts I learned to live with in C.