C++ Club - 171. WG21 Tokyo, next 30 years, WH safety report

Episode Date: April 14, 2024

With Bjarne Stroustrup, Gianluca Delfino, Jody Hagins, Frances Buontempo, Dmitry Kuzminov and Wenguang He.Notes: https://cppclub.uk/meetings/2024/171/Video: https://youtu.be/2GxSWFMEcLk

Welcome to the C++ Club. This is Meeting 171 and today is the 28th of March 2024. We'll start with some feedback. We've previously discussed both reflection and pattern matching papers, and Roy Barkan posted a hypothetical code snippet in a YouTube comment where he said, quote, imagine the combination of reflection and pattern matching, both having brackets in their syntax. And the function he posted was constexpr enum toring function, which uses pattern matching to match the value of the enum, and then uses reflection to generate the description as the name of that enum. So yeah, this is a good illustration of those potentially working together. That would be nice, wouldn't it? Looks a bit weird though.

We'll get used to it, I'm sure. The feature composition is usually the hardest problem. People can work on their little thing in isolation, then when it's thrown into the whole language, especially together with new features that are also being developed in isolation, you can get really strange effects. Yes, indeed. Another piece of feedback was a new name for the vowel language, which is now called Hylo. In my opinion, vowel sounded better and also more friendly to foreign language speakers, because it's unambiguous as far as the pronunciation goes. Hyla, though, if you don't know English very well, there are possibilities.

Is there a collision with some other names, perhaps? Some other language proposition that was also somewhat called Val or value or something. I don't recall. Is it named after a very wet town in Hawaii? Oh, I don't know, maybe. And also, the term that I forgot last time was Reify. Reify is to make something more real or consider it as real according to the Cambridge Dictionary. And in C++

reflection, it means to convert metatype to the actual type. So it's Reify and not materialize, as I said previously. Because I didn't remember it. Reify or Reify? Reify? Yeah, you're right i usually say ray if i like two parts but yeah again it's a weird two exactly i also mentioned while discussing pattern matching i also mentioned Rust and said I didn't know what

it looked like in Rust. And turns out it looks exactly like in the C++ proposal. There's an expression called match with the target of the matching and then calibrations and statements or expressions. So yeah, stole this from Rust, I'm sure. Maybe a common source? Or maybe great minds think alike? Let's say that's the case. Natural things.

Natural thing, yes. A listener called SM from South Korea sent a couple of quotes from the CISA paper on memory safety that I missed previously. They said, on page nine, there is a table illustrating short, mid, long-term plans, for example, in 5 plus years. Quote, companies use memory-safe languages for all new code with attack surface. MSSL means memory-safe systems languages. And on page 12, quote, encourage industry standards groups to take on memory safety standardization efforts. End quote. Thanks for pointing these out, and we'll talk about this a little bit later. But now let's discuss the Tokyo meeting. Committee trip report by Inbal Levy is, as always, very thorough,

and it lists all the papers that were adopted. She says, this was the first time since 2000 that we met in Tokyo. We were excited to have local members of the committee involved in this meeting. We are in Tokyo during Hanami season. That's the sakura flowering season, isn't it? We were also fortunate to feel a significant earthquake during the meeting. She then goes on to list the main C++ 26 features approved in Tokyo, which include papers like LuGin no discard policy, attributes for structured bindings, trivial infinite loops are not undefined behavior. That was accepted, which is nice. We did talk about this a few times. We did, yeah. And look, this one, erroneous behavior for uninitialized reads got accepted.

Interesting this one, right? That's a big one. That's the whole new thing in C++, erroneous behavior. Very interesting. Less transient constexpr allocation. C++ 20 introduced constexpr allocation, but in a limited form. Any allocation must be deallocated during that constant evaluation. All right. The intent of the rule is that no constexpr allocation persists to runtime, but the rule cited above does slightly more than prevent constexpr allocation to persist

