Algorithms + Data Structures = Programs - Episode 48: Special Guest Dave Abrahams!

Episode Date: October 22, 2021

In this episode, Bryce and Conor interview Dave Abrahams and talk about C++Now (aka BoostCon), C++ and Swift!About the Guest:Dave Abrahams is a contributor to the C++ standard, a founding contributor of the Boost C++ Libraries project and of the BoostCon/C++Now conference, and was a principal designer of the Swift programming language. He recently spent seven years at Apple, culminating in the creation of the declarative SwiftUI framework, worked at Google on Swift for TensorFlow, and is now a principal scientist at Adobe, where he and Sean Parent are rebooting the Software Technology Lab.Date Recorded: 2021-10-03Date Released: 2021-10-22C++Now (formerly BoostCon)Swift Programming LanguageC++ Move ConstructorsBoost C++ LibrariesC++ Standard Template LibraryStepanov WebsiteChris Lattner on TwitterJeremy Siek’s ProfileRust Programming LanguageC++ std::mutexC++ std::shared_mutexThe Day The Standard Library Died (blog that mentions std::string ABI break)Intro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

The STL, in my opinion, is a singular work of genius. What do you think it was about the STL that made it so novel? A sense of searching for some underlying truth. Yeah, no, no. We have more time than that because it's just my mom and I do yoga twice a week, as Connor knows. Oh, that is very cool. She's pretty flexible. Wow.

Good one. Good one. Welcome to ADSP, the podcast episode 48 recorded on October 3rd, 2021. My name is Connor. And today with my co-host Bryce, we have on special guest Dave Abrahams. And we talk about how C++ now aka BoostCon got started and his work on the C++ and Swift programming languages. Well, you know, it's funny, the one of the things that I am best known on the committee for is my my passionate speech for why we should not standardize the 2D graphics library. And during that, I said at some point we have to draw a line, let's draw a line about like what we're going to include or not. And I did not mean for it to be, you know, a cute pun, but everybody in the room just groaned.

And people, you know, I got such praise afterwards for my cleverness that I was like, I just want to tell people. Of course, now I've ruined it. Only for our listener. our listener, yes, our listener who, who may or may not be a fan. Um, all right. So it's a kind of, I guess you should do a little bit of an intro. So this is, this is how I was going to start. This is say that, uh, Bryce, you've known Dave. Um, I mean, Dave and I have, I think, peripherally seen each other on Twitter. I don't think we've ever actually spoken in a meeting directly to each other. Although obviously I know who Dave is by reputation.

So I think we should let Bryce do the introduction of Dave. And then the first follow-up question will be, Dave, take us back to whatever year you want to take us back to, to give us the, I'm super looking forward to hearing the history of everything you've been involved in. Cause as folks that are familiar with Dave, I won't spoil Bryce's introduction, but you've worked on a ton of cool projects, started conferences, et cetera. And you've, you've, you've definitely been around and um yeah so i i uh i'm super excited i've been looking forward to this to to get to hear the behind the scenes of not just the the

the bullet points but um yeah so bryce i'll throw it to you and then and then we'll throw it to dave i'm i'm i think i'm i knew dave from like my earliest days in programming because i got involved in boost very early on. And that was the time that Dave was, you know, was still Mr. Boost. And that was, you know, when, when Dave was working at boost pro, but I think we first must've met at boost con 2011, which was the last boost con before it became C plus plus now. Yeah. Cause that must've been where I met Dave first. And,

you know, all the other C++ folks, John Kaub, Marshall Clow, you know, everybody else who I've known now for like 10 years. And then, you know, I guess, Dave, how many years after that did you go off to do Swift? I started that in 2013. Yeah, yeah. So it was two, yeah, because you were at the first C++ now, and then you departed. And I guess I didn't have the full perspective at the time because, you know, I wasn't on the C++ committee. I didn't, you know, I wasn't involved in C++11, but, you know, Dave was a, you know, a large part of that.

But then went off to- Sorry about that. We talk about Lambdas are amazing. Went off to build Swift. Yeah, I didn't have anything to do with lambdas. I gave you the static exception specification thingies, the no-throw things, and move semantics. Yeah, move semantics are big. Yeah, they're big. I would argue the biggest feature in C++ 11.

Yep. What about auto? Sorry about all of that. I made some mistakes. So I guess maybe, so I think this is actually an interesting place to start because I heard a story about the origin of Boost at some other C++ event recently. And I'm not sure if it's historically accurate. In particular, it was regarding the origin of the name of Boost. Yeah, well, so you know I wasn't there. I mean, I've only heard the story secondhand also. You weren't there? I thought that- I wasn't there when Robert Klarer and Beeman Dawes had this conversation.

