CppCast - Abseil

Episode Date: October 12, 2017

Rob and Jason are joined by Titus Winters from Google to talk about the Open Sourcing of Google's Abseil library. Titus Winters has spent the past 6 years working on Google's core C++ libraries. He's particularly interested in issues of large scale software engineer and codebase maintenance: how do we keep a codebase of over 100M lines of code consistent and flexible for the next decade? Along the way he has helped Google teams pioneer techniques to perform automated code transformations on a massive scale, and helps maintain the Google C++ Style Guide. News CppCon 2017 Trip Report My CppCon 2017 Trip Report - 10 great talks to watch and learn from Kdevelop 5.2 beta 1 released Titus Winters Titus Winters Links Abseil CppCon 2017: Titus Winters C++ as a "Live at Head Language" Sponsors Backtrace JetBrains Hosts @robwirving @lefticus

This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io slash cppcast. And by JetBrains, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount for an individual license on the C++ tool of your choice, CLion, ReSharper, C++, or AppCode. Use the coupon code JetBrains for CppCast during checkout at JetBrains.com. Episode 122 of CppCast with guest Titus Winters, recorded October 6, 2017.

In this episode, we discuss more CppCon trip reports and the KDevelop IDE ide then we talk to titus winters from google titus talks to us about the release of google's app sale library Welcome to episode 122 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I feel like we just did this. Yeah, how are you doing, Rob? I'm doing okay. Not much news. This is our second episode of the week. Yes, although we're not going to air them back-to-back, so our listeners didn't necessarily know that. No, we're doing some time jumping. It's all good.

At the top of the episode, absolutely through a piece of feedback uh this we got a tweet from simon brand saying he finally listened to uh patty os's episode and it's great even if i sound like even if rob irving sounds like he's come from the future to put us on the path of c++ destruction having more resources for teaching those coming from other languages is great i am sorry again about the audio from that episode i'm still trying to fix that laptop i didn't use it for the last episode and i'm recording this one for my home pc but i need to get that figured out still you know i find it's a strange state that we're in because you and i have both had problems occasionally with audio yeah and you were using Windows regardless of the laptop

and using USB devices regardless of the laptop, the same USB devices. How does the laptop have any bearing in this? No idea? I was having some trouble running Windows updates, so I definitely think there's something that needs to be fixed on that laptop right now, although running all my development programs are working fine. It's just something with Skype be fixed on that laptop right now. Although, you know, running all my development programs are working fine.

It's just something with Skype is wrong on that machine right now. So random. Yeah. Well, I'm glad people enjoyed that episode, though. I know we got some mixed feedback when we talk about other languages on the podcast. But I think for the most part, listeners do enjoy those episodes. We still need to do one on a couple other languages, like maybe a Haskell episode. Try to.

Yeah. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes. Joining us today is Titus Winters. Titus has spent the last six years working on Google's core C++ libraries. He's particularly interested in issues of large-scale software engineer and code-based

maintenance. How do we keep a code base of over 100 million lines of code consistent and flexible for the next decade? Along the way, he has helped Google teams pioneer techniques to perform automated code transformations on a massive scale and helps maintain the Google C++ style guide. Titus, welcome to the show. Hey, thanks for having me. Yeah, thanks for joining us this week. Yeah. And now, actually, the numbers in that are slightly out of date.

As of CppCon, we're allowed to mention it is not 100 million lines of code. It is a quarter of a billion lines of Google-authored C++ code. Wow. That is an awful lot of code. That is an awful lot of code. That is an awful lot of code. Are you able to tell us how you measure that? I honestly don't know. Okay.

Like, people that measure these things have reported those numbers and I trust them. Okay. It's probably a Perl script. No, I'm joking. Well, it probably is. Okay. It's probably a Perl script. I'm joking. Well, it probably is.

Let's be fair. C++ just isn't used for that kind of little tool scripting stuff. That's true. I shudder to think at using the C++ file I.O. routines to count those lines. And how fast would standard regex be? I mean, I know lots of people complain about the speed of standard regex in most implementations, too, depending on what exactly you're looking for