until runtime. The goal of this paper is to allow more examples of allocations that do not persist until runtime, that nevertheless are still rejected by the C++23 rules. Delete should have a reason. That's a pretty nice thing for error messages. Variadic friends. That's a paper that participant Jody had authored. So congratulations and thanks for that. Yeah, thank you.

It was an interesting experience. Printing blank lines with Println, which is almost a bug fix. Like a no-brainer, one of those that you think, okay, why not? Formatting enhancements, formatting of the file system path, atomic minimum maximum, views concat, concatenation of strings and string views,

enabling list initialization for algorithms, which is a nice improvement. Debugger support. Is debugger present function? I guess that could be useful. This one is useful. Vector API for random number generation. So as far as I remember the paper said if you want a random number you probably want a bunch of them. So it makes sense to generate them into a vector, for example. There was also the consideration that there's a lot of instructions that can vectorize these operations of generating random numbers, and using this interface that he proposes, or they propose, and know who the other was, then you could optimize the generation of n random numbers into floats or into std arrays or vectors, I guess, and make it more efficient.

Other papers were comparisons for reference wrapper andference Wrapper and Padded MD-SPAN Layouts. but never directly involved. I would encourage people to get involved if you have any ideas about stuff. Even if your proposals don't get accepted, it's an incredible learning experience. It's an extremely enlightening process to go through. So I would encourage people to get involved in some aspect of this if you have anything that you think might be beneficial.

Yes, thank you for that. Now, Language Progress Evolution Working Group spent an entire day discussing Reflection, and I'm really glad to see that. They provided lots of feedback, very positive response, making good progress towards C++ 26. Also an entire day was spent discussing contracts. And Inbal writes, significant feedback was given to the group, though the polls show a significantly divided committee which might have difficulty reaching consensus. I think I've seen that before. P2900 may be minimal, but it is not viable. A set of sustained objections from Microsoft were provided and discussed. Yeah, that was an interesting day to be involved in.

And you definitely could, even if you were just a casual observer, you could see that there's a big divide between people and their ideas of what they want for contracts. And I'm not really sure how that's going to be resolved. The key issue is whether you can have contracts and still have time travel or UDP. That's where, again, from Microsoft, is hitting the problem. I have seen some examples where you have a perfectly good contract, except that it never gets executed. And that kind of stuff is paranoia-inducing. You can see the test there, but it doesn't execute. So I'm not worried about that.

So do you think there's a possibility that they can come to some form of contracts that sidesteps this big divide divide that's there i don't know i was optimistic for 20 and everything crashed in the last minute it's still scheduled for c++ 26 optimistically so hopefully they will come to some common ground. A half day was spent discussing pattern matching. Whey! The match expression paper. An update was provided on the design, and feedback was given to the authors.

An updated implementation will be needed soon if you want to have pattern matching in C++ 26, end quote. So that paper was submitted just before the Tokyo meeting so that it can get discussed and go in hopefully 26. But yeah. Yes. And so there's still a fair number of really big things that are in EWG. What I found interesting was at the plenary, CORE issued a warning of sorts, or just basically saying that time is getting short

for getting things through CORE to make 26. And so some of these things that are still being worked on, some of them are in CORE now, and some of these big things like still in EWG, they need to make progress. Otherwise, they basically said they might have time for one big last minute thing to get through, but there's a number of big things still working. So they kind of encouraged people to make significant progress in the near future. Yeah, that makes sense. make significant progress in the near future.

Yeah, that makes sense. There were lots of bug fixes reviewed. Also, seven papers were forwarded to core working group, including module declarations shouldn't be macros, trivial relocatability for c++ 26 a delete should have a reason was forwarded for inclusion in c++ 26 various other things concept template parameters sent for inclusion into 26. That looks nice as well. It's one of those things that if you do use template metaprogramming,