Oh, for some reason, I thought that you were one of the folks that was there that was one of the initial founders. Well, I mean, I was involved immediately after that. But this first conversation that they were having, Yeah, I wasn't at that. So when was that? I don't remember, frankly. Let's see. It must have been just after 98 because we standardized C++. And the reason that Boost came about was that Beeman, who was really was a groundbreaking piece of work, but it was also not the way we were supposed to do things. We were supposed to be standardizing

existing practice stuff that had actually a best marginal use at that point and in fact they you know based on what Alex Steppenup said he needed there were a bunch of features added to C++ that no compiler had even implemented yet when we standardized C++. So, yeah. So we didn't want to repeat that. And so Beeman's thinking was, let's get some libraries out there that are high quality, standardizable, and go into wide use.

And they're basically try to lower the barriers to entry as much as possible so that a lot of people use them. And I think we succeeded in that. Boost seems to be everywhere. Yeah. Well, not only is Boost everywhere, but a large chunk of the C++ standard library additions in C++ 11, 14, 17 all came from Boost libraries. Although it's interesting, you know, the point that you make that standardizing the STL was not really what the committee was supposed to do because, you know, it was successful. It was a risk, but it was successful. And, one of the frustrations I've had with C++ committee is the, is a kind of unwillingness to form a consensus about, about how the committee would operate and, you know, how bold to be what, you know, how important is breaking code, how important is

performance, any of these kinds of decisions, you know, to set a framework for future decision making. No one has ever wanted to do that. And, and that's, I think, a major, a major problem with the committee, but in fairness, with respect to being too conservative, you know, the STL in my opinion is a singular work of genius. I mean, you know, it has in, you know, with how many years has it been since it came out? 20 years? With, let's see, 98 to 2021, 30 years. Okay. With 30 years of hindsight, right? It's definitely, you know, I would have designed some things differently. It's got some ugly corners, whatever, but, uh, you know, those things worth gambling on like that come along once in a

generation, maybe. Yeah. Yeah. I certainly think that's true. What, what what what do you think it was about the stl that made it so so novel or or what what what is yeah what what made it so novel or successful or so so genius well i mean you know alex stepanov uh you know you don't need to say much more than that. If you've, if you've heard Alex talk and, and really know about what he, what he knows about and what he thinks about, I mean, aside from being an amazing polymath who, you know, can read things in the original ancient greek um and uh his he i think the the fundamental thing that

that he brings brought to the table that i've you know carried with me ever since i i met him is a sense of searching for some underlying truth, you know, rather than, rather than designing something, you know, Alex, the genius of the STL was that Alex didn't say, you know, I'm going to come up with a beautiful design that's, that accomplishes these things. Look at what I've done. He says, look at what's actually there in, in the world. Let's find, let's generalize from that. And let's, let's find the, the actual abstractions that are there. And that's a kind of humility that he brought to design that I think is, you know, really crucial. Yeah. And so, as we said earlier, in 2013, you went to join Apple and you got started on this, you know, this new project Swift. Um, and so what, uh, what was that like? You know, you,

there aren't many people who can say that they were at the, um, you know, the, the real, the start of a language that has grown as quickly to maturity as Swift has. And yeah, so maybe tell us a little bit about your experience with Swift. Yeah, well, I mean, it was a once in a lifetime opportunity for somebody who's interested in language design, you know, because languages do come along every week and they die in obscurity. So, you know, so if you've been around a few years and seen this, you only want to get engaged in a in a language project if you think it's really got some legs.

And, you know, this one had Apple's future behind it. Apple was staking its future on it, although to what extent wasn't entirely clear in the early days. Um, uh, and it had an amazing group of, of people, uh, that I had faith in, you know, starting with Doug Greger, who was my close friend. Um, and, uh, yeah. So what was it like? It was, uh, it was a thrilling adventure um you know um there it was you know it was scrappy we had a a group of about 10 to 12 i guess uh that maybe wasn't even the the starting size might have been like eight.

But, you know, Chris Lattner, to his credit, ran the thing very much by consensus as much as possible. And while, you know, some people denigrate design by committee. I have always found that the process of coming to consensus inside the C++ committee for example, has been more beneficial than, than harmful. Um, and so we had a lot of fights about things. Um, uh, we all learned a lot from each other. There was an amazing amount of, uh, of different experiences in the group. Um, yeah. And, and it was, it was a thrill, but when I got there the the language was uh extremely immature it was almost impossible to build anything generic um with it and and uh yeah so so the first the first few months i would say were quite frustrating because of that. It made it really hard to make progress.

