Trinstan Brindle

About the the whole safety in C ⁇ and the future of C ⁇ , and do you think do you think it has one? Should we just should we just let it die? Should we just go, well, you know, C ⁇ has had its time and now we should move on to something new? Or do you think we should pursue, you know, trying to turn C into a safe language? What are your Connor, what's your your feeling on the matter?

Conor

Welcome to ADSP the podcast, episode 223, recorded on February 17th, 2025. My name is Connor, and today with my co-host Ben, we continue our chat with Tristan Brindle. In today's episode, we chat about the recent C London meetup and whether C is dying or already dead.

Ben

Oh, that's right.

Conor

Yeah. Yeah. And I had FOMO. I was I I uh I mean I should have figured that there was gonna be a meetup and Ben would be there and then you guys would bump into each other.

Ben

Well, I only looked it up. You know, I planned my trip to England for the end of January, and like a few days before I was due to go, I'm like, oh maybe I should look up and see if there's a something happening in the London meetup. And as it happened, a huge thing was happening, and there was like everyone flew in for it.

Trinstan Brindle

It was the the biggest meetup like uh in the the the history of the event because it was a very uh kind of special uh uh occasion because it was um Bloomberg had organized this this panel of um was it six or seven uh experts on the contracts, the C contracts proposal uh to sort of come in and do a like a QA um all about all about contracts. So it is recorded.

Conor

I think a link in the link in the description for those that were not able to attend in purpose, in to attend in purpose to attend in person. You can go click a link. I think it's like an hour and forty minutes or an hour and fifty minutes or something like that. And I did hear Ben's voice on the mic at some point asking a question. I do not recall the question, but I I do remember hearing your voice.

Ben

I asked the question about whether uh contract handlers contra uh there's there's there's a way with contracts to install a user-defined handler for contract uh violations. That's the word I was looking for. Um that is I asked whether that was possible at compile time. It is not, it is link time only. So it's a runtime thing. Although everything else about contracts pretty much can work at constexpr time as well. That is the one part that unfortunately can't.

Conor

And the implications of that are that you can't entirely do contract checking at compile time.

Ben

You can do contract checking at compile time, but you can't have a user-defined violation handler.

Conor

I see. So I mean I'm guessing that you were hoping that you could do some kind of custom injection of some, I don't know, error message or well, if you can if you could do that at a compile time, it would mean that you could uh effectively do uh user formatted compile time warnings. Yeah, yeah. You could do some ASCII art in there or something if you really wanted to. If you wanted to, yeah. Yeah. Any any uh any uh so I mean people can go and watch the the talk, but any behind the scenes, you know, chats or uh gossip that you guys can share with the the listeners of uh you know before or after?

Ben

Or was it just you know people showed up at the left and I mean uh I'm not sure if I hadn't publicized that to to any of my London friends that I was coming. I had signed up because you know, signing up for meetups is is is a good thing to do because it it influences, you know, the organizers know how many people are coming, what the the what the kind of food and food and drink situation is, that kind of thing. So I had actually signed up, but uh I was sign up number 100 120, whatever, I don't know. I was down in the weeds. It wasn't like I signed up first so everyone could see that I was coming. Um so I just rock up and uh I see Gashper and Gasper's jaw drops onto the floor and he is all excited and waves at me, and then Tristan shows up and it's a good time.

Trinstan Brindle

Gashwashw's like Tristan, Tristan. Um have you met Ben D? And my the very first thing I said uh was what the hell are you doing here? Which now I think about it, I probably could have been a bit friendlier, Ben. So sorry about that. But uh what a man is. No, no, that's how grace people treat each other. That is totally friendly. Yes, yes. Um man of the moment, Gashpa, who's uh gonna be uh seemed to be one of the most important people in in C, I think, has been appointed editor of the Safety White Paper. I don't know if you've seen that. Oh, right. I have not. Along with Herb, they're gonna uh between the two of them, I believe. Interesting. So that's gonna be actually let's let's go on a tangent. I'm gonna be the host for a moment. I'm gonna ask you two uh uh questions. Uh or a question about um about the the whole safety in C ⁇ and the future of C ⁇ . And do you think Do you think it has one? Should we just should we just let it die? Should we just go, well, you know, C ⁇ has had its time and now we should move on to something new? Or do you think we should pursue trying to turn C into a safe language? What are your Connell, what's your your feeling?