you want to have, I would guess, that would simplify a little bit your code. There was a paper called Initialization List Symmetry. No idea what it's about, but this thing also had support for base class trailing commas and sent for inclusion into c++ 26 i think are you interested in knowing what that was basically this was this was probably the most uh uh discussion that went the most different directions basically what this says is in in yourizer list, they want to be able to have to end it with a comma, like in a, in an array definition, you can end the last thing with a comma. So they want to have the comma be able to end that thing. And so it basically got into a bunch of discussion with people talking about what they want their

code to look like. Um, and, uh, whether they liked it or thought it was ugly or not. Um, the bottom line basically came down to, it's easier to do this with, with learning people that are learning C plus plus. Um, and this is a problem. Um, and it also like gets better diff. And so the census in the initialization list, that part about the base class was that they want to be able to do it when you have your base classes as well. You can, you know, you have your colon and whatever you can end them with a comma so that

was what that's that's what that whole paper is about and this is apparently this is the third or fourth time this has been proposed oh it is much better than to put comma in front of uh the variable that's also the same issue but this is much more convenient. This is not a consistent number. Therefore, you can never make progress. Yes. This comma

before the curly brackets actually is not consistent with the rest of the C++ syntax. You cannot do this type of thing brackets actually is not consistent with the rest of the C++ syntax. You cannot do this type of thing in other places, right? So if you want a language to be consistent, the syntax has to be consistent everywhere. So I don't think it's a good idea to add a comma there.

I'm sure they'll get to the other places as well in time. And there are places when that is possible. For example, enums, the same. So there is inconsistency already. Or there is inconsistency already. Slightly smaller inconsistency now, hopefully. Nice. I like it. It goes back to the old debate in the Fortran kind of languages, whether the semicolon is a terminator or a separator. People have been arguing this for at least 50 years. That's

why I'm not getting all that excited about it. Right, so a bunch of papers sent back to Yuji from Core. Some amendments to Trivial Infinite Loops paper. They wanted to remove the yield forever. Structured bindings can introduce a pack. Some changes to that. Erroneous behavior for uninitialized reads. UG agrees that erroneous behavior may create values which later trigger UB. For example, an erroneous behavior read of a pointer has a defined value, but dereferencing the pointer may then be UB. Lots of papers received feedback, some papers did not have consensus, array element initialization via pattern expansion and postfix fold expressions. Some papers didn't have sufficient time to be seen, but I guess there's still hope for those.

So a massive amount of work done in that meeting. Right, library evolution features approved permit an efficient implementation of std print. Again formatting of std file system path and some guaranteed copy elision. She mentions again progress on large features, reflection, contracts. Other library features reviewed. So this paper we looked at as the adoption of tref got reviewed. Maybe it gets in this time, who knows. That used to be a source of controversy, but this time maybe it'll work. There's quite a lot of activity in the concurrency and parallelism study group SG1.

They met most of the week. Starting to see new post-P2300 content, like for example asynchronous parallel algorithms, parallel range algorithms. Networking met and discussed a proposed direction for C++ standard networking based on IETF TAPs. I don't know what that is. What is it? Transport services. Okay. Quote, we encouraged further exploration in that direction, as it will help us generically wrap networking stacks provided by operating systems and sender-receiver compatible APIs.

So everything goes back to the sender-receiver paper. There was an update to the release schedule. She says treat it as speculative and tentative. So we have big features, senders, current target optimistically 26, conservatively also Networking 2629 Linear algebra is approved So it's getting into 26 SIMD 26 Now contracts 2629 Hopefully Reflection 2626

So I don't want to say guarantee We don't want to jinx it We don't want to jinx it. We don't want to jinx it. We don't want to jinx it. And patent matching is still listed as 26. The reason Reflection is doing so well is that there's a very good guy pushing it. David van der Woorden. That's often the case when something actually moves forward. It's not an endless negotiation. And people have sort

