Also, if I remember correctly, the first Rust and Go compilers were written in C.

Sure history is great and all, but in C it's hard to say reliably define this int is 64-bit wide, because of the wobbly type system. Plus, the whole historical baggage of not having 128-bit wide ints. Or sane strings (not null terminated).

That isn't really a problem any more (since c99). You can define it as uint64_t.

But we have a ton of existing APIs that are defined using the wobbly types, so we're kind of stuck with it. And even new APIs use the wobbly types because the author didn't use that for whatever reason.

But that is far from the only issue.

128 bit ints is definitely a problem though, you don't even get agreement between different compilers on the same os on the same hardware.

you technically have _BitInt(128) in C23, but I'm not sure that would even generate what you expect it to.

Usually it helps to know why some decision was taken, it isn't always because of the technology alone.

It kinda is. Because it was made in the 1970s, and it shows (cough null-terminated strings uncough).

Or you know having a 64-bit wide integer. Reliably.

You did read the article, right?

> because it is the most minimal way of speaking to the hardware in a mostly portable way.

C is not really the most minimal way to do so, and a lot of C is not portable anyway unless you want to become mad. It's just the most minimal and portable thing that we settled on. It's "good enough" but it still has a ton of resolvable problems.