Conor

I want Ben to go first. I mean this is this sounds like uh it's a revisiting of episode 150 when we Bryce and I subpotted that other podcast and they were all like it's dead, blah blah blah. And I think the podcast episode was Is C dying? So I don't know if we're gonna call this one is C dying 2.0 or addition edition two. Uh but I'll let go I'll let Ben go first.

Ben

Well, I have opinions. Um I have observations. I mean, obviously C isn't dying for the same reason that COBOL isn't dead, and you know, like it's past the threshold of immortality. You know, that's a sort of trivial thing to say. But with safety in particular, it seems like no one's realized the um the impact of the current geopolitical climate on the safety conversation. Um, you know, it I who is now going to fund work on safety? Nobody has an incentive to do so. The US government is deregulating everything. You know, there is simply going to be no pressure from the US government anymore for the next at least four years, probably longer, to do anything with safety. Um that's the sad fact. Um so, you know, even if C gets safety in some form, there is no incentive for any tech company to work on it. The implementation of said safety will not occur to a first approximation. Um you know, we're seeing already tech companies just just changing things in response to the current administration. Now, you know, this doesn't take into account Europe the European Union, which is a force for good, maybe in this. Um we'll have to wait and see. But but but I certainly think that the current climate has not only taken the wind out of safety, but even reversed it. Um very sadly. Uh we don't have to be happy about that, of course. So that's just an observation that I have. It's very similar to what happened, you know, a lot of people again, we can sort of learn from history. Um if you are old enough to be working professionally around 2000, you may remember which which some of our listeners no doubt were. Um I have friends who were working at Microsoft then. Microsoft was being investigated for antitrust by the Department of Justice. Microsoft was in potentially quite a lot of trouble. They were talking about splitting up the company, all those kind of things. When the Bush administration came in, it pretty much went away overnight. From what I heard from people who worked at Microsoft at the time. And the same thing is happening here. Safety has gone away overnight, or at least the incentives to become safe in the US have disappeared overnight.

Conor

A very good observation. But a part of my my there's a voice in the back of my head that says, even though that's the case, it's probably not going to uh halt the committee's desire to make progress in that space because regardless of the current administration in the US, long term, um, it definitely seems like that is the the uh the trend. So even if we do take a four-year break or an eight-year break from the incentivization to do that, my guess is that in two decades from now, it's gonna it's you know, gonna the incentivization will r rematerialize at some point.

Ben

And well, I certainly hope so. And don't get me wrong, there is still a moral imperative here. Um there is just no structural financial imperative within society at the moment.

Conor

Yeah. I guess in Yeah, in terms of like the my take on like dying or dead, like, you know, I agree with with Ben in that there's no such thing like C is dead. Whenever you hear people say that, it's I think they're being they're playing fast and loose with that word. Uh the question is, is it now on like a downtrend? Like, has it peaked? And like over the next 50 years, pending that the AI singularity doesn't wipe out the planet or some other catastrophe, um, what's gonna happen? Um and from my point of view, there is there seems to be so much wind behind safe languages, primarily Rust at the moment. Like I listen to a ton of other programming language podcasts, and I'm not really a part of those communities per se, maybe Python a little bit, but there's so much tooling and like transferring of uh tech written in a cer a certain language to being written in Rust. And you never hear it happening to being written in C. All these new JavaScript, like runtimes, like Dino, etc., bun, all being written in Rust. All this Python tooling, um, you know, uh Rough UV being written in Rust. Like all of this like tech transfer that's happening to get these 100x speedups from being implemented in Python or JavaScript or some other language and then re-implemented in a systems language, it always happens in Rust. And I get the sense that like new projects in this kind of vein always happen in Rust. That doesn't mean that like C is going anywhere. Like I think Jason Turner, he had a C weekly video where he highlighted like all of the massive uh software programs, you know, Word, LibreOffice, just like he goes through just like a ton. And they're all written in C. And if you think about currently, like there's this joke that like, oh, you should, you know, when we're in the age where you should never need to manually manage memory, which is ridiculous. I don't know if it's an XKCD or it's some like quote or whatever, but it says that like every single uh G seed languages GC is implemented in C. So it's like the ability to not use manual uh memory is due to manually managed memory. And uh so I I don't think C is gonna like it's according to rankings, you know, rank number five or six, depending on uh the language ranking. I don't think is number two? The new uh the T O B Twilight. That's that's the worst index of all.