of joined up behind him. That happened in the meeting before last. I was cheering wildly. This is really good news. And thanks to David. David has been working on this since 2005, if you listen to some of my long-term talks. Yeah, it's quite impressive. And 26, sorry, and pattern matching is 26-29. I lost all hope for a while, but now that we have a new paper, maybe there is still hope for it to be in 26. Which one of those things do you think will have the most influence on the stuff that you guys do, like all of you guys? Which of those is going to impact what you do most?

Probably reflection and pattern matching. Yeah, it depends how you look at it. I would put my bets down on pattern matching because it has the greatest interface to the most people. But at a deeper level about what libraries we will get sometime after, we start putting the bets on things like reflection and senders-receivers. It's aimed at different populations, really. Pattern matching is aimed for everybody.

Reflection, I'm not quite sure I want to see everybody do. Yeah, I'm not sure we want everybody modifying the AST at Compile Time. Exactly. That can freeze the language badly so that you can't update it later. That happened to Scala. So yeah, a great meeting and a great review. There was also a trip report by Herb Sutter, which is really thorough. He basically repeats all the papers that were adopted, mentions them, and does the summaries. There was also a trip report by Jonathan Müller, but it's a short one with just a few papers. So yeah, I'm very happy with how things are progressing and I'm full of hope for 26. A quote from Herb's article.

We all probably suspected that pattern matching is a ground-shaking proposed addition to future C++, but in Tokyo, during the pattern matching session, there was a literal earthquake that briefly interrupted the session. Must have been exciting. Not more exciting than pattern matching, I'm sure. There was a bit of feedback that I saw earlier in one of the emails on Papers GitHub about the paper called Principled Design for WG21 by John Lakers and others. And the quote was this. The method suggested in the paper got support, even though some

issues occurred. First, questions regarding the need for such a method, as we already aim to have similar considerations with the existing proposal structure. And second, question on whether this can create too much of an overhead, especially for small, medium, non-controversial topics. There was a concern that the classifications proposed may be biased and affected by opinions, and therefore the grades may be biased, as the grades and importance may be affected by one's assumptions." Probably will be discussed further at some point.

Now, the next one was an article by David Sankel called C++ and the next 30 years. It was a keynote that he presented in China, I think. Yeah, I think so too. It was presented at the previous standards meeting as an evening session. Right. It didn't get a very strong positive response. I was reading it and there were some quotes that I had some thoughts about. Like this one. In the next 10 years, I expect C++ modules to become more accessible.

Most C++ vendors have at least some support and CMake recently announced its feature set. However, transitioning existing code bases and in, in many instances, bespoke build systems will be a great obstacle." I think I agree, and hopefully CMake will be gradually phased out in favor of other build systems. Yeah. Is merging CMake publicly? I find that people are big players are playing the modules, being optimistic, including the

library and system vendors. That's where it's going to take the longest time. If you have a business that is shipping to all implementers and all industries, you have a big, big problem. But some of those guys are already experimenting. And I have, of course, been a little bit disappointed about how slow the progress has been. On the other hand, it wasn't unexpected.

I think the phrase was fiendishly difficult that I used on my slides. Was there a recent post on RCPP about import STD finally being production ready for MSVC? I think so. Yeah, I think I've seen it as well. I wonder how many people are using it though. Many people are still using old versions of Visual Studio. Not all of them are on cutting edge. Quote, in the C++ feature department, we can expect static reflection, pattern matching, contracts, and sender-receiver to become available over the next decade.

Yes, please. The next quote was, AI-assisted coding is following the well-trodden Gartner hype cycle where inflated expectations precede an ultimate plateau of productivity. While we are thankfully past the idea that AI-backed productivity gains will result in massive software engineering workforce reductions, I don't think it is yet clear to what extent AI will improve software development productivity." Evidently, the management has not yet passed this idea, as layoffs continue in favor of transition to AI. That is a problem.

