I object to the "late" argument made by etho's parent. The difference in time to destination will inevitably be dominated by lights, in city travel, not by modest speed differences (say 45 vs 55) on a highway. Being safe & out of the way is the trick! It would be nice if we got rid of left & u turns and build our roads for that!

45 vs. 55 is not modest; that's 5 minutes over only 20 miles. Up around 60 vs. 70 is where it becomes "modest" IMO.

So, 3 stoplights worth of time?

Or 0.1 of billable hours, which for many people here is at least enough to pay for lunch.

I don't know code examples, but this tracks, for me. Anytime I have an agent write something "obvious" and crazy hard -- say a new compiler for a new language? Golden. I ask it to write a fairly simple stack invariant version of an old algorithm using a novel representation (topology) using a novel construction (free module) ... zip. It's 200loc, and after 20+ attempts, I've given up.

GPT likes to argue, and most of its arguments are straw man arguments, usually conflating priors. It's ... exhausting; akin to arguing on the internet. (What am I even saying, here!?) Claude's a lot less of that. I don't know if tracks discussion/conversation better; but, for damn sure, it's got way less verbal diarrhea than GPT.

Yes, GPT5-series thinking models are extremely pedantic and tedious. Any conversation with them is derailed because they start nitpicking something random.

But Codex/5.2 was substantially more effective than Claude at debugging complex C++ bugs until around Fall, when I was writing a lot more code.

I find Gemini 3 useless. It has regressed on hallucinations from Gemini 2.5, to the point where its output is no better than a random token stream despite all its benchmark outperformance. I would use Gemini 2.5 to help write papers and all, can't see to use Gemini 3 for anything. Gemini CLI also is very non-compliant and crazy.

It's a constant stream of makeup & dogs. I just stick to Michael Penn on YT.

So... every company only hires the best!? I jest, I jest!

In general, I've found that the younger engineers (20s, up to 30s) have a lot of vim & vigor; but, even the very best ones generally do a lot of spinning-in-place, when they think they're making progress. Almost anyone above a certain level -- call it the 30–40% mark (it's low!) -- can be raised up to be a competent engineer. Probably what'd be called an "an A- or B+" player? That's just part of a good training & onboarding regime; although, it can take 1-3 years, depending on the person. Very good "natural" talent can definitely boost top performance to an A+, but it won't substitute for literal time-under-stress of delivering high quality product-ready code to clients.

Our least tasty crop!

I know this is a bit cursed; but, I always wanted a bitfield-on-steroids construct:

    struct Dang : bits 64    // 64 bits wide, int total
    {
        foo : bits 5 @ 0;    // 5 bits wide at bit offset 0
        bar : bits 5 @ 0;
        baz : bits 16 @ 4;   // 16 bits wide at bit offset 4
        tom : bits 11 @ 32;
    };

It is a bit cursed, but you can do this in C/C++.

https://godbolt.org/z/vPKEdnjan

    union Dang
    {   
        uint64_t : 64; // set total width
        uint8_t foo : 5;
        uint8_t bar : 5;
        struct __attribute__((packed)) {
            uint8_t : 4;
            uint16_t baz : 16;
        };
        struct __attribute__((packed)) {
            uint32_t : 32;
            uint16_t tom : 11;
        };
    };

The member types don't actually matter here so we can have a little fun and macro it without having to resort to templates to get "correct" types.

    #define OFFSET_BITFIELD_DECLARE(NAME, SIZE) \
        union NAME { \
            uint64_t : SIZE

    #define BITFIELD_MEMBER(NAME, SIZE, OFFSET) \
        struct __attribute__((packed)) { \
            uint64_t : OFFSET; \
            uint64_t NAME : SIZE; \
        }

    #define OFFSET_BITFIELD_END() }

    OFFSET_BITFIELD_DECLARE(Dang, 64);
        BITFIELD_MEMBER(foo, 5, 0);
        BITFIELD_MEMBER(bar, 5, 0);
        BITFIELD_MEMBER(baz, 16, 4);
        BITFIELD_MEMBER(tom, 11, 32);
    OFFSET_BITFIELD_END();

Highly recommend not doing this in production code. If nothing else, there's no compiler protection against offset+size being > total size, but one could add it with a static assert! (I've done so in the godbolt link)

Edit: if you're talking about Zig, sorry!

You might want to have a look at the unboxing and packing annotations that are proposed for Virgil. The unboxing mechanism is implemented and there was a prototype of the packing mechanism implemented by Bradley for his thesis. I am working on making a more robust implementation that I can land.

https://arxiv.org/abs/2410.11094

I'm not sure I understand your example; if I am looking at it right, it has overlapping bitfields.

But supposing you didn't want overlapping fields, you could write:

    type Dang(tom: u11, baz: u16, bar: u5, foo: u5) #packed;

And the compiler would smash the bits together (highest order bits first).

If you wanted more control, you can specify where every bit of every field goes using a bit pattern:

    type Dang(tom: u11, baz: u16, bar: u5, foo: u5) #packed 0bTTTTTTTT_TTTbbbbb_bbbbbbbb_bbbzzzzz_????fffff

Where each of T, b, z, and r represent a bit of each respective field.

Overlapping. I have my needs.

I'm curious if some of the bits in your data types are "control bits" that determine what the format of the other bits are. If that's the case, then it sounds like an algebraic data type would be a natural way to express it. If you read the linked paper, algebraic datatypes in Virgil can have different encodings for the cases. As long as the cases are distinguishable via a decision tree, it should be possible to just describe the formats declaratively and have the compiler do all the encoding/decoding/matching.

Are you saying you want foo and bar to completely overlap? And baz and foo / bar to partially overlap? And have lots of unused bits in there too?

C# can do this with structs. Its kind of very nice to unpack wire data.

Look at Erlang bit syntax: https://www.erlang.org/doc/system/bit_syntax.html

It can even be used for pattern matching.

I don't know whether Gleam or Elixir inherited it.

I think you can do this with Virgil, but I'm having trouble finding the exact doc page at the moment: https://github.com/titzer/virgil

The description is in the paper, but not all of it is implemented.

https://arxiv.org/abs/2410.11094

Bradley implemented a prototype of the packing solver, but it doesn't do the full generality of what is proposed in the paper.

Bitfields are kind of a fake feature because they can't be individually addressed like variables can. So they just turn into inlined getters and setters. Old compilers could not inline arbitrary short functions so bitfields were required as an extra hack, but this is no longer the case today.

You can kinda do this with Zig’s packed structs and arbitrary-width integers

Waymo's been in Austin for a while! Seeing them on MOPAC, when I don't think they're supposed to be on the highway, is always charming.

a while for sure, Waymo had cars all over last time I was there ~5 years ago

Waymo expanded highway operations at the end of last year

https://apnews.com/article/waymo-autonomous-driverless-cars-...

Ballpark figures based on the ram earth construction for TGE vs AOT would have the AOT wall be 5-10x the volume & mass of the TGW. The issue is labor — the Great Wall probably represents 20–100 million ma years of labor. The AoT wall probably has at most 100k man years of labor it could've pulled from. That'd mean it's labor-mass ratio is off by 1000–10000x.

This gets into spoiler territory, but the walls in Attack on Titan weren't made with human labor. The first hint that something funky is going on was at the end of the first season finale, but we don't get the full story about the walls until much later.

It also was built when Marley was still very much a massive empire. So it wasn't limited to the manpower inside the walls. This is clear from how many of it's actual construction materials were used.