Trinstan Brindle

Um it's apparently this is like uh people who've just been uh Are you kidding me?

Conor

I'm pulling it up right now. T I O B stands for the importance of being earnest, the irony that not lost there. Look at that, folks. Python number one, Cumber two. But let me let me uh you know highest position since 1995, I read somewhere. Fortran is number 11, uh Delphi slash object Pascal number nine, visual basic number 10. TypeScript doesn't even make the top 20. I think it's ranked like let's find it, folks, 38th, and on every other single uh measuring site or ranking site, it's a top 10 language. And I think we've got Prologue is making a comeback, one of the fastest growing languages at number 20. And uh, and so just like I have, I don't know what is up with this site, but uh I actually uh uh it's still included, the link is still included on my plrank.com site, but I have uh disabled the ability to include it in the average, because I just have checks check boxes to you know calculate the weighted average. Um I've I've uh excluded it. You're no longer able to include it because I think it's such a bad site. And so whenever I hear podcasts linking to this, and and don't get me wrong, I used to look at this site all the time because I see rankings, I see logos, I go, ooh, very nice. Um, but then when I started noticing like the changes from month to month when this gets updated, I was like, what the heck is going on here? Um like the fact that TypeScript is 38th and that prologue and Fortran, I'm not saying the Fortran isn't potentially a top 20 based on some metrics, but I mean, uh, it's probably not higher than TypeScript, um, is all I'm saying. So, but I guess asterisk, it is number two according to T I O B E. Um, but yeah, I I don't think it's going and it's not gonna drop out of the top 20 in the next 30 years, I don't think. Um it's gonna be uh still one of the most popular languages, and I still think what there's gonna be, if you look at the number of jobs open per language, it still ranks one of the highest. And I don't think that's going anywhere. The question is, is like the momentum, you know, like and I think we're gonna whether it's Rust or some other language, yeah, I definitely think the momentum is gonna be switching to and I honestly I'm not even sure it's safety, to be honest. I think the tooling is my number one recommendation to the C community. If you can replicate the Rust Up experience for C, so that I don't need to go manually configure clang format, clang tidy, include what you use, uh CPP check, like um all this stuff, like Rust up just does it for you. If you and like it not only does it do it for you, it initializes like a Git repo with like your Git setup, and you can just immediately go, you know, git diff. It's a it's amazing. Um I think like 50%, if not more, of the reason Rust is doing so well is because of its tooling experience. Um it's not because it's a more pleasant language or whatever. Um like safety's great, but I honestly uh you know, for research work, you're I don't care about safety. I care about being able to prototype quickly, right?

Ben

Not um we have to recognize also that we are talking about the sort of the top of the pyramid here in terms of the privilege of being able to write in a desktop environment or in a server environment or you know, in an environment that can support these kinds of things. You know, one of these days, uh in one of my talks, I'll put a pie chart, which will be like number of processors in the world, and it'll be like desktop and server processors versus embedded processors. And the pie chart's just gonna be one colour, it's gonna be embedded processors because there won't be enough resolution to display the number of server and embedded processors in the world. You know, uh have you tried counting the embedded processors just in your room that you're in right now or in your house? Well, let me tell you that every desktop or server processor contains within it dozens of embedded processors. So that alone is going to mean that, you know, and and programming embedded is still often done in C, not even in C. Well, you know, I I do it in C, and it certainly is possible in C, but many, many people are still working in C, and still and and we still have to work in Assembler sometimes. And you know, the idea of programming embedded in even Rust, let alone JavaScript, TypeScript, maybe another language, a safer language, we are a long way from that at the moment. Rust Rust had the reason I don't think Rust is taking over there anytime soon is I mean there are initiatives to do Rust on embedded, I'm aware. And there are, you know, an embedded is getting uh more cape more capable, right? Embedded doesn't always mean bare metal, it might mean some embedded Linux distro, right? And in that case, maybe Rust is viable. Um but at the moment C and LLVM are the only things that have a defined memory model. Every language that uses LL LLVM inherits the C memory model because it's what LLVM provides. Um and and when you're when you're doing work with interrupts, when you're doing that kind of work, you need to be able to reason about the memory model. Um that's one thing. Um at a higher level when you're programming libraries, um C's killer feature is Variadic templates. Absolutely no doubt in my mind. Um I cannot understand why Rust is not scrambling to get variadic generics. Apparently they've looked at it, they've decided that it's not high priority. It is the single biggest feature for writing libraries, it is the most powerful feature. I contend.