There was an interesting video from Alex Andreescu, I think last month. Maybe we talked about it. He goes through creating and improving Quicksort algorithm using as a companion. I don't remember which one. This was ChatGPT4, I believe. And it's very interesting. It's an hour and a half. Highly recommend it. Right. Next quote was, another major factor over the next 10 years will be the growing usage of

Rust by C++ developers. End quote. You know, I can see that. At the standards meeting, essentially everybody jumps on his numbers, not just this one. It's very hard to get good numbers these days for just about anything of importance. And certainly he didn't get a lot of buy-in for the numbers. I mean, just from the point of view of expanding one's knowledge, learning another programming language is useful, if only to compare different approaches to things. Like, for example, when there is a ready discussion about C++ versus Rust, there's always someone, one or two people, who provide sensible comparison of features between those two languages

and what's good and what's bad for each of those. And what is a feature? There's a lot of people that compare language features as opposed to what you see when you actually write code. So I remember one person on one of those threads compared their experience in implementing a game engine in both languages and basically said something like,

some things are easier in Rust, but implementing the overall machinery and data structures was much easier in C++ because Rust's generic programming is not as powerful. And also, in many cases, you have to fight against Rust's borrow checker, like when implementing self-referencing data structures, for example.

So it was like a calm and sensible post-mortem of their experience with actual code. Most discussions like that are full of noise, unfortunately. Another quote was, One might wonder if today's C++ successor hopefuls, Hylo, Swift, Cpp2, Carbon, Zig, Mojo, and Rust will gain more traction at this time. And I was like, C++ successor hopefuls? Putting established production languages like Swift and Rust side by side with language experiments doesn't sound right to me. Yeah, that doesn't sound right to me either. But one of the things that were more surprising to me is I never really considered Swift as a C++ successor. What am I missing there?

It's not. It's a new language. It's not even successor to Objective-C. I think it was supposed to take over the Apple world, but it didn't. Right. Then he says, C++ will remain important in niches. Companies with large existing C++ code bases and surrounding software assets, no one wants to rewrite. And to me, that sounds like quite a lot of niches for C++. It is a bit reductive. Yeah. I think it's a safe bet to say that it will stay for sure in those niches, but hopefully

not only. After all, it wasn't forced into those niches. We didn't have a marketing organization. Yeah. Then he says, in the 10-20 year time frame, a few industry shifts will start to take hold. First, memory safety legislation with make usage of C and C++ for new projects require special justification and oversight. Safety critical applications will see C++ entirely phased out, end quote. And I thought, yes, legislation will solve everything. Just pass

a law to forbid C++ and say automotive industry, embedded systems, military or space exploration, boom, solved. military or space exploration boom solved that pr could influence uh c++ badly anyway so we do we do need you know like even though most of this c slash c++ uh nonsense it's uh obviously something that uh could be addressed uh in a way another. We still need somehow to spread a positive message about C++ in a way that we convince the gut feeling of the general public that we can still use C++, we don't necessarily have to abandon C++. So, I don't know, it's a PR problem I still don't know how to solve. It's hard because other people have hype machines and other machines don't have just about everybody knowing some of the problems with the old stuff. The new stuff, of course, have no problems,

right? That's the way it's presented. We couldn't do that. I mean, that would be lying also, but one, we don't do it, and two, we would get caught. One, we don't do it. I never did it, so it's not just because there's something out there, but people know what C++ can be. A lot of people know what it was 20 years ago and think it's still like that. That's what we have to work on. We should just change the name. Keep everything the same. Change the name. That has been suggested a couple of times. As silly as it sounds. As an aside, it might be worth

reminding people that if they think AI is going to overtake the world loads of people are using like Python and just chucking together a couple of lines to do some AI stuff mostly statistics realistically and so much of the AI

libraries are written in C++ alright there may be some of the love libraries are written in C++. Alright, there may be some of the Fortran stuff there as well, but so much of the fundamental underpinnings for all the AI that's going to replace all of us is actually some of us still writing some