to count meaningful lines, that is. Right, true. Yeah. Well, I guess that's enough railing on C++ for the CPP cast. Oh oh i'm sure there'll be more well titus uh we got a couple news articles to discuss and then obviously we'll be digging more into your announcements that you made at cpp con this year sounds good uh so this first one we got a trip report from ben dean um which was very interesting to read. He went over

several of the talks he enjoyed. First one he called out was Matt Gobbold's keynote, which I still need to watch. That was a good one. Good talk. He did not mention this excellent Constexprall the Things talk that I know he was at.

I watched that one yesterday. It was a good talk, Jason. I actually haven't looked at it at all to know how well it recorded. One thing I was curious about, and I haven't watched Herb Sutter's talk yet, but I see that in the picture of Herb Sutter's talk, he's talking about you and Ben, apparently.

Yes, he mentions us. And Herb is great at that, like, better than updating his talk. Yeah, any other presenter that as far as I know, he updates, it's every year he updates his talk to mention things that have happened in the week leading up to his talk. Yeah, that's pretty cool. Yeah. And his talk was great. Yeah, go ahead.

Herb's talk was really a great vision into what may be coming next. Although, as he pointed out many, many times in the talk, none of that is C++20, or very little of that is C++20. He's talking far future. C++96. It's when we loop back around on the version numbers. Oh. That's terrible. Well, who knows when it'll come and i guess i'm i'm tired so

who knows what i'm saying right now although i will say uh another thing in ben's uh article here is calling out matt's emulating a bbc micro and javascript talk um and that was a lot of fun yeah not recorded and as i don't know if there's a version of that recorded i know matt has given it several times and he was clearly very comfortable giving the talk and having a lot of fun during it and it was a lot of fun for all of us in the audience and i really want to watch this other one the uh traveling the solar system with c++ looking forward to that one getting posted. I didn't see that one. I wasn't even aware of it, honestly. Oh, that was on Friday.

It was from one of the engineers at JPL. Sounds pretty cool. Cool. Okay, and then we have this other trip report, MyCBPCon 2017 Trip Report, 10 Great Talks to Watch and Learn From. And the first one he's calling out is yours, Titus.

Oh, yeah, I think I saw this trip report. Yes, that was nice. Yeah, so obviously we'll be talking more about your talk in a minute, but yeah, tons of trip reports coming out. It's good to see all the different perspectives about CPPCon. Everyone seems to be very, have lots of good

things to say about the conference. Yeah as a presenter i've really really liked seeing trip reports not not just because it's nice to see you know your your work mentioned right but very much like to get this sort of feedback of like how was it perceived right did Did the message that we were aiming for go through? Those sorts of things. So those trip reports I really find very, very useful for having a finger on the pulse of the community. Yeah. And then this other article we have is KDevelop 5.2 Beta 1 was released.

And I'm not too familiar with the internals of KDevelop, but it sounds like they went through a big change internally where they merged two of their code bases together. Yeah, and I don't know if we've ever mentioned KDevelop on this podcast. Do you recall, Rob? I feel like we have. Have we? I don't think we've done an episode on it,

but I think we've at least talked about them before in the news. Okay. Well, yeah. I agree we haven't done an episode. I couldn't remember if it's ever been in the news before. So when I saw this, I just felt like I needed to put it in the list of news items. Because KDevelop is, I think, effectively the only IDE that I've ever used.

It's what I used before I switched to Vim in like 2003. Yeah, and I saw a big announcement as far as you're concerned was the analyzer inclusion in KDevelop. They now have CPP Check and this other one called HeapTrack. So I thought you would probably like that. Yes, definitely. More tools, the better.

Yeah. Absolutely. Titus, I'm just wondering what types of IDEs you see used at Google? Because I know Google has a reputation of not having a lot of Windows users, if I'm correct. That is definitely true. Are Googlers using things like KDevelop? Are they using Vim or Emacs? What do you use there? It's been a little while since I've seen the latest stats. I know that in terms of traditional things, Vim leads by a reasonable margin, I think, followed by Emacs. There's heavy use of a sort of internal IDE.