And it was good to be part of the design discussions and move the design forward. So that was great. But I was also responsible for the standard library. And how do you build a standard library on a fragile foundation that barely works? Um, uh, and, uh, at some point, uh, you know, the, the pressure of not delivering anything became too much for me and I, and I decided, okay, I'm just going to do what I have always done with broken C++ compilers, which is figure out how to, you know, coerce them into doing what I need. And who cares if it's beautiful or even correct, you know. So that got me over a hump.

When I was first able to build an array. That was something. Yeah, I mean, I guess it really is early days of building an array is, you know, is a challenge. And you were involved a bit in the design of C++, of Swift's generic system, right? A bit. Yeah, definitely. I had some influences, especially later on. I would say that a lot of the inspiration for the initial design of the generic system came from work that Jeremy Seek had done on something called System G, I think. And basically what he was doing, as far as I understand it, was building a generic system with separate compilation. And in the sense that Haskell does it, except with associated types,

which at least standard Haskell doesn't have. And, and I think Doug took that as, as a foundation. And part of the reason that was so important at Apple was, or for Swift, was that Swift needed to not lose the one really killer quality that Objective-C had for Apple, which is this ability to upgrade either side of an interface without breaking code. So, and without recompiling. A challenge that continues to plague the C++ ecosystem and the evolution of C++. Yep. Yeah. So that's what they called resilience or ABI resilience.

And so to do that, you have to be able to separately compile generics into something that doesn't change when you invoke them with different parameter types. Yeah. I mean, I think this part of Swift is a really good example of, we have some talk in C++ about the ABI problem. And some people are like, well, we should just go and break ABI or not break ABI. And it's almost, the conversation is usually one that makes it seem like it's simply a policy question. To me, it's never, it's always seemed like there's been a missing discussion about the technical limitations that we have that, you know, we don't really, it's not something that was the language was designed for from the ground up. And who knows, maybe it's not too late to bring some sort of resiliency to C++. But I think

it's much easier, of course, if you design it from the start of your language. You know, one of the problems that would come from almost any form of resiliency that we'd add to C++ is, would it have some cost over doing things the non-resilient ways? And if it did have some costs, then how would you get people to buy into using it? And one of the problems, of course, is that some people who are making the choices that will impact whether or not you can change your ABI, they may not realize when they're writing their code that they needed resiliency. Yeah. So all of these things are real problems for Swift too.

I mean, ABI resilience at generic boundaries is a definite performance cost because what it means is that you end up with some kind of dynamic dispatch. Even though it's static polymorphism, you end up with functionally, like in the implementation, a dynamic dispatch that chooses one implementation or another based on the input types. Now, one thing you can do to mitigate some of that is to have a JIT, right? Or some kind of late recompilation that erases the cost at the resilience boundaries. But regardless, you have to think of it, every resilience boundary with polymorphism behind it, even static polymorphism has a virtual function call.

And, you know, one of the things that generic programming depends on being able to hide very small operations like the increment of an integer or a pointer behind an abstraction boundary, whatever the concept requirement is in C++ terms. And so when you pay the cost of a dynamic dispatch for tiny operations, your code gets a lot slower. So there are all of these halfway points that you can get into with Swift with regard to things like saying that this thing is inlinable. If you say it's inlinable, then the resilience boundary goes away. But then again, you can't change it. Right? Yeah, yeah. And I think the whole question of library evolution is something Swift hasn't yet really addressed.

It's addressed the problem of how do you build an ABI so that you can extend a struct without breaking code. But there's a whole universe, I think, of tools and processes that library developers need to have in order to be able to effectively evolve their libraries, which I don't think Swift has done anything to actually dig into yet. They've had a lot of other stuff on their plate. Yeah.

I was going to say, is there a language that you think is the good archetypal model for those kinds of tools? Oh, no. I don't think, as far as I know, nobody has really tried to figure that out. And I think starting with the ability to create ABI resilience is important. So I think Swift is in a unique position, at least of having that as a platform. But yeah, I think there's a lot of work left to do. I mean, yeah, a lot of languages, including a lot of new languages you know struggle with this i know that right now in the rust world there's a lot of conversations going on about abi um uh resiliency and um i'm gonna badly summarize my understanding which is that for a long time the model and