C++ code to give you the easier interface to the AI things. You want some maths? You probably want Fortran or C++. Sorry, Bjarne. I was out in the Data Sciences Institute at Berkeley a couple of years ago. Their estimate was that 97.5% of their workload was C++, but their interface was Python. Quite.

I mean, maybe you should start referring to Python as our interface language. People would not like that, but it would be correct. Python is C++ with extra steps. Too many extra steps. My impression for all these discussions is, you know how the arguments go on the internet. You're not going to convince the other side that you are right. It'll never happen. I think this is the case with all these C++ in unsafe discussions,

both sides have made up their minds. And whatever we say, whatever anyone says, they will remain in their own camps and basically persist. It's not going to be like, oh, so modern C++ is safe. okay, I was wrong in bashing it. That's never going to happen. So the more I read about those discussions and arguments and white papers from the government, the more I think that for me it's just a waste of time. I become tired of those arguments and discussions. I want to write C++ code. Anyway, back to the article. There was this quote. Software engineering as an engineering discipline

will mature with regulatory oversight, inspections, and enforcement of best practices becoming commonplace. I think that's the funniest sentence of the entire essay. More paperwork.

That's what they think of as sound processes. And then he says, finally, on the application side, AI will become the dominant form of human-computer interaction. Pressing X for doubt. Then he says C++ in 20 to 30 years. This period is difficult to predict, but the world will likely remain highly dependent on complicated and memory unsafe C++. Didn't he say it was going to be phased out, what with all the legislation and stuff? You always get more time if you make outrageous statements. It's one of the ways to get popular and to get up in front of a lot of people.

And the next quote goes like this. However, rather than people, AI will be doing most of the coding. It will find and fix defects and will trust it to do so. No, I take it back. This is the funniest sentence of the entire essay. A probability-based autocomplete trained on poor quality code will suddenly create new good code and fix defects. Sure.

Maybe this paragraph was written by Chad GPT. Yeah, there was some study about using Copilot, and they found that people wrote the code significantly faster, and it had significantly more bugs and security violations. Now, unfortunately we don't have much time, but I was going to discuss back to the building blocks, a path towards secure and measurable software, the White House report on memory safety. There's quite a lot of links and quotes. I wrote one large paragraph on it. Yeah, it got mentioned on the InfoWorld, I think. Or does Falkrill provoke me to do it? Hmm.

I don't do such things I'm provoked. Yeah. So you said, quote, I find it surprising that the writers of those government documents seem oblivious

of the strengths of contemporary C++ and the efforts to provide strong safety guarantees. On the other hand, they seem to have realized that the programming language is just one part of a tool chain, so that improved tools and development processes are essential, end

quote. Strangely, though, the subtitle says, Biden administration seems oblivious of the strength on contemporary C++. Nice work, Mr. Krill. It sure seems like Biden's fault. Could I share a screen with you? Sure. I just wanted to show you this thing that appeared in Spain yesterday.

What is this? I'm not sure. C++ above the White House. It's a question that you raised with the White House paper and my answer. It sounds like

a Jedi with a C++ sign on it. Something like that. In the White House. It appeared in my mailbox as part of a large article, by the way. If your Spanish is good, you can read this. I'm sure it was created by AI programmed in C++, so that checks out.

There were many quotes from various discussions of this document and the responses to it. One of the Reddit quotes went like this. I really respect Bjarne Stroustrup, but... And I thought, oh boy, here we go. And then they continue. He seems to not understand the fact that the problem is not in

the language, but in the programmers who are failing to keep up with the pace of learning the safety features of C++. So he just wants to change 6-7 million people to do things the right way in an area that isn't easy?

Yeah, someone said that there's now a meme. Just rewrite it in Rust. Another dream. I heard that about Java, by the way. Is Java in the list of the approved languages, by the way? I think so. It's got memory safety, so they should put it in. They forgot Ada to start out with.