There's been sort of waxing and waning use of Eclipse over the years, and certainly some people talking about CLion. You know, you just casually mentioned some internal IDE. Well, so we have unique problems. Like I said, you know, a quarter of a billion lines of code in one code base. Most IDEs kind of want to sort of build everything and try to get a primitive IDE level index of all the things in your code that you might be calling. And when you have a quarter of a billion line monorepo, those fall over. So you have to sort of design that scale in from scratch. And so there's been various projects over the years to try to do something that scales nicely and it's all internal stuff. So I guess you found

that some of the commercially available IDEs are not doing a great job with such a large code base? That has usually been the case, yeah. Like, anytime that you you know anytime that you have something that's trying to auto syntax expand for you if that's not based on uh very specifically designed tools then it just doesn't work um a lot of the reason that i think vim does so well is because Vim is the primary development system for our tooling team, for C++

tooling, and so they sort of started and I think maintained the YouCompleteMe plugin, which is rocket-powered. And that actually scales.

That's cool. Interesting. Okay. So for listeners who missed your CppCon talk, which is available on YouTube now, what was the big announcement that you got to make last week at CppCon? So Google is returning to C++ utility library open sourcing. I sort of started the talk with, yes, I know you might not trust us. We have put stuff out and walked away from in the past. But the reality on the ground has changed. And it's very important for us now to have API compatibility between the internal and the external. And for a lot of that, our solution is, oh, we're doing something weird for no good reason.

We'll go fix that. Most of my talk was not about that. But let me tell you, we have moved many, many mountains to try to improve the state of that. But the stuff that the rest of the world is interested in is for things where we just like our API better, we're just open sourcing those things. And to that end, I encourage everyone to go check out Abseil at abseil.io or on GitHub. This is the first drop.

There is much, much more to come. But this is our commitment to having a well-supported infrastructure platform of our commonly available APIs. And it's necessary for us to do this sort of thing because more and more of our stuff is going open source, not because we think it's cool, but because it's strategically necessary for us. Like, gRPC and protobuffer are an important piece of our whole cloud strategy. And those need to be vibrant open source things because we believe that users are best off when they're not locked in to their choice for cloud providers.

So those things have to be open source. And the problem with having written those things internally in C++ is that they're written against the libraries that I've maintained for so many years, and so they have to pay a heavy tax to exit out of the code base because the open source version, there just wasn't a supported open source version of all those libraries. So now there is, And we'll be here for the foreseeable future.

So you started by saying things have changed on the ground, which is why you felt the need to release these tools that are supported. Now, just to be clear, you're talking about the fact that you are open sourcing more and more things. Is that what changed or something else? That's

part of it, but it's also like in the talk I've discussed for a fair number of years, it was really the case that everything that Google was building in C++ was built with one toolchain and deployed to our production environment and nothing more. That's increasingly

not been true. You can find bits and pieces of our C++ code linked into mobile apps and, you know, in open source releases and in all sorts of things. And, you know, in a layering perspective, if the lowest level things in your dependency chain aren't portable for all of your needs, aren't compatible with all of your needs, you're going to have a bad time. And it took us a while to realize just how much of a bad time we were having, but we're having a bad time. So we're fixing that portability issue. Okay. So I had one question about the name of the library, Abseil. I believe Abseiling is another

word for repelling. Is there any meaning behind that name choice? There is not. There's a lot of accidental kind of jokey meaning, which you can read between the lines. Okay. But there is not. The name really comes from... There were internal code names and acronyms that clearly made no sense. And then we went through round after round with branding. And there were internal names that

we were using for a while uh and then got changed sort of late in the game and eventually we're like there there are literally no four-letter words that aren't trademarked in the tech industry and i from uh from a namespace choice perspective, like, it needs to be short. Sure. Because C++, like, you're going to abuse the namespace system more and more if you have longer names to type. So four letters was my max for your namespace. So I wound up sort of, one of the pronunciations of one of the names that didn't go happened to be abseil and so we just started calling the project abseil and picked four letters that fit that and that's it

