3 ms·

This 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 han

This 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 4mo ago
Zig 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 4mo ago
  you 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 4mo ago
    Or you just go ahead and forget that big endian ever existed. It's not coming back.
    - ulbu 4mo ago
      it’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 4mo ago
    This has been largely solved by everyone agreeing to use little endian. There aren't really use cases for wanting to convert between them.
    - jstimpfle 4mo ago
      Does that mean there are no file formats thatbuse big endian? And network byte order isn't a thing?
      - teravor 4mo ago
        > there are no file formats thatbuse big endian if someone chooses to do that they own the problems. > network byte order isn't a thing if the network serializes/deserializes for you (kernel primitives) then you don't care what it does. if it doesn't and for some reason you choose to use big endian, again, you own the problem.
        dcrazy 4mo ago
        If someone chooses to load a TIFF or a PSD or an AIFF or…
        teravor 4mo ago
        then you either use an existing C library (the most likely approach) or if you are determined to re-implement it you have to be careful parsing their bytes.
        lkjdsklf 4mo ago
        Network byte order has nothing to do with the kernel and you have to care about it It’s a standard because neither side of the connection knows the endianness of the other side so there must be a standard. That standard is big endian regardless of your architecture or kernel or anything else So any serialization intended go over the network should be big endian
        teravor 4mo ago
        right, so a zig app will just do little endian. in the very unlikely event you have it running on a big endian machine you have to do extra work.
piker 4mo ago
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.
- dtj1123 4mo ago
  I know which kind I want to be.
- dfee 4mo ago
  i think it's perfect: AI allows you to go incredibly deep (you have unlimited access to context to make incredibly impactful surgical changes), or you can go incredibly broad (you have unlimited access to context to tie a mind numbing amount of components together). what shakes out is the middle layer: "infra" between "algorithms" and "product". though, to be fair, the middle layer itself is composed of this same work. so it's fractal, or turtles all the way down.
  - cyclopeanutopia 4mo ago
    And why do you mention AI here at all? These statements are ridiculous, world didn't start last year.
    - dfee 4mo ago
      because i was responding to a comment about it.
- rogerallen 4mo ago
  Same as it ever was.
  - miki123211 4mo ago
    yeah, remember those newfangled fancy Node.js guys who would just copy/paste from Stackoverflow without any understanding? Or the Java guys who wrote bloated apps that wasted CPU cycles on garbage collection instead of writing in C++, like God intended? Or the Fortran / Cobol guys who wrote in those God-damned, wasteful, useless high-level languages, instead of using assembly, like a proper programmer should?

This 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 4mo ago

Zig 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 4mo ago
you 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 4mo ago
  Or you just go ahead and forget that big endian ever existed. It's not coming back.
  - ulbu 4mo ago
    it’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 4mo ago
  This has been largely solved by everyone agreeing to use little endian. There aren't really use cases for wanting to convert between them.
  - jstimpfle 4mo ago
    Does that mean there are no file formats thatbuse big endian? And network byte order isn't a thing?
    - teravor 4mo ago
      > there are no file formats thatbuse big endian if someone chooses to do that they own the problems. > network byte order isn't a thing if the network serializes/deserializes for you (kernel primitives) then you don't care what it does. if it doesn't and for some reason you choose to use big endian, again, you own the problem.
      - dcrazy 4mo ago
        If someone chooses to load a TIFF or a PSD or an AIFF or…
        teravor 4mo ago
        then you either use an existing C library (the most likely approach) or if you are determined to re-implement it you have to be careful parsing their bytes.
      - lkjdsklf 4mo ago
        Network byte order has nothing to do with the kernel and you have to care about it It’s a standard because neither side of the connection knows the endianness of the other side so there must be a standard. That standard is big endian regardless of your architecture or kernel or anything else So any serialization intended go over the network should be big endian
        teravor 4mo ago
        right, so a zig app will just do little endian. in the very unlikely event you have it running on a big endian machine you have to do extra work.

piker 4mo ago

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.

dtj1123 4mo ago
I know which kind I want to be.
dfee 4mo ago
i think it's perfect: AI allows you to go incredibly deep (you have unlimited access to context to make incredibly impactful surgical changes), or you can go incredibly broad (you have unlimited access to context to tie a mind numbing amount of components together). what shakes out is the middle layer: "infra" between "algorithms" and "product". though, to be fair, the middle layer itself is composed of this same work. so it's fractal, or turtles all the way down.
- cyclopeanutopia 4mo ago
  And why do you mention AI here at all? These statements are ridiculous, world didn't start last year.
  - dfee 4mo ago
    because i was responding to a comment about it.
rogerallen 4mo ago
Same as it ever was.
- miki123211 4mo ago
  yeah, remember those newfangled fancy Node.js guys who would just copy/paste from Stackoverflow without any understanding? Or the Java guys who wrote bloated apps that wasted CPU cycles on garbage collection instead of writing in C++, like God intended? Or the Fortran / Cobol guys who wrote in those God-damned, wasteful, useless high-level languages, instead of using assembly, like a proper programmer should?