rust had essentially been we're not you know we don't provide, we don't worry about ABI stability. And now there's maybe some question that there's some folks who might want that. And they're trying to sort out how exactly would they do that, especially in a world where they sort of statically build everything. Yeah. Yeah. Well, one interesting answer for for performance oriented languages like C++ and Rust is tell people how to build APIs that can be extended and give them some guarantees,'t don't make that the default. Right. Right. So there are things that we do in C++ all the time, which we get from C, you know, you build a C interface, you, you dynamically allocate your struct,

then you can extend the struct anytime you want. Those kinds of techniques actually work in practice to some extent. They, parts of them may be guaranteed. I don't know. Yeah. Like a good example of this in C++, which is, would be like std mutex. So on, on MSVC, their std mutex so on um on msvc their std mutex implementation is like it it's eight it's 10 times larger than their std shared mutex and it's like two times slower and the reason is because their std mutex has to be be abi compatible back to like the windows x mutex layout, which is like this huge thing that uses this

very old API. Fortunately, no one should ever use a mutex. Yeah. But it would have been a fairly simple thing to avoid this problem if they had just, instead of having the, the, the, you know, the, the metadata for that mutex be just regular data members of std mutex, they could have just put it in some opaque struct and just had a pointer to it. It's just that when they did their implementation, they didn't, they didn't make that decision. And there was, you know, there was a trade-off to that at another level of indirection.

But I think it's something that we perhaps should have designed for more consciously when we, when we first started standardizing C++. Yeah. Yep. Well, I mean, that's, that's up to each individual implementation, right? Yeah. Were you around when the infamous stud string ABI break came through the committee? I'm not familiar with this story, so at least not in those terms. This was, so in C++11, we changed some of the complexity guarantees on std string in such a way that it prohibited the GCC copy on write implementation

from conforming to what std string was. Oh yeah, I think I remember, I think I remember lots of complaints about the, about the, at that time, I think I remember people saying that you couldn't actually make a copy on write implementation conform. Right. Right. It, what, what, what's interesting to me is that, uh, everybody who I've ever talked to from that era doesn't remember it as being a controversial thing at the time that the requirements were changed. It was only afterwards that we realized how significant of a change it was, that think that it ended up slowing down adoption of C++11 because if you upgraded to C++11 to the, you know, the compliant C++11 std string, it would, you know, it would be an ABI break and std string gets used everywhere. And I think it's just, you know, it's, we would never today in the committee, we would never make such a change because we've become super sensitive to ABI changes to the

degree that almost any proposal that would in some way, shape or form break ABI is a non-starter. But, you know, it wasn't always that way. We just didn't know, we didn't realize what the costs were at the time. Well, at least, I mean, to your credit now, I guess at least there's some consensus about what's important, right? I mean, I think at the time that ABI break happened, it was fairly random. We were willing to break ABI over here, not over there. For what reasons? You know, there was no sense of what the scale of values was. So, but I, I do think that, that, you know, an unwillingness to break the ABI of C++ is, is a, probably a serious limitation on it being, you know, evolving into a better language.

Yeah. I mean, I think it does still remain sort of an existential, the existential struggle and question of the C++ library evolution. Because as long as we live in a world where we cannot fix our mistakes after we ship them, that will make the committee very, very cautious about what things we ship. And so I think that the standard library will roughly continue being the same size and scope as it is today, because any sort of massive expansion would, a degree of risk that would just be unacceptable. And so it's like we, we, we all understand the rules or not rules. We all understand the, the current, you know, policies and consensus and like the implications of that today. But I think just because we,

we understand that it doesn't necessarily mean that the outcomes are the best. Well, why can't you just standardize library components that are designed with resilience in mind? Right. And I think that's something that we need to be doing. But it's not an area that we've really treaded into. And I think that oftentimes, there's the performance trade-off. Always. Not often, always. But if you want the resiliency, you have to be willing to make that trade-off. One example, there's been a lot of talk recently in the C++ about standardizing networking. And one question that always comes up is if we standardize some sort of secure networking, some sort of TLS layer, well, of course, that would

need to be standardized in a way where we would be able to roll out security fixes and deprecate old protocols, et cetera. And I mean, I think we could do it. I think that if we sat down and if we said from the start, hey, this library component needs to be something that's going to be resilient to change, we could design it in that way. There might be some performance trade-offs, but it could be done.

And I think that oftentimes the conversation in the C++ committee has just been, well, this is an ABI break, so we can't do it. And we maybe need to have more of the conversation of, you know, how could we build, you know, this new component to be resilient? Makes sense. Thanks for listening. We hope you enjoyed and have a great day.