Finally getting around to listening to the Wookash Podcast where...
Björkus 'No time_t to Die' Dorkus@__phantomderp
9 views
Dec 17, 2025
~12 min read
Advertisement
1
Finally getting around to listening to the Wookash Podcast where defer is, apparently, mentioned. I guess I should listen to this thing in ful-- oh my god it's two hours??
Well, time for the 2x speed buff.
Well, time for the 2x speed buff.
2
Oh okay nope one person talks WAY too fast for 2x to work, scales down to 1.75x.
3
Oh god they're talking about defer. Do I really wanna hear this.
4
Oh, okay, so before talking about defer they briefly mentioned modules, and now spans. The Pro-C person says he's not super convinced spans are necessary, the Hates-C person says he wants spans to do bounds-checking in a dedicated, compiler-driven fashion. Makes sense.
5
That's about my take on it too, really, more than any syntactic gains. (I'm also working on the paper for this, but it's tabled until after defer and other stuff are finished).
They use the word slices but it's the same thing, spans or slices. I also want the ease-of-use safety.
They use the word slices but it's the same thing, spans or slices. I also want the ease-of-use safety.
6
"The one C standard I would use is C11. Basically, for the atomics." Yeah, that's my take pretty much as well. I do wish I had a lot of the stuff I was standardizing, though. C89/98 is the most portable, agreed there.
Seems like a big reason people struggle on C11 is MSVC.
Seems like a big reason people struggle on C11 is MSVC.
7
The other guy who loves C basically loves C99 (minus VLAs and other turned-optional-in-C11 optional).
Both of them are complaining that C23 is adding too much stuff and "forgetting the essence of C". Lol. Lmao.
Both of them are complaining that C23 is adding too much stuff and "forgetting the essence of C". Lol. Lmao.
8
"These unelected bureucrats... who do stuff and it trickles down. And that's not how it works... To me, what's important, is who implements what." The people on this podcast... ALMOST get it.
It's a push-and-pull, but the implementers DO have ultimate power. But, there IS a
It's a push-and-pull, but the implementers DO have ultimate power. But, there IS a
9
reason why MSVC has a 30-year-old GCC extension (typeof) implemented basically a month after C23 was ratified. And that's because we standardized it.
Sometimes, we get our legs cut by implementers and can't fix or change things. Other times, you bring people in with standards.
Sometimes, we get our legs cut by implementers and can't fix or change things. Other times, you bring people in with standards.
10
It's also a blinkered view to say "well, people have to compile the code from 20 years ago, now". What about the code being written right now? What happens 20 years from now? Will you still be using a 40, 60 year old bit of code with 0 improvements, ever?
Nobody ackowledges a
Nobody ackowledges a
11
middleground, where things DO have to improve for the better, or even tools backporting good things into older versions of the standard. There's plenty of "C89, but these fixes and atomics"-style of compilers. If vendors subset the standard, fine, but there has to be a
12
standard to subset! If there isn't, you get what MSVC did to GCC/Clang source code compat for 30 years: load a shotgun and start fucking blasting it.
They also acknowledge this with the enumeration situation. "It was broken, C23 fixed it" yeah, man. Now that can be backported!
They also acknowledge this with the enumeration situation. "It was broken, C23 fixed it" yeah, man. Now that can be backported!
13
"No one, actually NO-one, is writing pure C. We're all using extensions!"
... So, like. Should the Committee acknowledge that and work to standardize those extensions and come to a middleground, or do we just... keep shooting up with extension-drugs forever? I know stability is
... So, like. Should the Committee acknowledge that and work to standardize those extensions and come to a middleground, or do we just... keep shooting up with extension-drugs forever? I know stability is
14
tempting, but like.
You hate the Committee and the de-jure law, but you acknowledge that *NOBODY* is writing pure, fully-legal C. Do we just keep doing that for eternity?
The other part is vendors are complaining about needing to maintain extensions forever. They aren't
You hate the Committee and the de-jure law, but you acknowledge that *NOBODY* is writing pure, fully-legal C. Do we just keep doing that for eternity?
The other part is vendors are complaining about needing to maintain extensions forever. They aren't
15
happy about the situation they're put in, either! It doesn't seem like it's good to keep having (loosely) defined extensions with sometimes subpar documentation upholding whole industries!
But maybe I'm just weird for observing that and trying to change it, hm.
But maybe I'm just weird for observing that and trying to change it, hm.
16
"We should get rid of declaration matches usage" YEEAAAH!
Unfortunately, the Hates-C person is playing spoiler: "That's a new language. That's not C anymore!" And he's right! But ooooooOOOOH we gotta get rid of that shit, it's A W F U L. Worst design decision of any proglang!!!
Unfortunately, the Hates-C person is playing spoiler: "That's a new language. That's not C anymore!" And he's right! But ooooooOOOOH we gotta get rid of that shit, it's A W F U L. Worst design decision of any proglang!!!
17
(For Committee Reasons:
we will never get rid of it. It will never change. Ugly functions will continue to be jaw-droppingly ugly, declarations will continue to look fucked up. That's just a core tenet of C that not even I would try to change.
I'm sorry.)
we will never get rid of it. It will never change. Ugly functions will continue to be jaw-droppingly ugly, declarations will continue to look fucked up. That's just a core tenet of C that not even I would try to change.
I'm sorry.)
18
"Yes, I'd remove VLAs, but I never use them in the first place." Unilateral agreement from the Loves-C person too.
I would agree, but unfortunately VLAs have straight shooters in the Committee, dawg. You try to remove them and a small but very strong subsection of C people WILL
I would agree, but unfortunately VLAs have straight shooters in the Committee, dawg. You try to remove them and a small but very strong subsection of C people WILL
19
bet at your door, big dawg. You gotta be careful. Your truth too right, your insight too real. They'll get you!!!
(This is a joke and a play on a meme format: nobody will actually come hurt anyone about VLAs, but removing them after being made optional is a thing. MSVC will
(This is a joke and a play on a meme format: nobody will actually come hurt anyone about VLAs, but removing them after being made optional is a thing. MSVC will
20
likely never ever implement them for moral reasons. And they're already conditional, so there's that.)
21
"Remove const" OOOF, that's a SCALDING hot take. But it's kind of correct. "read-only" is like an object property, not really a good type-system property. But we don't have a good decl-based system; only compile-time system that exists in C is the type system, alas!
22
"I'd remove `const` from C, but I'd have to replace it with something else." Yeah. It's too useful to get rid of outright, you'd have to replace it, unfortunately.
Odin manages this slightly differently than C does.
Odin manages this slightly differently than C does.
23
"C is the wrong langauge to try and add immutability too" agreed, 100%. It's also why "functional programming" really struggles here, and why C++ struggled to make a functional library bit without some semi-dire consequences (C++20 filter_view shenanigans, anyone?).
24
(They're talking about how overloaded `static` is, and they bring up the obscure [static N] bit in the language.)
Yeah, that's awful. It's not a good way to do bounds, unfortunately!
Yeah, that's awful. It's not a good way to do bounds, unfortunately!
25
"I would remove the entire standard library" hard agree!
C's standard library is its WEAKEST part. Very awful design, lots of shared, mutable, invisible state. Truly bad, very thread-antagonistic. Blowing it up and starting over would be very good stuff.
But then it's not C. :3
C's standard library is its WEAKEST part. Very awful design, lots of shared, mutable, invisible state. Truly bad, very thread-antagonistic. Blowing it up and starting over would be very good stuff.
But then it's not C. :3
26
"Only include memset, memmove, and memcpy" yeah, basically. That's pretty much all C is good for for its stdlib.
The printing stuff sucks, the time stuff is dated and sucks, the thread stuff still sucks (I'm working on it), the atomics have some guarantees but not all, the
The printing stuff sucks, the time stuff is dated and sucks, the thread stuff still sucks (I'm working on it), the atomics have some guarantees but not all, the
27
Unicode stuff is now okay for conversions (but lacks support pretty much everywhere else), and so on and so forth.
It's all booty-ass-cheeks, so, you know. Blow it up, start all over again, make sure it's multi-threading aware (NO internal locks/shared data), stuff like that!
It's all booty-ass-cheeks, so, you know. Blow it up, start all over again, make sure it's multi-threading aware (NO internal locks/shared data), stuff like that!
28
I need these people to talk to the C folks because SO MANY people in C-land are shooters for nul-terminated strings, and they are THE MOST crapshoot GARBAGE in C.
But these two get it, BOTH the C lover and the C hater directly describe why the implicit-malloc, 0-terminated,
But these two get it, BOTH the C lover and the C hater directly describe why the implicit-malloc, 0-terminated,
29
threading-awful, and other such things in the standard library are AWFUL.
(I also had this issue which is why I proposed SIZED thread attributes, but the Committee blew them all up and wanted null-terminated string ones only. So, even though these two people get it, other C
(I also had this issue which is why I proposed SIZED thread attributes, but the Committee blew them all up and wanted null-terminated string ones only. So, even though these two people get it, other C
30
people are EXTREMELY brain-poisoned on this subject and will die with their null-terminated strings despite the various issues that come with them.
It's refreshing that even the younger C programmers understand how dogshit null-terminated is, though!)
It's refreshing that even the younger C programmers understand how dogshit null-terminated is, though!)
31
YEEEAH TALK YO SHIT, MALLOC SUCKS, CALLOC IS AWFUL, REALLOC IS GARBAGE, NO ALIGNMENT NO SIZES IT'S A "REALLY BAD API" THAT'S RIGHT BILL TALK TO 'EEEEEEEEEEEEM!!!!!!!!!!!!!!!!!!!!!!!!!!!!
32
Everyone is agreeing that the whole C standard library design is shit. Good.
There's hope for the youth yet.
There's hope for the youth yet.
33
"Memory management in C is not actually hard, NO! It's malloc that's hard!"
Half-agree. Like, this is a complete true statement, but it's missing the "and we don't have good slices and everything's still a pointer".
Half-agree. Like, this is a complete true statement, but it's missing the "and we don't have good slices and everything's still a pointer".
34
"Start with the most descriptive name, THEN compress it later."
Bill and Ryan will be happy to know that we've adopted this policy! ... But mostly for very new features/headers. Old stuff will still probably have the compressed names! stdbit.h has descriptive names, though.
Bill and Ryan will be happy to know that we've adopted this policy! ... But mostly for very new features/headers. Old stuff will still probably have the compressed names! stdbit.h has descriptive names, though.
35
"We would remove most stuff from C23, and only work from C11 or C99/89" I've talked about this a lot previously, but honestly it's fine. This is how most C developers are; they consider the things they care about to be the holy grail, and then EVERYTHING else is FOR LOSERS.
36
Good vouch for Bill's design chops, though:
"In Odin, I have atomic operations, but I don't have atomic types but I've been considering the types." This is actually the correct direction of how to design atomics. Atomic operations are the fundamental, hardware-mirroring,
"In Odin, I have atomic operations, but I don't have atomic types but I've been considering the types." This is actually the correct direction of how to design atomics. Atomic operations are the fundamental, hardware-mirroring,
37
low-level design. But then you put types on it for the same reason that Ryan advocated for shortened names: it's such a ridiculously common operation, and certain objects will never, ever be modified non-atomically, ever, and anytime you'd want the benefits of non-atomics you
38
want it done safely from the comfort of an optimizing compiler that's proven all the bits necessary to just start doing shit non-atomically where it matters.
C++ and C got this wrong in their designs, they started with atomic objects, but needed atomic "accesses" (operations).
C++ and C got this wrong in their designs, they started with atomic objects, but needed atomic "accesses" (operations).
39
Linus also complained about this on the LKML, and C++ fixed it with atomic_ref<T> in C++26. C has no fix for this, because it doesn't have references and because _Atomic(T)* and _Atomic T* are not "atomic accesses into T", but "pointer TO an atomic object".
It is, unfortunately,
It is, unfortunately,
40
something that is entirely unrepresentable in C at the moment. It needs to be fixed, but it won't for quite some time I'm sure because C is slow as balls to recognizing its mistakes and moving to fix them.
Alas!
Alas!
41
"I wouldn't have while, or do while, just for."
I mean... I guess? Once you have one, the others are free. This is more nitpicky and honestly a flavor remove than anything, and he says as much, but. Even if I was designing a new language from scratch, it seems so totally.. free?
I mean... I guess? Once you have one, the others are free. This is more nitpicky and honestly a flavor remove than anything, and he says as much, but. Even if I was designing a new language from scratch, it seems so totally.. free?
42
Like it would cost me ~nothing to have while/for/loop in a new language. It's not even worth thinking about. If someone comes up with a fourth one that isn't well-handled by those three, then like, sure man. Spice it up. At some point I'd not have more, but. You know.
43
This is one of those things that generates like 500-post-mailing-threads because it's such low-hanging fruit, so people will immediately start frothing at the mouth and bitching endlessly. It's a real timesuck.
44
"For language design, you do what people expect, not just pull stuff out of your ass." Again, good language design chops from Bill here. There's people who design what they want (and it fucking sucks to work with, like Java, Haskell, etc.) and then there's people who design for
45
their users (C, Odin, C#, Typescript, Python, etc.).
"Remove the arrow operator, just make the dot operator do the dereference"
I mean. Kinda agree, but not really worth it now that the blood is already in the water. It's more important for C to do this than C++, cause no T&.
"Remove the arrow operator, just make the dot operator do the dereference"
I mean. Kinda agree, but not really worth it now that the blood is already in the water. It's more important for C to do this than C++, cause no T&.
46
"I would remove uninitialized stuff. Equal-zero by design." Good stuff.
"Error handling in C?" Some disagreement between Ryan and Bill here. Ryan would might do implicit thread_local stuff, but Bill would do return types and keep it all locally. But Bill figures it's API stuff.
"Error handling in C?" Some disagreement between Ryan and Bill here. Ryan would might do implicit thread_local stuff, but Bill would do return types and keep it all locally. But Bill figures it's API stuff.
47
"Build syste-" YEAH NOT LISTENING TO THIS, SKIP!!!!!!
48
"My opinion on macros is that they're the only reason C has survived"
Buddy you don't know the half of it. There's excel files using C macros as a preprocessing step. It's fucking bananas out there.
Buddy you don't know the half of it. There's excel files using C macros as a preprocessing step. It's fucking bananas out there.
49
There's an undefined behavior discussion, and guess what?
I'm not touching it.
Everyone's got their own bugbears about it and I hate getting involved in the topic because it's asinine even to just pin down definitions. I'll keep my hot takes to myself!!
I'm not touching it.
Everyone's got their own bugbears about it and I hate getting involved in the topic because it's asinine even to just pin down definitions. I'll keep my hot takes to myself!!
50
Now we're onto data structures. Tbh good takes, and they're both right: C is anemic in this regard. But we've already acknowledged the standard library is garbage, so not really a big deal here.
Big bit is how allocations work. Universal acknowledgement that arena-style
Big bit is how allocations work. Universal acknowledgement that arena-style
51
programming, while efficient and good, is not how most people program. So you want to optimize for 2 types:
- always pass in your own already-allocated buffer, make user responsible for memory (by having conservative stdlib) (Ryan),
- just make heap parameter explicit (Bill)
- always pass in your own already-allocated buffer, make user responsible for memory (by having conservative stdlib) (Ryan),
- just make heap parameter explicit (Bill)
52
For the record, they both mostly do arena-style programming where it matters. But for libraries, explicit and/or replaeceable heap, or just refusing to allocate and making the user do it (Win32, C2y <stdmchar.h>, how Vulkan works but for GPU resources, etc. etc.)!
53
On macros and the "curse of lisp":
the "Curse of Lisp" didn't happen (fully) to C because C's macro system isn't good. It's very weak and stupid and babyslop-awful levels of "this is only good for the simplest of transformations".
Compare this to, e.g., Rust's macro system,
the "Curse of Lisp" didn't happen (fully) to C because C's macro system isn't good. It's very weak and stupid and babyslop-awful levels of "this is only good for the simplest of transformations".
Compare this to, e.g., Rust's macro system,
54
where the macros are so fucking strong that they paper over a very extreme amount of language deficiencies by using macros (and even then, apply in-compiler shenanigans to make it better (hello, format and friends)).
Lisp is the same way, but turnt up to 11: you can't make
Lisp is the same way, but turnt up to 11: you can't make
55
shit if you're not making macros. The language literally doesn't function if you're not macro-maxxing and paren-pilling yourself at all times.
Macros are the way to paste over a lack of language features, but even for C you can't paste over all of C's defiencies with its
Macros are the way to paste over a lack of language features, but even for C you can't paste over all of C's defiencies with its
56
macros because its macro system is garbage. So it had to force the language to reach a place where it could be used in a good handful of situations without the macros by themselves.
57
"There's not a lot of good resources for how to write good C."
Honestly, not that wrong. Gustedt's and Seacord's books both do a lot to help with that, but like. It's still hard to talk about an interface and what it needs and what necessitates certain features.
Honestly, not that wrong. Gustedt's and Seacord's books both do a lot to help with that, but like. It's still hard to talk about an interface and what it needs and what necessitates certain features.
58
I'd actually write something about this myself but I want to wait until certain C2y/C3a features settle, like having Statement Expressions and the like. (Those will all take time, but they do unlock a good portion of how to write meaningfully helpful C code.)
59
Sean Barrett, also a good librarian. Reading his source code can be good too, though won't always teach you some of the more advance stuff like allocation handling and whatnot.
60
Lol, last little potshot at # embed there. Fair, fair.
As for the defer stuff: not anything I haven't heard before. More of the same "oh, what about my beautiful one-to-one, sequential, translation to assembly", which is not a good way to design either a compiler or a codebase.
As for the defer stuff: not anything I haven't heard before. More of the same "oh, what about my beautiful one-to-one, sequential, translation to assembly", which is not a good way to design either a compiler or a codebase.
61
But that's the end of the podcast.