like it's everything else is happenstance wow so i have also i have also now found that Abseil, for a certain fraction of German speakers, has a datalogical connotation. Oh, no. You can't win them all, I guess. No. But we've already had to rename this stuff so many times. It's done. It's done. It's done.

Super done. So the name is effectively the result of the effort to not name it QZFP or something. Pretty much, yep. And as with all good naming bike sheds, I cannot oh, so many hours spent on all of that. But in the end, I do actually sort of really like the name. That's good. So what sets Abseil apart from some of the other common libraries that are out there already? So I think the comparison that most people start with is Boost.

Sure. And I think we serve very, very different purposes for the community. Boost, I think, serves an excellent role as a laboratory. This is a place where you can propose interesting kind of avant-garde sorts of things to try and to see, like, what can we do in the language? Like, where are there, like, how far can we take this? And some very, very useful things fall out of that. And, I mean, looking at Herb's talk, you know,

a lot of where Herb's work in standardization is going right now is looking at the things that are solvable but messy and trying to find a cleaner way to do it in the language. And a lot of that is coming out of things like hana and you know the necessity of you know serialization and reflection sorts of things like boost serves that a very good purpose there but boost does not necessarily provide you good compatibility over time right currently if you want something to be compatible for a longer period, you're basically stuck

with the standard. And the downside to the standard is that's forever. And if we as the committee make any sort of mistakes, the committee is currently not good at having the fortitude to resolve those. And I think that there's room for other priorities. Another thing that I said in the talk, one of the very few design goals for libraries in the standard

is you don't pay for what you don't use. And the example that I use in the talk is Crono, where because the standard needs to suffice in so many different contexts from high frequency trading to embedded systems chrono doesn't make a choice and doesn't force you know scale and resolution things like that on your users because maybe there's resolution in there that you don't want to pay for, or maybe that there's, you know, overflow safety that is unnecessary in your domain that you don't want to pay for, it is possible to have a different set of priorities. So Abseil is really prioritizing compatibility over time and not, and being a little bit more opinionated. It is not the case that we think this is the one true correct answer

that should be useful for everyone. But to go to the chrono example, we're shipping time and duration as concrete types. They interact with chrono, so if you're in a chrono world, that's fine. But they're concrete types, they're fully defined, there's saturating arithmetic there's infinities um and it's we think 96-bit precision covers a very useful range and if you need something more than that i think it's currently subnanosecond range over roughly the lifetime of the galaxy. And if you need something outside of that, use something else.

Chrono gives you that flexibility. You can write your own rep. You said there's a focus on compatibility, so I'm curious what the baseline is. What compilers or standard library things do you currently require to be able to use abso right so the goal over time we want to get to roughly five year support for everything okay the major exception to that right now is msvc because we require so much C++11, especially the thread-safe static initialization, magic statics, that you can't really do that until 2015.

So we require MSVC from 2015, and GCC or Clang, support for those go back about five years. With support, libc++, Libstd C++. Definitely not STL port because that's not a real thing. And, yeah, most platforms that I've heard of, we're aiming for PowerArm, x86, Windows, Linux, Mac, Android, iOS. Everything seems to mostly work it seems like if you require a significant portion of c++ 11 you might have even had to carefully choose your gcc and clang from five years ago this would have been right on the cusp of having good solid support i think

um it's if so long as you avoid there are a lot of things in the abseil internals that are working around known bugs okay um things like we have our own type traits implementations for things that we're missing in gcc49 for instance um and the the five-year thing also goes sort of hand-in-hand with we intend for this to be zero config. There's no running auto-conf. We're not detecting what the quirks of your platform are. We are assuming that the standard actually holds, and if you're in a known weird scenario,

like your GCC version is missing standard type traits uh then we'll make a note of it note when it gets fixed in comments and five years after that fix we'll just clean up the mess okay do you want to talk about that a little bit more because that was one thing i find interesting about your talk how that five-year window is going to be continuously moving so if there's some bug you know in a 2012 era compiler a year from now you might fit or you might currently have a fix for that bug but you're going to take that fix out in like a year yeah um that is the goal uh we've been as the you know single tool chain world sort of dwindled in the last few years internally,