Conor

I mean I I know multiple people that have said that's the reason they prefer C to Rust, is that they aren't leaving a language for another language that doesn't have variadic generics. And like I think even on Oxide and Friends, which was the podcast that we subpotted where they had a couple people saying C is dead, they had one of their employees at Oxide like speak up and say that like, well, from a library implementer like point of view, it is actually quite painful trying to do some of the stuff that's possible in C. And I think he might have even like mentioned like the tuple implementation example of like, you know, doing this kind of stuff, like sure, we have macros, and you can superficially get the same kind of thing, but like that's not idiomatic Rust. You don't want to be in like trait land and iterator land and then want to do something that's variadic and then have to reach for an IZIP macro. Like it's just it's it's awkward. Like a lot of people don't even know it's there. And that's tech that's the solution right now. Like uh I've asked a few Rust programmers, like, if you want to you know zip over a couple different sequences and then like unpack it, like how do you do that? And they're like, ah, well, you have destructuring in the parameter list, so I can just like destructure a tuple where the second element is a tuple. And so your destructure is just like paren, a, comma, paren, b, comma, c, and paren, and paren. It's not super elegant, but like it does work. And like the more you try and scale that, the worse it gets. Uh, but that was the answer I got. And he's like, and and the individual said, like, honestly, like I I acknowledge that like C's solution is superior here, but that is something I'm willing, like, I'm not an implementer, I'm just consuming this stuff, and that's something that nicety is something I'm willing to give up. Uh, but from an implementer's point of view, it's it's like it's not just a syntax inconvenience, it's uh a tool that you no longer have to build your library. And I think he mentioned that like this was a huge gap that like a lot of people don't notice because a lot of like the majority of folks are app, you know, uh writers, they're not library implementers. Um and so unless if you're talking to a library implementer, you're not really gonna hear about uh this kind of missing piece, right?

Ben

It's funny you should say that because I would I mean it's true, but uh you know, everyone writes functions. Everyone writes libraries because we write functions, we write APIs, right? Um, regardless of what we're doing. Very few there are very few people who don't write functions. So regardless of whether you're an app writer or a library writer, I think variadic generics are are super, super powerful.

Conor

Yeah.

Ben

And that's my, you know, I have a bias here. And and my bias is that I haven't written a non-template in about six years professionally, and I haven't written a non-variadic template hardly in most of those six years. So there you have it.

Conor

What's your opinion? We've we've we've voiced ours now. We'll we'll flip it back, and now we're the interviewers again.

Trinstan Brindle

Uh on variadic templates.

Conor

No, just uh everything. Uh is is C on its way to dying? Is it is it uh only in uh a second kind of winter as was the 2000s, and we're about to get C26 or 29, and it's gonna be a a second boon, you know, a golden age of C.

Trinstan Brindle

Uh well um hmm. Well I I agree with you that uh there is just too much C code out there for it to ever truly die. Like it it won't. Whether the thing that might happen is it just loses mind share. Like like people just the young people when they're learning to code, they just think of C as an old language and they don't want to, you know, start using it, and it becomes harder to hire C programmers because the ones that are there are starting to retire, and people just move away from it for that reason. Um just loses mind share and in the end just sort of fizzles out for that reason. I think we're that's uh one of the dangers of uh dangers, if that's the right word. Well one of the Potential futures, just because I think you you see it a lot already, is that if I can generalize sort of younger coders like people who are just getting into it, uh seem to gravitate more to more to Rust than C. It's seen as uh uh you know trendier, if you like. So even outside of the safety thing, that's that's something that could happen. In terms of safety, yeah, uh Ben, you're right that the uh regulatory pressure uh might reduce. Um companies, of course, they always care about the bottom line, and if safer languages mean they're going to face fewer vulnerabilities, things that could cost them money, um, you know, that might be a reason that they choose to do it anyway, um, even outside of regulatory pressure. Uh so yeah, I I I would like to see uh a safe version of C. I would I I support kind of the the goals that uh Sean Baxter had with his with Circle of uh coming up with it is really the the subset of a superset thing that that Herb and uh and Bianna have been talking about for for a few years now. You know, we can we want to expand the language with safe uh um facilities and then you know have a safe subset that you can do most of your everyday programming in. I think that would be that would be a good future for the language, but whether we can get there, I don't know. It's um incredibly difficult.

