CppCast - Reflecting on Timur and Phil

Episode Date: October 24, 2025

Timur and Phil reflect on Phil and Timur. We share some personal updates as well as news from the community. News "Why we didn't rewrite our feed handler in Rust" - post from DataBento "C++ reflection (P2996) and moc" - from Qt wiki "Poll: Does your project use terminating assertions in production?" - from Herb's blog Links Episode 376, with Rainer Grimm Final entry on Rainer's blog :-( Epsiode 350, with Timur and Phil ACCU Conference and C++ on Sea, merging: Announcement post Tickets - Super Early Bird at time of posting Catch23 repo P3846R0 - "C++26 Contract Assertions, Reasserted" ADSP: The Podcast Two's Complement - A Programming Podcast by Matt (Godbolt) and Ben (Rady)

Episode 403 of CPPCast, recorded 14th of October 2025. In this episode, we talk about C++ versus Rust, the QT meta-object compiler, and terminating assertions. Then we talk about what we've been up to lately and some important news about our podcast. Welcome to episode 403 of CPPCast, the first podcast for SipersSOS developers by SipersSOS developers.

I'm your host, Timor-Dumler. Jut by my co-host, Phil Nash. Phil, how are you doing? today. I'm all right, Timor. How are you doing? I'm all right. Thank you. Actually, before we go into anything else in this episode, I do unfortunately have to share some sad news that on the 6th of October, Reina Grimm has passed away.

So for those of you who don't know who Reiner was, Reina was a software architect, instructor, trainer, and mentor. Reina has created many amazing articles, tutorials, and talks about modern C++, lots of really great content. He had a blog, he was giving seminars. He's published lots of books, and many, many people have learned and understood superstas thanks to him.

And for the last couple of years, Raina was living with ILS, which is a progressive and fatal neurological disease, for which there is no known cure. We had Ryan on the show a few times. Last time was in February 2024, so last year, where he openly talked about his condition. He was also writing a blog about it,

where he was posting regular updates about he was doing. And actually last time I heard from Reina was just a few weeks ago at CPPCon. He could not physically attend the conference due to his condition, but he recorded a video message for everybody who was there. He had a little doll called CIPI who was physically in the room, kind of representing him. And yeah, it was a very kind of touching message, and I'm very, very sad to hear that he has now passed away. This is a huge loss for the CIS community. I have known him for a while. He's a really, really nice guy and a very big figure in a civil society.

community. So I just want to offer from both of us, our condolences to his family, his loved ones, his loved ones and his friends. Yeah, as you say, huge loss for the C++-plus community. I'm sure a huge loss for those loved ones as well. This is one of those things. It's something we've been sort of expecting for a while, but maybe not quite so suddenly, but also a big shock because it has come out of the blue, as he say. He was participating in CPPCon just a few weeks ago. We will definitely put a link to that previous episode in the show notes. If you didn't hear that the first time, we only should go back and listen to it. It gives you a lot more background about his condition.

Right. So we did want to put this at the front of the episode, so it's not mixed with the other content that we have for you today. But we do have some other content for you today. So at the top of every episode, we'd like to read a piece of feedback. This time we got an email from Peter with quite a lot of feedback. about the last episode with Herb Sutter, which was, I think, received with quite a lot of interest. So thanks again, Herb for coming on a show last time.

And so the email from Peter itself is quite long and detailed, so I'm not going to read the whole thing. I'm just going to repeat the main points. So I'll summarize them a bit. So Peter said a few things. First one, he said that automatic differentiation, autodif, which you were talking about a little bit with Herb. in SIPAS doesn't actually need reflection

according to Peter and their libraries like eigen and autodiv and boost math and XAD which I have not heard about who already supported without language support for reflection. Yeah, this was something I wasn't sure whether to mention at the time

either because I was thinking I know there has been auto differentiation done in C++ I don't know enough about it to say what the limits are or anything or what reflection brings you to the table so I didn't say anything at the time but I know one person has an auto-diff library where they actually have their own floating-floating point type or like a wrapper type that then behaves differently and collects information at runtime when you're setting up expressions, more like expression template sort of situation.

So it is in a way of doing some reflection types of things. I imagine most of these libraries will do something similar to that. So maybe reflection just makes that process easier or can go a bit further or do more of it at Compact. hard time. So I'm guessing there is still something that reflection will bring to the table that will make that process better. But I can't say any more about it than that. So I'm not an expert here. I used some methods for differentiation when I was back in numerical physics, but that was very different. That was numerical differentiation. It was not actually looking at the code you wrote. But I do recommend everybody who's interested in getting to

the truth here to actually watch Herb's keynote from CPPCon because he actually has a auto-diff expert on stage, like, explaining this and also explaining what the new bits are. So I think the answers are probably there in that talk. So we're linked to that from the last episode already, right? So, yeah, I think, I think if you want to know more, go back to that, listen to the auto-diff section. I think, I think there is, there is some difference here. Yeah, sound advice. Right.

So the next thing that Peter said in his feedback email is that the reason machine learning took off in Python was not due to, you know, C-Bast, not having reflection or any other features. And, you know, he's saying that other frameworks that I have admittedly never heard about, like CAF, Darknet, and D-lib, we're all C-B and they were very successful. And what Python did is it just made the experimentation faster because kind of the development cycle in Python, I guess, is faster. I guess that's what Peter was getting at here. But the heavy lifting in terms of like number crunching always still happens in like C-Bus-plus or, you know, something like Couda, some low-level thing.

So reflection, again, according to Peter, isn't really the new thing here that made a difference. Yeah. And again, I don't know the actual reasons here, but I'm guessing what Herb was talking about, which was a speculation on his part anyway, was that if reflection-based auto-differentiation makes the processing part of the experimentation faster, then you can see the results sooner. Maybe it's not quite as productive to write, but overall the timeframes can condense and you can get through more experiments. So I'm guessing that's what Herb was getting at.

So I'm not sure that that's incompatible with what Peter is saying. So who knows, it's an alternate timeline that we would have to unpick to get the truth of it. So we'll leave it there, I think. All right. So finally, Peter makes a third point, again, contradicting something that we were discussing with Herb and something that Herb also said in his RECON keynote is that Peter disagrees that reflection will shape C++ for the next decade or two. Peter says that reflection, as we have it as USS 26 now, is just too complicated for users to adopt.

I'm not sure it's too complicated. it. I do find it easier, like, from looking at the proposal to understand what's going on than I did, for example, with core routines or send a receiver. But I guess your mileage may vary. It's a low bar. It is certainly not a trivial proposal. There's new syntax to get used to. There's some weird stuff going on there. So I kind of see the point. But Peter then goes on and makes a much sharper point, which I think, you know, is up for debate. So Peter says that the only think that's, I'm quoting here from his email, the only thing that's going to matter if C++ wants to survive is provable memory safety.

Rast's Borraceka is what's drawing developers away from C++. And having an equivalent of the Russboro checker in C++ would be 100% more important than reflection. And he says, you know, don't listen to me. Listen to Sean Parenthood. He doesn't even write any C++ anymore, just Rust. And also he cites Sean Baxter, who did a lot of work on, you know, trying to get a borrower checker into seat or sauce, including, you know, specification and implementation, all of that

stuff. And he says, I simply don't understand why the committee didn't listen to Sean Baxter. He literally did all the work already. It's crazy. A lot to unpick then. Yeah, I'm not going to address all of it. I think he has some valid points all the way through, but I don't agree with everything 100%. Maybe the bit I want to, or two bits I want to pick on. One about Sean Parent. John's been, well, he did one of his longer interviews on ADSP, the podcast recently, and as usual, you know, they split it up, serialised it a bit, so it's spread over about three or four episodes, but a really good one. That's where he says that he's now writing Rust rather than

C++. He doesn't say he doesn't write C++ anymore. In fact, I think he actually started the conversation by saying, I was writing some C++ this morning, but he has shifted his emphasis to Russ, that is true. So I'll give you three quarters of a mark for that one. But the other one I wanted to pick on was, well, actually you started with this, the too complicated part. It is a more complicated language feature. It's very powerful language feature for that reason.

Similar in a way to using something like IFCONS dexter and concepts, they're quite complicated features. but they do simplify things you would have done otherwise. So let me like actually chime in here, Phil. Why do you think if Constexper is complicated? I think it's more the different mental model you have to have. You know, it's doing something different to the usual flow of things. Oh, you mean the fact that a branch actually instantiates a template-ish?

And so like, but you don't actually have to know that to use the feature, right? Well, to use it effectively, you sort of do. But anyway, we're getting distracted. Yeah, yeah, yeah. But my main point is, my main point is that this is primarily, I think, primarily for sort of library authors. People can build amazing libraries using this. You don't have to know how they work to get the benefits of them. And a great example, you know, the simplest possible example, you mentioned it last time, was, you know, the whole enum to string thing.

Yeah. Just be able to say, you know, convert this enum to a string or this string to an enum, single function. call, nothing simpler than that. You don't have to care that behind the scenes, that's using reflection to actually do the magic. That's a good example of, you know, you're not having to actually understand the complexity of using reflection to benefit from it. And I think a lot of the things that reflection is going to open up fall into that sort of category where we'll have some library features that will do the heavy lifting. We will just call some simple functions to get the benefit of it. Not all of them, but I think most, many of them will be like that.

Yeah, I think so, too. I think this is also how reflection is used in Rust, for example. I think there's just these amazing libraries that, you know, I mean, it doesn't have a fraction the way it was Sus has it now. It's kind of a bit different, right? Yeah. And also, I'm not a Rust expert, right? I have never actually professionally written a single line of Rust.

I've kind of poked at it a little bit. But from what I have seen, it's exactly that. Like, it's used to enable, like, really powerful libraries who otherwise just wouldn't exist. But as the end user, you don't necessarily have to understand. all the guts of it. So I think it's kind of similar in that sense, and I think we have features that are more complicated and deliver less value for, you know,

both library and users. So I think, I think, yes, but I wouldn't say that would be a reason to say it's a bad thing, or it would be better if reflection just wouldn't happen at it, right? I just don't see that. I think it's definitely a net win. Yeah.

And it's too complicated for users to adopt. I think it's not too complicated for, you know, library users, sorry, library authors to adopt. And then those libraries will be adopted by users because they're just going to be able to do stuff that give users a lot of value. So, yeah, I don't quite buy that point. I think I'm with you, Phil.

Okay, that said, we've sort of been critical, all of Peter's feedback, but actually it's great feedback, and we really appreciate you seeing a day Peter. And there's a lot of value points there. So thank you for that. So the one about Rust, actually, interestingly, we will talk about this. That's sort of why I deferred that bit. Yeah, yeah. We will talk about this again in a minute. But until we get there, I want to point out again that we would like to hear your thoughts about the show. And you can always email

us at FeedbackatsvipCast.com. So today, we don't actually have a guest, as you may have noticed by now. So it's just Phil and me. Again, we did this. a few times already in the past. We did this again today because we have some important news to share about our podcast. But before we get to that, we do have a couple of news articles to talk about. So let's do that first. And the first one gets back to what we just discussed, which is Rust versus C++. Exactly.

Yes. So I stumbled upon a blog post today, which is a very interesting counterpoint to this whole, you know, Rust will replace C++ plus unless we add a borrower checker thing that Peter brought up. And it's a blog post from Data Bento, which is a financial market data provider. And the blog post is called Why We Did Not Rite Our Feed Handler in Rust. And, yeah, it is a blog post about, you know, how they considered rewriting their feed handler, which is a pretty important piece of technology for them in Rust. And then in the end decided to not do that and keep that in C++.

I have not actually read that blog post, but Phil, I think you have. Do you want to tell us a bit more? Yeah, so it's interesting you put this in the notes, because I read this last week, came up in a different context, and it's important to frame this that the authors of this post, at least. It's not like they considered using Russ for the first time and then got scared away by the fact that it was all different. But they've used Russ successfully on a number of projects, and they're all in on it. They appreciate a lot of the benefits of it. But for this specific project, and based on those previous experiences, and some of the pain points they encountered, but they just found that the pain points just seemed to, like, add up, like, you know, sort of multiplying the peak of a wave for this particular project. And then they picked three particular pain points, but I don't think it's necessarily all of them to expand a bit on in this blog post.

So really with that in mind, that, you know, these are some of the things that Rust does a bit differently, that maybe it's actually better to do these particular types of things in C++, but bear in mind, it's not the whole story. So of the three examples, I'm not going to go through all of them.

Two of them are more about just sort of, you know, dancing with the borrigenger. Things at the Borracecker doesn't actually allow that technically can be okay if you know what you're doing. Borrachuker just rules them out. And I suspect you could probably begin around these

with, you know, some judicious unsafe code or some other ways you're doing things. They go into some of the alternate ways to do it in there. But I'll leave those ones because I think those ones have been discussed a lot. The one that interests me the most was the third one, I think. I'm just looking at the post now, actually. Yeah, case three, compile time generics. And what struck me here is that this one is not really what you can and can't do

so much as that it's just a lot more code in Rust. and in their simple example that they've actually got a side-by-side comparison and you can see the Rust version is like four or five times longer but then they say as this scales up that differencing increases more and more but if you actually look at what they're doing

what they're really saying is that in C++ calling it generics it's really sort of template instantiations they're really a form of duct typing what they're really looking at here is what's the difference between between static typing and dynamic typing.

C++ templates, ironically, is more like dynamic typing. Wait, I don't get that. Do you have to explain that to me? So, okay, the specific example they looked at, they said they have like different versioned struct. So they'll have a struct with some data members in. And then they say, oh, no, we need to add a data member. But we want to work with other systems that are still using the older version.

So they'll have version one, version two, and so on. And then they want to have a generic function, so a template function that the type is taken in as a template parameter, that then operates on both those versions. And the bets that are in common, they just say, just access those data members in this example, the same way both times. And then they just have an ifconce extra, which is obviously very simple, to conditionally access the new data members. Whereas in the Rust version, they're saying the only way you can really do that, and that there's some truth in this, is by using traits to constrain the types. So you have a trait that works with version one, a trait that works with version two. Then you've got lots of repetition and extra function accesses to wrap the data member accesses

because you can't sort of conditionally access them directly. So it's kind of like a compile time shim kind of thing that you have to kind of insert. interesting. And now, I mean, the way they've written this one out, it does sort of show the extremes, I think, you know, the simplest possible C++ version and then you've just exposed all the complexity of the Rust version.

I think in general the Rust approach is better. It's safer. It's easier to reason about because you're only thinking about one thing at a time rather than this thing that could be in these different states, different parts of the program. And in this simple example, it's simple. But as I said, you know, if you scale up,

this problem gets worse, But I think also the readability problem would get worse on the C++ side. Again, really, it's similar to the debate of, you know, what's best at dynamic programming language or aesthetic programming language. There are people in both camps. It's not a right or wrong. It's just a different way of approaching it. So I thought that was an interesting one.

Yeah, yeah. So if there's something I learned from like nine years on the CIS committee, is that there just isn't such a thing as right or wrong. There is a thing of, you know, thing A has, you know, trade off X and thing B has trade of Y. And, you know, what is more appropriate for the thing you're trying to do? Is it like X or Y, right? Yeah, yeah, exactly.

There are trade-offs. And that's what's nice about this post is it does actually show you, you know, some of these trade-offs that you would make if you're moving to Rust and do you want to pay that cost? I'm not enough of a Rust expert to know whether they've really accurately represented it. It also seems to make sense. But I did speak to somebody who is more of a Rust expert. And they seem to think that they haven't really fully embraced the idiomatic Rust way of doing things.

But I can't really comment more on that. So interesting, because my next question would have been, so do you think is there like a space for a language which looks like C++, but has a borrower checker in it, like somewhere in between? Or do you think, like, we should all just embrace Ross and move on? There's no right. Yeah, I kind of set you up for a trap here, sorry, Phil. All right, let's just move on to the next news item, perhaps.

So this one also has to do with reflection, but not with us. Actually, this one is something I stumbled on the QT Wiki, so QT or QT. However you choose to pronounce it, is a pretty popular cross-platform framework, application framework on CPSOS. And it has this thing called mock or meta-object Compact, What is this? So QT actually uses a bunch of non-standard Zipersvast extensions, such as like they have the Q object macro

and they have like a signaled slot thing, which is what they use. If you click on a button and the button does something in response to your click, like how do you connect them? And so those are not standard ZsiaS, those are kind of extensions on top. And so the mock is like a tool that reads a header that is written in this kind of like dialect,

extension of C++ and spits out, you know, regular C++ that you can then compile. And basically, this is something that has been considered as a bit of award by some people for quite some time now. And the hope was, or one of it, I would say, even the motivating use cases for adding reflection to CipaSlus was to get, you know, rid essentially of some things like the QT mock. And so the QT people themselves now wrote a article about, you know, whether DioSas Reflection actually does allow them to get rid of the mock, which is something that I think I had an episode. I think you were away, Phil.

I did it with the guest co-host. We had Vila Votilainen on the show from QT, and we talked about this a little bit, I think, there. It was, I think, kind of a bit early days because we didn't yet know what the feature set will look like of Reflection in Croso 76, but now we do. And so I don't know if Vela actually wrote this article or somebody else did, but they are saying that zero source reflection

actually might be insufficient for replacing the mock with standard C++ because they would also need token injection, they would also need to be able to programmatically define a new function and not just a class, which is what we have now, I believe. And they also need string-based lookup and other things. And some of that is kind of intended to be in CepaS29.

Some of this maybe isn't or might not be. So it's unclear if actually Searsal's reflection will ever be enough to replace the mock. So I thought that was actually kind of interesting to contrast all of the amazing things that we have heard about reflection and then people being like, okay, look, we do have a use case for this. Does this feature actually satisfy a use case?

And it turns out, well, not quite. And I thought that was interesting. Yeah. And to be clear, with your way around here, I didn't have time to read the whole article, so I just read the TLDR, which mostly said what you just said. I thought it was interesting. It said that C++26 reflection might be insufficient for replacing MOX. So it's actually still leaving open that maybe they can quite, can squeeze it in, but I think the rest of it does sort of roll it out. And it does seem to suggest that what we're

looking at for C++29 should get us there, but obviously it's too early to tell. I don't get the impression from what I did scan through that they're saying it would never be sufficient. But I'd also wonder whether there might be a little bit of, similar to what we were saying about with the C++ people switching to Rust and maybe not quite fully embracing the idiomatic Rust way of doing things, that maybe if you're taking what Mock does today and then saying, can we do all of these individual features with C++26 reflection? Maybe the answer to that is no, but could you do what Mock is true overall? with C++-26 reflection.

Maybe a different answer. I don't know. Just speculation on my part, maybe we just need to sometimes rethink what it is we're trying to achieve with what we have. And maybe we can get to there, at least by C++ plus-29.

Yeah, I'm pretty hopeful. I think also we have three more years to figure out what's going to be in C++39. And I very much hope that, you know, if you are still missing some proposals to get to where, you know, QT needs to be, that Qutti is going to send some people to committee meetings to help us get there.

Yeah. Although I think we only have about a year and a half to two years to decide what's going to be. Still a lot of time to write proposals. Yep, let's get writing. Well, we've got the next decade. All right. All right. So I had one last news item that I wanted to squeeze in, which is, again, going back to

Habe Sathe, but actually not something that we discussed, I think, last episode. No. but that's more about contracts and discussions around contracts and Herb. So I like Herb's approach of, you know, when people just disagree on the committee and saying contradictory things, which, you know, may or may not have happened in these discussions, he always says, well, let's look at the data. Let's see if you can figure out who's right by looking at the data. And so one of those questions was, you know, if you use assertions in your code, whether it's

C-Assert or your customer assertion macros, the kind of thing that we are seeking to replace with S-S-26 contracts or provide a better alternative to with C-a-Sys contracts, do you use them in a way where kind of you switch them on and off as you, I thought until now, that's how you use assertion macros? Or do you actually use assertions that are always terminating? So you use them for checks where you have the checks on in production and you don't turn them off

and they're just always on and they always terminate when you when you hit one of those assertions. So in order to find out what people in the field actually do, this is an important data point for us at the moment.

He is running a poll on his website and we're going to put a link to that poll in the show notes. And I would really, really, really appreciate if everybody who is listening to this and using C++ in their lives would go

to that link and fill out that poll. I think it's literally just one question with a bunch of options. You just click once and then click again to submit your answer. So please go ahead and do that. It would help us ton. Thank you very much. Yeah. And the one thing I'll add to it is when you do vote and submit your vote, it will then show you the current count or the current breakdown, you know, which option is winning and how many people voted for each option. And I'll say this much, I think the results are slightly surprising, at least sitting here now looking at it, it may change. The only way to find out yourself is to go and vote yourself, so go and vote now. All right. So that concludes our news items. And we do get to the main part of this episode. Yes. So, yeah. So, so Finn and I wanted to talk about a particular thing that has been on our mind for a while. So people, have noticed that we have been posting episodes less regularly over last year or so and had a few breaks, like longer breaks, and in particular had a three-month break recently between

episodes 401 and 402, I think. Yeah. Yeah. So there was actually a Reddit thread about this that I saw earlier this week where somebody posted, has anybody heard something from CPP cast? So that was during this three-month break. And I'm missing. I'm missing. I'm listening to it dearly, and I would be delighted for the podcast to resume. So that was before we published Perbs episode last Friday. And then there were a bunch of replies, and people said a few things, and some of those things were, I have no info, but I have surmised that the two hosts have been all consumed with conferences.

And somebody else wrote, one also has to deal with trying to stop contracts from being pulled from the standard again. And another one wrote, I believe one has a one-year-old. at home now too so that's probably eating up some time and yes all of that is true and there is actually also more to it as well so so yes it's true that we have been increasingly struggling to produce new episodes it's been going on for for quite a while now and we have a thought about this very thoroughly and we have now the very heavy heart decided that we're going to put the show an indefinite hiatus.

Yeah. So that is a big decision. It's not one that we've taken lightly. So I wanted to give just a little bit more background. So you know what sort of led to this? So it was like nearly three years ago, I think, that we took over the podcast. And if you haven't heard that episode where we took over, do you go back and listen to it.

Well, I think it was it $3.50? 3.50, yeah. I put a link in the show notes because I really like that episode, actually. I think that came out really well. but we didn't take that decision lightly either. We knew that we were taken on a commitment to the community, basically promising to keep this going. A lot of people have really appreciated that,

as we've seen from the comments we've been getting. And at the time, we were both working in roles that were quite conducive to that developer advocacy in particular, very community focusing. So that's sort of fitting quite nicely. unfortunately for both of us that that changed different times but over the last year or two we both changed our roles change our focus a bit and that's already made it more difficult but we kept going even though there was a point that it would have been much easier to have

stopped quite a while ago but that feedback we've been getting those comments we've been getting emails in person at conferences people thanking us for keeping the podcast going. We just keep coming back to this. No, we've got to do it. We made a commitment. We want to serve the community. So that's what's kept us going. But I think the last year has been particularly difficult. That's why we've had some longer breaks, particularly the last three months. We didn't plan that. It's just one thing after another has stopped us from recording again, even though actually we pretty much reached this decision during the summer. And we were just sort of planning the last couple of episodes. We wanted to get it done.

and move on, but even that got delayed. So I think that the big thing that's really pushed us over the line. It's a bit more than the stroll that's broken the camel's back, but it's sort of like that. Both of us are now taken on new full-time programming roles that are going to take up all of our working time, and I think eating into our free time as well. It's just not going to be feasible to our podcast recording on top of that as well.

and that's on top of all of the things that we've been dealing with already. So at this point, it's unfortunately just not sustainable. And we've had to make that hard decision. But the one thing that was hanging over us when we made the decision is, you know, when should we stop? And looking at the episode numbers, it became obvious that if we stopped by episode 403, then obviously 404 would never be found. So that was a bit irresistible at the end. So I got to say at this point, Phil,

so we do have a bit of a history, right? So we actually have been working together for a while, I think since was it back in 2017, when you were working together at JetBrains. And yeah, even back in the day, it was a thing where you just always wanted to make like a pun or a joke or on something like this. And I was just never getting any of your jokes.

And that was kind of, that became a joke in itself for like the rest of the team. I think. And yeah, it was this thing again where I was like, oh, man, like, 4-04. Like, but I think this time, like, you actually came out with the, I didn't even remember who of us came out with this. But I think it's a, it's a, yeah, it's a good, it's a good way to incorporate that, that one last pun. Yeah.

I guess. Anyway, so, so ironically, we are actually going to be working very closely together again. not physically together, like in the same company, but actually just a few blocks away from each other. So I might actually at this point as well share some piece of personal news. I'm actually also at the end of this year moving back to London from Finland. So yeah, I'm taking on a new job, which takes me back to London. I'm very excited to go back to that community there.

Yeah, I just want to maybe explain a little bit more from my perspective, like what has been going on and why it's been such a difficult decision. decision. I have been kind of lately just really struggling with the fact that I just had too much going on. I think I just, my problem is that I just cannot say no if there's like interesting like community stuff happening and like I do really care about the C++ community. I just cannot say no. And I get involved in more and more things. And at some point, I had the local C++ Helsinki meetup here where I currently still live in Helsinki, which I was running. I was the CPP con. program chair, responsible for, you know, basically putting together the schedule for like the most significant conference in our community, which was quite a lot of work. All of this is kind of unpaid, volunteered work that I was basically doing in my free time. There was also all the drama around contracts and getting that on the CPSS 26, which if you have followed that topic, it turned out to be like way more intense than anything I ever thought, I would get myself into.

And there were just so many more things, just at some point I was just struggling 10 things at the same time, all related to, you know, CepaSos community things. And ZIPCast was one of them. And in a way, it's kind of the one that was closest to my heart because like every time I go anywhere, like to a CPS conference or meet up, people shake my hand and say, thank you so much for the podcast, you know. And that really, really means a lot. But at some point, yeah, I reached a point where it was all just getting too much.

And I think what pushed me over the edge was earlier this year. So I actually, for the last two and a half years here in Finland, I have been kind of contracting, like freelancing, basically. And you kind of have to, you know, find clients that you can work for. And something that happened at some point earlier this year is that the main client I was working for at the time just said, oh, we had some like, you know, internal changes. We can't fund, you know, freelance contractors anymore.

so from next week you're not going to be paid anymore, which, you know, if you're a contractor, then that can happen quite easily. And with a family to feed, that was an extremely stressful experience, which I'd rather not repeat again. And yeah, all of the stuff kind of just really had took a toll on my mental health. And I was kind of struggling with anxiety and other things for some time now and had to get help for those things as well. So, and I just realized that this is just not a sustainable thing. And, you know, if I'm going to just completely burn out and then, you know, I'm not going to be of any help to the super source community either.

And also it turned out that I just didn't have as much time for my family and my kid as I would have like, like, often, you know, instead of spending the evening after work with my kid or my family, I was like recording a CPP cast episode because, you know, the guest that we had this week was in California and that's a 10-hour time difference between Finland and California. So, you know, I had to record it late in the evening. And at some point, it just became so much that I just realized, like, as much as I really love the show and having the privilege to do it, it's just not sustainable for me.

I'm just going to burn out really badly and be in a bad place. And I don't want that to happen. So I decided to kind of shift focus and find a job where, you know, I'm actually employed and not self-employed. And I have, like, one thing that I do. you know, a day to day and focus on that. And I think that will do me some good. So my plan is to, yeah, take on a new job soon.

And hopefully I can talk about that kind of in more detail publicly soon. And probably also do a little bit of committee work still and a few conference talks here and there, but less than I used to, sadly. And pretty much put any other super social community stuff that I'm doing just kind of on indefinite paths. So I handed over the C++ Helsinki meetup, the local one, to a couple other people here who are local who are going to do a great job at keeping it running. I also passed on the CPPCon program chair to Brett Brown, who I'm sure is going to do an amazing job. And I've kind of done the same with all of the other commitments I had.

And yeah, the last one is this podcast. And so, yeah, with a very heavy heart, we are now putting that on hiatus. as well. Yeah. Yeah, thanks for sharing all of that. I think it's important particularly when we're talking about things like mental health issues, burnout, that we do raise awareness of these things. They happen a lot in our community and they can creep up on you. So thanks for sharing that. And actually, my story is sort of quite similar in that respect. Definitely know what you're talking about when you say about not being able to say no to things and taking on too much. I've definitely definitely been there, and I was skirting with burnout myself earlier this year, and I think

I'm recovered from that now. It's ironic, I think there's many people that can say that they are moving to high-pressure jobs in the city to get away from burnout, but that's the direction that we're taking. So, yeah, hopefully, hopefully that's going to work out well for both of us. I've also pulled back a lot from community things, wrapping up This podcast is a part of that, unfortunately. I've also stopped some of the conference work that I've been doing, as many people and I've been organizing conferences. I've got a little bit more to say on that in a moment.

That's not completely stopped. C++ London as well. I'm still helping to organise that. We've actually built up quite a good organising team now, so I'm sharing that load, which is nice. So if you've been coming along to those, you'll be seeing I'm not hosting all of them now, and so that's been quite refreshing.

but conference talks as well I think I've done one this year at ACCU maybe I did one at C++ online I forget now but usually I've done about 12 or 15 by now so that's a big change

I'm sort of trying to take a step back for at least a year and then we're going to see how it goes I think the role I'm moving to again like a team maybe we'll talk about that publicly a little bit later

when I've actually started there perhaps but all going well it's one that does actually support involvement in the community, so I should be back to some of that maybe next year, but we'll see how that goes. Yeah, yeah, I have the same thing going on. I mean, I will definitely be still involved in some of that and still going to conferences here and there, but yeah, just kind of a very different level from what we've been doing. Yeah. I think we're in the same boat here, Phil. Yep, I hope so. Well, definitely, we will be in the same city,

so that's a start. I did mention that I'm going to be keeping some of the conferences going. So some people would know this already, but C++ on C and ACCCU, to be the two big conferences that I've been involved in in organizing the last few years. C++ on C was the one that actually started, took over ACCU a couple of years ago. And that was a big part of me going independent, so I could focus on those and training as well. It's fair to say that hasn't really worked out in terms of sustainability, which is why I'm going back to a full-time role. But I don't want to give them up either. So what we're doing

is merging, at least for next year, C Plus Pass on C and the ACCU conference. So there'll be a single event and a single location, but it's going to have the character, the branding, the content of both conferences merged together. And we think we're going to be able to do this in a way that doesn't really lose the spirit of five of them. So if you go to one conference, it's as if you would have been to two for the price of one. So if you're thinking about buying tickets, do keep that in mind.

That was a big decision in itself, and it took a lot of thought and research, I suppose, to see whether we could pull that off. But I'm actually quite excited about it now. And I think it's going to be the best move for both events. as well as allowing me to actually continue being involved with it moving forwards and keep those going. I'm very looking forward to that. Both of those conferences were things that, you know, events that are radio to my heart and I've attended them many times and they brought me a lot of joy. So I'm looking forward to like attending them both in one package and hopefully I will be there next year.

And I won't even have to travel internationally in order to do that. So it's going to be in April or in summer, like which? So that was one of the things we had to consider. And in the end, it was sort of decided for us, the venue's availability, but I think it's worked out well. It's going to be in the summer, a little bit earlier than C++ on C usually was, but it's going to be next June. So that works out well because the venue is going to be C++ plus on C's venue,

which is literally by the C, that's where the name comes from. So we'll be back by the sea in the summer, and I think that's a good combination. and people have always commenting on how nice it is to be sort of there looking over the sea with the sun shining and they're going out for a walk along the coast. Yeah, I love that venue. It's great. Yeah. Well, both of these conferences have been probably the conferences

closest to my heart, well, for the whole time. Obviously, C++1C, I started that back in 2019. So you can understand that one. But ACCU, that was really the first developer conference I went to back in. in 2001. Wow. That's the first of what I went to.

And I've been... 2001? Yeah. I've been to everyone apart from one year. I couldn't make it since then. I can... I started my speaking career. It's been really where I sort of found my community as well.

And that's really what's got me into this whole journey. So I have a lot to ACU. So you went to ACU in 2001? Yes. Wow. I'm going to say something that is going to make you feel really old. I finished high school in 2003. Well, we have high school students come to these conferences, so that could have been you.

So, no, I'm really, really glad that we're able to keep that going. ACC in particular has been struggling a bit down in recent years, particularly costs of everything, particularly venues and video production, has just been skyrocketing, particularly since the pandemic. And attendancees have been dropping, so it's just not been a good combination. But this way will actually grow, but we'll definitely do well, I think, and we'll just retain the spirit of both of those conferences is going to continue. So I'm actually really, really happy that it's sort of worked out this way. Right. There was one other thing I wanted to talk about, while I've got the mic.

Right. Something actually wanted to talk about for a while, but it's just not been appropriate while we've had a guest, but since, you know, we have each other as guests again, I'll take this final opportunity. to talk about something that actually started a couple of years ago, and I did mention it on the show then, but I didn't really get very far with it, and that's Catch 23. So many people will know that I'm the original author of Catch 2, originally Catch, and it's always a bit awkward to say that, but I haven't actually been active on the developer team for that for a few years now, for various reasons, some of it related to what we talked about today. But I have missed being involved with that. And Catch 23 originally started as a project

when I was working at Sonar. It's not a Sonar project. It's always been open source, but it was going to be like a vehicle for me talking about C++ plus 20 and C++23 features. And to be honest, I think it's still going to be a great vehicle for them. It's a surprisingly good showcase for the modern C++ features. I'm actually being quite excited about it. But since this summer where I've had a bit less work on. I've picked that up again. It's been giving me a good opportunity to get back into Fultime Development. And I've developed it out now to, it's not quite a fully fledged framework, but it's, it looks very close. You can actually use it already. It does require C++ plus 23. Oh, that's why it's called Catch 20. Of course. Of course.

You do get there eventually, Tim. All right. So is that on GitHub, Phil? Can I use it today? So it is in GitHub. You can use it, but I wouldn't recommend it. Okay. You're really selling it. Not yet. It's still, it's rare mental, should we say. I mean, have a look there. You can see some of the test cases that are there going to feel for it. It mostly looks very similar to catch two, although there are some new ways of doing some things. The biggest change is the guts of it. The internal has been completely rewritten. I haven't just taken the... to codebase and said, how can we update this? Started again with a completely blank slate. I said, how would we do this with C++23 today? And it really is completely different. If ConsdExper is probably the number one biggest difference,

closely followed by concepts, or the two working together, if Concexper of concepts. So you've got no macros going on? There are still macros. Right. One of the things I did experiment with is offering a macro free syntax, and I did have for a while. I actually took it out just last

week after going backwards and forwards, because you actually get very little benefit from it, other than just knowing you can do it. But you lose something in the process, even still today. So we have source location, which covers some of the big things we had before, but

you still sort of lose things like when you say, you know, require an some expression, it actually shows a string version of the original expression. to report on. Without the macros, you can't do that. Right. So you would need to wait for CUSUS 29 in order to get reflection on expressions, right? Yeah. Or at least, I think I can get a lot of it from 26, not that bit in particular.

But there's a lot from reflection that we can get, that we'll make this even better. But I didn't want to call it a catch 26. Fair enough. Yeah. But one of the big things that is different, though, is the, the tags syntax, seems like a little thing, but it's just like an example of some of nice little things that drop out of this. If you use Catch 2, you'll know that you can put a second argument to your test case macro, where in a string, you put sort of square brackets and some labels, tag names in there. And then you can run all the test cases with a particular tag,

and you can do all sorts of combinations and things. And some of those tags are what we call control tanks, where they have a special meaning. Like, um, the hide tag says don't run this by default, you have to explicitly opt into it, which is really useful if you want things that are not strictly unit tests that you only want to run like a performance test or an integration test,

that sort of thing. Or to Marks having us, you know, this test actually should fail. So if it passes, that's an error. So you can do all those sort of things. So we still have tags and they still have all of those properties in Catch 23. But now the syntax is

real square brackets. using the new multidimensional indexing syntax. And then you can put strings for the tags, but for the control tags, they are now separate objects of the tech type, which means you get co-completion, you can sort of click through to, you know, read the associated documentation,

all sorts of benefits that come from that. You can also, you know, create your own versions that have the same properties. So even a little thing like that, because it opens up new possibilities. Where we go a lot further, though, is I've already implemented property-based testing. So not just generators that Catch 2 had. This is for generating random values to test with.

Oh, that's very interesting. We've always had that for a long time in Catch 2. The second part of property-based testing is that once it's found a value that fails, it will then try to find the simplest version that fails. So rather than some big number or some massive long string, they'll work back and find the simplest possible case that fails, which is usually going to be where your boundary condition is that introduces the error, and that makes it so much easier to find the cause of a particular bug.

So that is now in, and that's actually quite a big deal, I think. I'm also working on mocking built in as well. Lots of other things that are in the framework for the first time, they just made so much easier by having a fresh start on C++ plus 23. I think I've talked about it enough for now to give you a taster. I will put a link to the repo in the show notes. Go and have a look at it, but as I say, it's not quite ready as I speak now to using your own project, but by all means, do try it out and let me know what you think.

That is exciting. So it sounds like you're going to be involved in this project for quite some time and hopefully get it, you know, production ready at some point in the future. Yeah. Or is it more like an experiment tool, kind of? It's been an experiment, which is why I haven't mentioned it too much until just recently, but where I've done a lot more work on it, it's looking much more fleshed out. So it's not quite ready yet, but I'm going to try and use the next couple of weeks

before I go back to a full-time job to get as far as I can with it, because I know that once I'm working full-time, my time is going to be obviously much more constrained. So we'll say how far that gets. Hopefully I can open it up to external contributions as well. at some point. But yeah, I just wanted to take the opportunity while we have our last chance to do so, to mention it here. So that's an update on me. What about yourself, Timor, what have you been up to? So as username War Shrimp has correctly observed on Reddit a few days ago, I was

busy trying to stop contracts from being pulled from the standard again. This has been my life for quite some time now. And so it's actually quite interesting. I think, I mean, I mean, if I may take a few minutes to talk about this, too. Of course. I think we made a fatal mistake, kind of early on, after the last version of this feature was pulled from CSOS 20, we continue to call it contracts, or now we...