we found that in general, anyone that we could nudge to be sort of close to current, it was hard to force them to update within two or three years, and it was not particularly challenging to get them to update within two or three years and it was not particularly challenging to get them to update in five basically my belief is if you're ever going to update your code you're going to be updating within five um if you're longer than if you're farther than five years out that is legacy code that you can't touch or you're you're off on your own. So that's roughly the idea. And in practice, yeah, we're just going to try to keep that treadmill moving.

One of the more interesting things will be figure out when GCC Clang and MSVC actually had good C++14 support. Count out five years, and then we'll drop 11. It seems like that investigative process itself of finding exactly gcc 4.95 is the exact one that we need i've dealt with that a little bit but not nearly on the scale that you're talking about right um and it's it's not like okay five years to the day it's we're to start a conversation with the community about, hey, this is coming up. We're going to start this process. If anyone knows things that we haven't spotted, now's the time to chime in, that sort of thing.

I really want this to be sort of a back-and-forth conversation with the community. I really encourage people to sign up for the Abseil.io mailing list. Links are on the website. Because we will post questions about, hey, this is outside of what we specialize in. We're looking for input from all of you. Are there any uh particular classes you want to highlight in abseil uh as far as classes go sort of the the class of classes

that is maybe most interesting for a lot of people is uh pre-adopting types out of 17 so abseil only requires c++ 11 but we are including C++11 versions of optional and any and string view, and any places where the APIs differ between what you can implement in 11, what you could implement in 17. We've done our best, I believe it's correct, to make those build breaks, so you can't accidentally depend on something that will be incompatible in the future. But these are mimicking the standard API. And sort of more importantly, when you start building in C++ 17 mode, we will drop our type away and make it a typedef for the standard so that when you spell

abseil optional, it is the same type as std optional when std optional exists. So, I'm sorry, go ahead. No, go ahead. Were you directly involved in the backporting of some of these things like optional to C++11?

I did a couple code reviews and such, but mostly I sort of set design priority and direction. I'm kind of curious if you are aware what issues were hit, like what things from 14 and 17 would have just made goodness optional so much easier to implement?

There's certainly some things in deduction rules and things like that. One of the bigger ones is obviously we don't have class template deduction guides from 17 as a language feature. So those sorts of things are missing, but you can't accidentally depend on that in the wrong direction. So it's okay. But yeah, actually, we proposed a talk for CppCon of what it takes to implement optional, in particular, in C++11. And the constraints of trying to do that on, in some cases, five-year-old compilers, but it was regarded as too esoteric was the feedback that we got.

I sort of disagree with the program committee's assessment on that. Well, there's always C++ now. It seems to welcome esoteric talks also. Yeah, I suspect we will be well represented now this year. Interesting. Cool. Do you know if you'll be accepting pull requests from non-Googlers to AppSale? I believe that we already have. Probably doesn't. We certainly do. For the most part, the stuff that I know that we will accept is things that optimize a little better on platforms

that we haven't prioritized. Documentation updates, those sorts of things. The place where it gets hairy is API changes because we already have a quarter of a billion lines depending on this. So there'll be some discussion there. But I certainly want to see how that plays out it's it's certainly not a no it's a show me what you got and we'll talk well let's talk about api changes a little bit because i think in your talk you said how you

know the app sale team might be making at API changes, but you have plans to accommodate for that for users. So a lot of the talk focuses on change over time and how SemVer is basically a web of lies, and we are foolish for thinking that that actually solves any of our problems. And importantly, every possible change that you can make is a breaking change for somebody. They're probably a breaking change for somebody if they're doing something foolish, but basically everything is observable in C++ at some level. And the side effect of that is you need to be really clear about what is and is not okay to depend upon.

And so Abseil has a pretty detailed list of, please don't do this with our library if you want your upgrades to be smooth. There, of course, since I'm planning for this to run for 10 or 20 years, there's going to come a point where we have to make API changes. One of the things that I definitely foresee happening is there's going to be APIs that we have that wind up making their way into the standard and as it winds its way through