Conor

Yeah, and I mean the committee, even if we do get there, it's gonna take I mean stuff that supposedly a lot of the committee agrees on, it still ends up taking like a decade to get in.

Trinstan Brindle

Yeah. Um yeah, and then it's like um it's the the whole th the backwards compatibility is uh is is always the difficulty with C even like you were saying with the with the tooling being being problematic, but like with with any new language, um, or nowadays anyway, because people have learned the lesson that whenever like a company comes with a new language, they will have like yeah, it will come with a build system, it will come with a linter, it will come with a source code formatter. And so people just have this from the start. And you know, we could probably have a similar experience to what you get with cargo uh and and Rust Up and that stuff, but it would mean that you would have to lay out your files in a particular way, and you'd have to give them a certain um you know, file extension or whatever. And the C you know, people were hell no, like I want things to be standardized, but I want you to standardize it my way. Um so it's kind of a a bit of a problem. Um, you know, everyone wants everyone wants niceties, but uh as long as they don't have to change what they're doing.

Ben

C supports such a wide range of hardware that that it's it is very diverse in terms of needs. Right. Um I saw just just this weekend, just you know, last week the C committee was meeting. Making a byte 8 bits for C26 was just dropped. A byte it's not necessarily 8 bits, because presumably there are hardware platforms out there that that preclude us from making that determination. So C is extremely supportive of diverse hardware.

Trinstan Brindle

Yes, I I was uh I I had no idea that they these these platforms still existed, but apparently they do.

Ben

Um what I so I'm not I don't know anything about this really, but from from Google searches, um I see that there are there is DSP hardware that is specialized to work with even 12 bits, 14 bits, 16 bits, where where the tool chains just just treat that size as as their byte, I guess. And and yes, why not? If you have a specialized piece of hardware that does one job and it just effectively has one data type to work on, then uh why would you spend a silicon to make to make bytes addressable, to make eight bits addressable if you only ever work in 16 bits, I guess. Like I say, I really know nothing about it, so that's just what I'm surmising.

Conor

Alright, do we want to put a bow on this uh is C dying uh second edition uh slice of this conversation? Any any final thoughts on uh I don't don't don't call the episode that I feel bad.

Trinstan Brindle

I feel bad now. I was just curious about what you two what you two thought. And I don't want to put a anti-titles though on the case.

Ben

We shouldn't lose sight of the fact that learning languages is fun, learning C has a lot to offer, you know, and I'm a big fan of languages in general. Um different languages have different things to offer, and and the reason to learn C in 2025 is the same as it's always been. Because it's because you learn things about how languages work, you learn things about how how computers work, um, because it's fun.

Trinstan Brindle

Yeah.

Conor

APL is fun too. I would argue more fun, but that's I didn't say it wasn't.

Ben

I didn't say it wasn't.

Conor

I can spell iota in a single glyph instead of uh what is it, three plus two columns for the namespace, plus four is uh nine, plus you need the parentheses and everything else that comes with it. Uh but you know, there's another reason I love C. It borrows heavily from APL. All the numeric algorithms come straight from there. Inner product, adjacent difference. And APL even gets not only not only does APL get mentioned in From Mathematics to Generic Programming, there is a line of APL code in From Mathematics to Generic Programming. There's a whole little there's a whole page where uh Stepanov references both uh Kenneth Iverson's 79 Turing Award paper, Notation as a Tool of Thought, and John Backus' Turing Award paper from the year before in 78. Um can von Neumann be liberated from the von Neumann style? Yes, where he introduces the FP language. Um two of my favorite papers. Are they top five? I'm not sure if they're top five, but fantastic. They get referenced in like the same two paragraphs, and uh and then I think he shows an example of a plus reduction. And so there's there's APL, you know. If you weren't convinced by the the passion that Stepanov has for the stories of mathematicians, uh, you know, go read it for that one line of APL code. Um all right, we will we will wrap up. I think that's episode 223, and now we're starting episode two twenty four. Be sure to check these show notes either in your podcast app or at adspthepodcast.com for links to anything we mentioned in today's episode, as well as a link to a GitHub discussion where you can leave thoughts, comments, and questions. Thanks for listening. We hope you enjoyed and have a great day. I am the anti price. Um