They said that memory-safe languages include Rust, Go, C Sharp, Java, Swift, Python, and JavaScript. JavaScript, hey! Exactly. The interpreter is written in C++. But safety, come on. JavaScript was never intended for writing server-side applications. And now look at the modern web. I'll include more links in the notes. There are many rebuttals of the article and many sensible people basically saying the same thing that you, Bjarne, said.

That's good. Where do you find this? Oh, on Reddit? There are discussions on Reddit and Hack News and on Slashdot even. I'll gather the links and post them into the notes. There's even a reaction on Slash dot even. I'll gather the links and post them into the notes. There's even a reaction on slash dot.

And the first one says, It's a brave new world. I for one welcome our new government authority to micromanage things it never understood. Most articles are pretty sensible. This one, PC Magazine, White to developers using C or C++ invites cybersecurity risks. Several people pointed out that those languages that were listed as safe, many of them have runtimes that are communicating with operating systems which don't provide safe APIs.

And the runtimes are also written in C++ often. Not many of the languages are self-hosted. The things I've discussed in my talk is the problem of communicating between parts of software with different safety guarantees. That's a non-trivial problem. Or do you get the graphics system, the operating systems, a lot of the high-end communication software, not to mention some of the device drivers. Yeah. Steve Klabnik, who is a Rust developer, says, your operating system does not offer memory-safe APIs.

To do anything useful, you must call into the operating system. This means every program would be infected via this conception of safety, and therefore, as a definition, it would be useless. If we instead make an exception for a language's runtime, which is allowed to make unsafe calls, but uses code is not. That would draw an appropriate boundary. Only write code in the guest language, and you don't have to worry about safety anymore.

This is the approach, black box approach, in the sense that just don't look into it and assume that your code is safe. And don't worry. We promise. I once got a job off of my BM Yorktown Heights to work in security. And they showed me something they were very proud of.

And I pointed out that I could just dive in under them into the operating system and break their whole work that they've just worked for several years about. They were good PhDs. And they say, oh, no, the rule is that we have to assume that's correct. Yeah, that's cheating. I concluded that I did not want to work in the field. We are radical security.

And there was another interesting article called The White House Memory Safety Appeal is a Security Red Herring by Maya Posh. And one of the quotes was, putting the focus on memory safety is more than a little suspect when the worst CVEs come from programmers not putting in basic checks for path traversal and forgetting

to fully check user credentials. What is also worrying is the complete lack of any reference to the favorite language of the military, medical, and aviation fields where things going boom prematurely is generally considered a bad thing. ADA. Like you said, they didn't mention ADA at all. I pointed that out on the very first one. Yeah.

As an example of we had language people here as opposed to serious systems people. And then she concludes, this is perhaps why the ONCD report feels so wrong, as it contains none of the lessons of the past, nor the hard-won experiences of those who write the code that keeps much of society up and running. You can almost hear the cries of many senior software engineers as they wonder whether they merely chopped liver

in the eyes of government organizations, even as said organizations are kept running due to countless lines of ADA, COBOL, C and C++ code. Never mind the security researchers who despair as basic input validation is once again ignored in favor of buzzwords pushed by a couple large corporations." End quote. So all in all, I thought that the general vibe of the comments after this white paper was more positive towards C++ than before. So I guess your efforts, Bjarne, and the efforts of other C++ programmers and members of the committee are starting to work, hopefully. Let's hope so. I want to see some experiments at scale

to show that it actually works. Without some code running, we don't have really good credibility. And I don't have a development team, so I can't just go and do it myself. Yeah. We're a little over time, and I think we'll end here, and I will leave you with this Mastodon quote by Ash.

Why do you have a messy pile of clothes in the chair? It's an L1 cache for fast random access to our frequently used clothes in constant time. And here's another one for you. Cast random access to our frequently used clothes in constant time. And here's another one for you. Embedded software development is when you write software in your bed. And on that note, thank you very much for coming. And I will talk to you soon.

Bye. See you. Cheers.