standard API discussions, it's going to get tweaked the side effect of that will be either Abseil has to figure out how to adopt the changes that the standard suggests, or we have to be different for no good reason. And that's not a thing that I really like thinking about if we're talking about maintaining this project for decades. So eventually, on a long enough timescale, API changes will be necessary. And I have a quarter of a billion lines of code that already depends on this. So clearly, when it comes down to it, and we're making an API change,

I'm going to build a tool to do that, because otherwise it's going to be insane to try to deploy that internally. So my promise to users is, if you don't do anything insane with our code, and the definition of insane is spelled out in some detail on the website, then it should be the case that the tools that we ship you should be capable of updating any code that you run it over, whether it's code you understand or not, from the old API to the new API. And because we are so large internally, we have long history of making these changes non-atomically. That is, you introduce the new thing in a compatible fashion,

you convert piece by piece, the code builds at every step, and if and when you actually get rid of the last caller to the old API, then you can delete it. I can't actually promise that we will necessarily delete the stuff that we have shipped in Abseil unless it's an actual real problem, but we will introduce the new thing, ship a tool, convert everyone to the new thing, and then mark it deprecated, and you can resolve it at your leisure. That's the plan. There's a little bit of magic that will need to happen to actually pull that off. But in theory, that all works. Having had some experience with Clang Modernize and knowing how good of transformations can be done with libclang,

I'm imagining that that's the basis for a tool like this. But is that the plan? Yeah, the plan is basically, you'll notice, for instance, there's already dozens of project-specific plugins in Clang Tidy. So the expectation is when we have to make an API change, we'll introduce that as a check in Clang-Tidy to do that update. Not everything can necessarily be done that way, but I think the vast majority of it can.

And anything that's left should be simple enough that a Perl script suffices. That's always back to the Perl script. I mean, it's the point that I'm actually, like, I'm not 100% sure that we can get Clang Tidy to... I worry a little bit about build dependencies, like updating your build system, like, target interdependencies, updating the graph. Like, Clang Tidy doesn't know anything about that.

Right. And rightly, it probably shouldn't. Yeah, but that's one of the places where, yeah, there's a little bit of then some magic happens. But in practice, hopefully all of these things are in the same build target. But, you know, eventually that's not going to actually be true. So we'll see how that goes. Well, you started this by saying that this was the first drop and that there would be more to come do you want to give us a preview on more to come yeah so um one of the talks from cpp con that was uh really great very well attended uh if you haven't seen it uh look when it gets published for Matt Kulikundis' talk on hash tables.

There's been a ton of very, very interesting work that we've done internally on building better hash tables because unordered math does not cut it. And as a result, my mission is API compatibility for the common stuff between internal and external. At the point that Matt has demonstrated that his new hash tables are the new idiom internally, it's my job to get that shipped. And I think he's basically already demonstrated that. So we're in early discussions for, okay, what are the last things we need to do?

How do we start renaming, cleaning that up, and getting that ready for release? So my guess is sometime in the next three to six months, we'll probably ship those very high-performance hash tables. There's a lot of little APIs that just didn't quite get baked to our standards in time. We really want to ship an Absol variant, and we have it all implemented, but it is not battle-tested. One of the things that we really like pointing out is this is the code that runs in production.

Google production has a few things running in it. If you're building in a similar sort of framework, similar usage, that should give you some assurance that this is working pretty well. When we took a look at it, the

version of variant that we were going to ship was not quite up to that level of, like, we're certain of it. So we'll ship that as soon as we're sure. There's some string stuff that wasn't quite fully baked to the point that we

made the design cut off. We will ship something very much like the old G-Log system. We will ship the spiritual descendant of the old G-Flags system, which is now thread-safe and has user-extensible types. So those are kind of very nice design changes that have happened over the years.

And, I don't know, a host of additional things. Oh, there's random. We sort of find that the C++11 pseudorandom number generation APIs are really, really chatty and annoying to use correctly. Almost nobody actually uses them correctly as a result. So we're sort of building things that sort of layer on top of that and shifting our internal code base over to use that. And once that's, like I said, fully baked,

it will ship those things and try to upstream those APIs into the standard at the same time. I could go on. I've got at least three years' worth of release plans. Wow. Okay, so I'm definitely going to risk splitting hairs here on how your release schedule works and your backwards compatibility, but in 10 months months you release your variant

hypothetically does that mean that that variant that chunk of it is five months is five years back from 10 months in the future that it's going to support compilers like are you are you free to support slightly different compilers with it no no no no no the only thing that matters for uh when a thing was released is we are technically saying for the first month that stuff is out, we don't promise perfect compatibility across time. Because there's a possibility that like, hey, maybe there's just build system interactions that we haven't seen because we don't use all of the build systems. So there's sort of a very minor, not official beta tag, but beta tag for new release stuff. But as far as compatibility goes, it is when the compiler or standard library

or language version was released, not when our thing that depended on it was released. Okay. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation throughout the software error lifecycle.

Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. Thank you. signals such as heap corruption, malware, and much more. This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io slash cppcast. You talked a little bit about semantic versioning and how you think it's failed us.

Do you think what you're proposing with Abseil might be the way of the future? Do you think other libraries might try to get their users to live at head instead of just depending on semantic versioning? I certainly hope so. I think the... What I don't see is a compelling way

to force people to change. There's no stick here. I can tell you that there is a carrot, that it is a much better world to live in, both for maintainers and for users, when the burden of making an update easy rests entirely on the library author. But it is a paradigm shift,

and I made my pitch for why I think that's a better world and more theoretically workable and all of those things. And you can believe me or not. If you just want to use a version of Abseil at any given point in time, you are, of course, welcome to do that. If you want to, you know, if you need compatibility, if you need an upgrade path, if you need stuff to work better over time, then I really encourage you to think about, you know, the theory behind it all. And in theory, Simver is not giving you anything. In theory, there's not a whole lot of things that actually work. And I believe that what I'm saying here actually does have, you know, all of the right theoretical properties. And I think as,

you know, we expand the open source community and we, you know, the prevalence and interdependency of, you know, library relationships on GitHub and everywhere else expands, the scaling problems in SemVer are going to show more and more. And when people start feeling that pain, I'll be here. So I'm curious if all... So we've got Abseil, and you're talking in general about the semantic versioning issues. As a previous user of V8, I would get very frustrated where every time I were to download an update, I would have breaking changes across the API. And it was very frustrating to update my code base that used V8. Are you going to be applying the same rule set to the other open source projects that Google has out there?

I have been making a lot of noise internally, but I do not have infinite authority. And as it turns out, it depends a bit on the technicalities of the language that you're in. From what I've seen, like Java has a different, for instance, Java has a different problem space because in a lot of cases they can have multiple versions of a library in the same build. It's not a good idea, but it is a technically feasible idea by basically baking in the version numbers into all of their symbol names and everything just sort of works and limps along. It's a little bloated but it's technically feasible. C++ with all of our ODR and everything

it really does not work. There is no other option. So some languages they have technical reasons why maybe they can dodge. Other languages where the community is just so rallied around their package management and semver story it would be really hard and really expensive and really sort of tone deaf for us to try to like force that behavior on them. It's going to be a mismatch. C++, for all of its chaos,

is sort of chaotic. Like, we can do a thing like this, and yeah, it's maybe crazy, but it's not completely alien. And so we're going to use this as sort of a demonstration, see if people buy in. Hopefully they do, and hopefully it can spread from here to other languages

and other Google projects and other libraries and things outside Google. And if not, well, it's a nice-to-have for me. It's not a must-have. That's right. So you view the lack of a package manager that every single C++ developer uses as kind of a bonus to this livet head style of library development? To be clear, I view the lack of a SEMVR package management system as a bonus. Yes. I think if we had a package management system

that made it easier for you to say, hey, I depend on gtest. Hey, I depend on boost. And just pick up the current thing. And if the upstream updates and needs you to run a tool in order for your code to still work properly, notify you, hey, run this tool.

Or run the tool for you. And say, hey, as part run this tool, or run the tool for you, and say, hey, as part of this update, you need to approve this patch. That would be an amazing package management system. But package management in C++ is also always going to be hindered by ODR and lack of consistent build settings and all of those things. So package management in C++ really needs to mostly be source management. And yeah, there are ways that we could do that. I think I said this to Eric Niebler in the comments at the end of my talk.

There are certainly ways that we could do that that I think would be really very compatible and wonderful experience and very much in line with livid head. What I don't want is just another SemVer package management thing that glosses over the fact that you don't know what a breaking change is. There's no such thing as a patch that is definitely safe to apply

to code that you can't see. Speaking of SemVer and Abseil, do you have a version for Abseil, or are you just pointing to the revision of it in Git? There are no tags. There are no revision numbers. I did not... We did not cut a release branch.

And I trust this so much that for the live demo later in the day on Tuesday, I pulled down a fresh copy from GitHub. Turned out I didn't actually run any of that because at the same time, Godbolt added Abseil support, and I thought it was actually cooler to just go do it live in Godbolt. Oh wow. But yeah,

again, whatever version was running there was also just fine. And that's sort of the point. Okay. Anything else you wanted to mention before we let you go? I'm really excited by all of the stuff in App Sale. One of the things I haven't mentioned here is that it's more than just the libraries.

Okay. We're also very much in line with we put out the old G logs and G flags libraries and then eventually sort of abandoned them. We long ago decided style guides are a really good thing. And there's a GitHub repo of all of the random style guides and i think it is a tech writer's primary responsibility to like check on that every once in a while but none of the language leads are actually very active there and it's impossible to tell the difference from a distance between a java style guide pull request and a c++ one This is not a well-designed system. I'm going to pull the C++ style guide into Abseil sometime soon so that

I can keep better track on that and make sure that it stays more in line with the internal style guide because there are changes all the time. Also, I finally have a solid mandate to help improve the education story for C++. As a result, there's a tip of the week series that we've been using,

that we've been putting out internally, starting on C++ library team, my old team. There's about 135, 140 sort of short essays in here. It covers some of the same topics as C++ core guidelines, but also goes into things like test structure and test readability, things like that. And it's a lot of stuff that just kind of commonly comes up in solid code reviews. I've been sort of trying to find a venue for that externally, but it's been a background task for years. Now it makes perfect sense to publicize all of that via Abseil.

And so starting as soon as possible, I will start cleaning all of those up in priority order, not in numeric order, and post those to Abseil.io. Those are some of my, I think, most important engineering work at Google has been putting out that guidance, that explanation of why the style guide says the stuff that it does, why the rules are what they are, why you should be doing these things. Some of it is strong guidance, not the style guide, not the law of the style guide, but this is something you should really

be doing. If you really know what you're doing, you could do something else, but try this as a first approximation. And I think the last stat that I saw on this was, this is cited something like, we get 25,000 page views a month internally for that series. So it's sort of an important part of the C++ culture internally, and I'm hoping to make that an important part of the C++ culture internally, and I'm hoping to make that an important part of the C++ culture externally.

I would have posted a bunch of those earlier this week, but I got sick as soon as I got back from the conference. Okay. Well, we look forward to seeing those get posted online. Yep. I think there's an RSS feed you can find on Abseil.io that will notify you for those. it online. Yep. I think there's an RSS feed you can find on Abseil.io that'll notify you for those. If not, send an email to someone, me or

the Abseil list, and we'll make sure that that gets double-checked. Okay. And where can listeners go and find everything they need to know about Abseil? Abseil.io. Okay. Well, thank you so much for your time today, Titus. Thank you both very much for having me.

It's always a pleasure. Yep. Bye-bye. Thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in. Or if you have a suggestion for a topic, I'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you like CppCast on Facebook and follow CppCast

on Twitter. You can also follow me at Rob W. Irving and Jason at Leftkiss on Twitter. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.