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.View the profile
About the talk
Engineering is programming integrated over time. That is to say, as much as it can be difficult to get your code to build and run correctly, it is manifestly harder to keep it working in the face of changing assumptions and requirements. This is true no matter the scale, from a small program to a shared library. Only two solutions have been shown to be theoretically sound: never change or provide no compatibility guarantees. What if there were a third option? What if we took the question of maintenance out of the realm of theory and moved it to practice? This talk discusses the approach we've used at Google and how that intersects with other languages, package management, API and ABI compatibility, and a host of other software engineering practices. The particulars of C++ as a language and an ecosystem make it well positioned for a different approach: Live at Head.
Good morning, everyone. Really? How come on you have to a little better. Good morning, everyone. Okay. So I am super excited to be up here. Number one reason why I'm super sad to be up here. I do not have to present up here. And this is actually the real reason I'm super said to be up here is because I'm really excited to introduce you. You're at your next speaker Titus Winters idea of how I got to know Titus professionally rebuilt bunch of people's plus tools amazing. Miraculous. We were sure they were going to
change the landscape of C. Plus. Plus they they couldn't Bebe was wonderful, but we made this like critical mistake. We forgot something tools. Do not have impact. Pools don't have them put they don't they really don't tools can't change the world. People used tools to have them packed into change the world and Titus and his team used our tools to change the world of C plus plus Google and you turned articles Plus Code based from something that was falling down around us and that we didn't know what to do with into something
sustainable and maintainable for years and years to come for decades to come. He turned our developer ecosystem are developers from some kind of din of confusion and frustration and anc's into actually like a productive and happy and an empowered and informed Community right in and that's why I'm really excited to be up here in introducing him. However is I'm supposed to be up here telling you why you should be excited to listen to Titus and I can't do that. So tell me to ask you a question. Why are you here? Norton I'm dead serious. Why are you here? And you should be
asking yourself everyday everything you do. Why am I here? And why am I doing this? I suspect a bunch of people here. How many folks here are here to learn something some way or another right right to to grow to improve right? Incrementally year-over-year. I hope right in conversations in the hallways with new ideas and revisiting old ideas listening to Great talks. But to learn we need a teacher during a reminder to say yesterday of the importance of teachers. It's my pleasure to introduce the person who taught Google to write better
cplusplus and to write C plus plus better finest teacher that I've had the pleasure of working with the Google. Dr. Titus winners the teaches about living a tent. All right. So C plus plus as a living head language, we certainly know some of those words. This is a deep and esoteric and some moments sort of traffic. But in order to get into that we need to sort of set this stage. We just motivated. We need to start with a story and getting here required moving through Google and working with the Google tell base and much of the story is sort of the history of Google C plus
plus code and portability. Historically Google his head pretty limited portability requirements for many years. We control our toolchain and production environment and lower control it very well. There were some projects that had some projects had unusual portability requirements things like building Google Earth for Windows, but it was an extreme minority and bar focus on it was sort of largely an afterthought overwhelming majority of our code had completely controlled constraints that it just wasn't worth focusing on other things and you can sort of see this in her
interactions with some of our open source projects early on we build cool things and we wanted to share them put out things like flags and logging in and all of these things. But then as our control over our building production environment got better and better it sort of stopped making organizational sense for us to spend a ton of effort providing those libraries for platforms that we never touched. It was very outside of our needs and so our interactions overtime over a decade old. Started changing on the upswing a little while
back. Noble shockingly has different needs than production. Are open source projects that support Cloud have different needs still and we sort of managed to put blinders on and muddle through regardless for a while, but eventually it did become clear throughout the organization that we needed a different approach. The era of Google's codebase doesn't need to be like everyone else had come to a close and it took a while but we didn't realize that On the other hand that era gave us amazing experiences and Towers
things that we've spoken about previously talks that I've given calling from former teams. I am right? Well, we only had a single platform that we cared about. It was easier to do things like right tests and impose rules like our Beyonce rule if you liked it. You should have put a test on it. This is the type of rule that allows janitors and Tool makers and compiler team to make changes to the infrastructure is literally everything in our code base uses. with confidence
if your team actually wanted your code to not break you needed a test for us to validate against. This is monoculture made sings possible. Now, we make changes at scale millions of edits are not just possible. But actually pretty straightforward. My team next quarter will almost certainly make a million at its to archivist. I would be surprised if we didn't get to that number. Weedle evolve to the place where anything that needs to be changed can be changed. We are sustainable. That is
very powerful. So in a couple years back when our leaders started taking other platforms and code portability. Seriously. I really wanted to ensure that we didn't lose that property at sustainability when they start talking about funding efforts to improve code-sharing. I made sure to get involved in those directions early. I shared what I knew and what I wanted to ensure and as a result, I got tapped sort of broadly to make code sharing between our code base and the rest of the world more peaceful. This talk is really about two things one. Google is
open sourcing a bunch of C plus plus common libraries is in the bits and pieces that underpin literally everything we do. And I want to do this in a way that doesn't impact our ability to make changes, but that is also good for users. And that is a difficult balance. There's not a lot of great examples for how to pull that off yet. So this is what I'm going to try to motivate. The discussions that happened comparing our internal development strategy and how the rest of the world Works have been Illuminating to really explain things in to make this worthy
of a plenary talk in a big audience. I want to step way back and look at some sort of core software engineering practices. First software engineer of the things that we do when we work on a project why we do it. I want to be a little bit like the kid that asked why over and over to get to some more abstract stuff get us to take a look for a while it sort of basic software engineering practices or when I'm doing snarky software engineering Orthodoxy. And get you to evaluate why you do the things that you are doing, but first we can't really look at those practices of software
engineering without some working definition of what is software engineering. We all know what is the difference between these two things? Why do we have two words for these Concepts? Software engineering to me is programming integrated over time. I'll put it another way a programming task is oh, hey, I got my thing to work and congratulations programming is hard and a lot of the time the right answer to a problem is I'm going to go write a program solve that problem and be done. That's great. No, no judgments, right
totally fine engineering on the other hand is what happens when things need to live for longer and the influence of time starts creeping in the library that you used has a new version the operating system you develop for has been deprecated the language you wrote in has been revised and you need to update the requirements have changed and you need to add new features other developers are working on it. You're moving to a new team. You're moving to a new computer your hard drive. Time happens sings change how you handle
that and how you keep your programming working is engineering. It may bleed into the programming itself as you plan for change within the structure of the code, or it may be entirely layered on top when you're quick one-off hacked becomes and trying to the critical feature of your team's tool set. filmtools, Dan The first time I can remember having the spot programming is engine engineering is programming integrated overtime. It's still relevant. This is optional versus required in front of us people at the company for longer than I am
smarter than I started saying required fields are harmful. Let's ask why What about if you remember is the message format for the lake Json that we have Google build all of our PC Services out of nearly days you define a message maybe like this name of this type is request that has a single feel very ID, that field is required as a 64-bit integer. The name of the field isn't present in his wire and coding just the ID number of the field 17. If a process is sent a request that doesn't have a 64-bit integer in ID 17. It will fail to parse.
Breakfast just dies before it's even made it up the staff. So they are peace-loving and logically that makes sense. You can't process without the request without you can't process the request without ID. Why would you think you could seems perfectly reasonable to make this require? What happens when time Creeps in we change the service have a different option? But if you provide the raw string instead of a precomputed ferry ID not case. We aren't sure which one of these will be present. So maybe we make both the ID or in the spring optional validation at a higher level. What's that look
like when we do play we have some front end that is sending requests the back-end server. Unshocking Leaf we deploy the front end first will start sending maybe request ID or maybe sending request string and the server remember is somewhere back in time. It is still running with the old definition any servers view of things. The ID is still required. And so if the server is configured so that that garbage request is an assertion failure or just silently ignored things go sideways surprising first is very in line with everything that
everyone knows about writing protocols. You need to be strict and what you mix and liberal and what do except they're clearly raft update the backend first no shock make sure we're capable of accepting any definition of the servers at once. It does seem safest after all we know the previous version was working updating all the servers to the new version that wants might be catastrophic. So we do some of them and then the front end and if the front end doesn't know the difference between which ones support the new thing which ones
don't then we're back to the same problem. This only gets worse when you start having complex networks of servers. I could not possibly draw the graph of server interconnects and Google production. You do not want to get into a situation where every service in the fleet has to be restarted all at once in order to handle handle a protocol update. So we could of course fix this by adding virgin fields to every message definition, but that in and of itself is still adding time to the protocol. All of this complexity is fundamentally a different flavor than I got it working
is fundamentally a different flavored then programming. It is completely unnecessary and some contacts. If you know that your programmer service is only into work for a limited time, right? I need to get it today. I need it to last through the demo. I need the next round of funding. We don't need to plan for the future. Then you don't plan for the future. That's fine. Right context matters. But when you aren't certain when you have to be prepared and that preparedness. Is what I look at at Suffern to nearing is the impact of time on a programming system
and the point of this whole anecdote that something that makes sense on the face of it required Fields. Turns out to be a horrible idea when you start thinking about change over time and I would argue that there are many things that we do. That makes perfect sense in a limited domain in the programming demand, but do not necessarily make sense when we are thinking about it as engineering and change over time. At the core, I think everything that we think of when we talk about software engineering tools and technology is about resilience to time Version Control is about being
able to go back in time coordinate with your colleagues over time. CI continuous integration is about making sure that recent changes haven't broken the system unit test are very similar. This is make sure the feature that you wrote haven't been broken by the idiot down the hall or you in the future. Factoring tools are how you update from an old way to a new web design patterns give you some ability to plan for future changes without knowing exactly what those changes will be dependency management of how we deal with the fact that the library's we depend upon may change that last
is really crucial and what I'm going to talk about for a while here. Let's talk about dependency Management in the fundamental problem and dependency Management Diamond. Diamond dependencies are the bane of package management content management dependency management any sort of management and they arise commonly in cases where multiple libraries depend on a lower-level library. Here we have live a and Libby they both depend on love you till. As soon as versions change there is now to Green boxes for live your film if everyone in your infrastructure doesn't
upgrade at the same time, then we have version SKU Libby depends on me too, but they depends on me one. This is even now still fine in theory until some additional package maybe yours chooses to depend on both of them did little libraries. Now we have a problem. You are the pink box. Some situations for some languages we can make this work by compiling in both versions of live you till so long as there are not types from love you till the pass through both of them into user code and so long as there's not Global initialization in love you
till and long host of other things but in general for many languages in for many situations this test results and failed builds, or maybe in some cases worse failed run time problems. There is a standard mechanism that we use for identifying a problem and it is so ubiquitous. It's even worked its way into this diagram when discussing two incompatible versions of love, you till my instinct to describe these as version 1 and version 2 not 1 and 1.01 not apple and orange Not A and B. Clearly, I describe these as one into this is what was intuitive to you as well. I'll guess
we've come to take it for granted that version numbers are what identifies a release and changes in major version indicates some level of incompatibility you change this is what we call semantic versioning and it is the standard answer for versioning a dependency management. Semantic versioning that we're on the same page generally gives us version numbers of the form X. Y. Z103. 17 for instance the small batch number. These are things that shouldn't affect anything just to bug fix. You minor number. The three is a minor additional
release. We've added some new apis things that weren't present in the old thing but nothing has changed. No one will be broken and the major number bump is reserved for I made a change to an existing API your code won't build. So when you expressed dependence on a particular version of one of your underlying libraries with you till you say I depend on 1.3 or better And 1.3 or better means could be 1.4 could be 1.5 can't be too. Oh because in that 122 switch you made a breaking change
scarecrow. implicit in the system is that you can tell the difference ahead of time between exchange that break someone and they change that doesn't and it's actually sort of worse than this using an incompatible. Major version doesn't mean that things won't work. It just means things might not work. It is entirely possible that the major version got bumped because of API changes that you don't actually care about that is imagine that live a doesn't depend on it everything you till only one part of it. Changes unrelated to apis and live your till May not affect live a in any meaningful
way and yet in December since we've lived live you till 2 V 2 and a new major version because there was a incompatible API change. Don't some instances Denver is over constraining which if you've ever had trouble installing something because of version incompatibilities. Is not a pleasant thought I think it has been a week since I had that annoyance and I would give you better than even odds that if we just made it shut up and turned off all of the version checking it would probably work very annoying but assuming that you can identify what breaks your users and assuming
that you're okay with that slight over conservativism. This does give us a standard way of identifying things that will work together. Nope, what's number doesn't say? This is not providing any form of proof that your dependencies can work out. It is just saying that if there is a set of runes for your dependencies that satisfies all stated constraints Buchanan Siri find it. And of course each version of all of your dependencies comes with its own requirements and it is especially important to note that any dependency tree. You see that fits on a slide is wildly simplified. And the
popular dependencies are very popular and the diamonds form at many levels and scales. And as your dependency graph grows, it grows quadratically that is how grass grow only a linear faction of your dependency graph is under your control. You are the pink box you get to pick the things that are directly dependent upon by you you do not necessarily have control over the dependencies of everything else in your graph. Do the math the chances of December and its potential slight over constraining leaves you with an unsatisfiable. Dependency
Tree Grows quadratically. We are doing better and better at in the open-source world of making things shareable and we are heading to disaster. Why do we use cember? It is a compromised position between nothing ever changes and there is no stability promise. There is nothing about this that is necessary nor is it in any way sufficient as your dependency graph expands dependence on December is equivalent to I sure hope that major version bumps in My Graph happen sufficiently infrequently that this all works out. So I hope and a prayer.
What's the difference between a patch release in a major version it gets worse. That is what guarantee are you giving when you bump from one 317-213-1828. You aren't giving when you go to 200 that is. Put another way what constitutes a breaking change and because I've done quite a bit to change an update Google skybase over the years. I can answer this quite confidently almost everything. Breaking change this is not binary. It is Shades of Grey. Almost certainly fine
or boy. We sure hope so having white spacer changing line numbers. Clearly. They should be fine right in any language that has even the most primitive reflection properties say extract get me the current file name in line number in this file. It is theoretically possible for production code to depend on those properties. This is the stupidest factorial implementation of all time. Plaid code is by its nature ridiculous, but you can certainly imagine that spread over ten thousand lines of actual production code something that
reduces said this could in theory exist and practically speaking. If you saw my top contest a couple years ago because log statements tend to include Philemon line number riddle and poorly designed test regularly do depend on Philemon line number we shouldn't care but we also should not pretend that this does not have the potential to break some I'm more extreme and removing a public API. This is clearly a breaking change. Everyone would agree with this type of thing that everyone knows recognizes a break. This is not contentious the same time
you had an API that's better in every way for 5 years for 10 years for 20 years. We really have to continue supporting the old saying what if you go talk to Chandler and you like a tool that update everyone from the old thing to the new thing just provably can we delete the old busted apis then? Even the delete a thing that is clearly a breaking change. hayirli impossible nothing's in the middle. How about adding an overload since the break-in change O N C plus plus this is breaking
change the address of your function any function pointers. This is almost certainly going to be a bad brake aren't you have changed the functions. You've made it ambiguous which function you wanted out of that Overlook set philbrick will hit more minutes later. It was that a breaking change adding overload. What about changing the number or alignment of members in an object? Someone could be depending on that obviously. Or run time efficiency, what about cases where run time efficiency gets better for almost all colors, but some of them regress coming up
with a definition for breaking change is hard no matter what we do and a Hiram's law sense. Someone could be relying on every observable. And as a number of users of your API goes up the odds of someone relying on every observable behavior of your API goes to certainty I'm going to include a flight on this whenever possible until everyone else is courting it as far as I'm concerned. This is one of the great practical constraints and software engineering Hiram's y.com. Basically, it's just that quote, but we miss you Hiram. And there is of course an XKCD for today.
Hear a clever user is relying on a bug in their keyboard drivers to configure their emacs workflow and then complaining about the bug fix. Semantic versioning. This is the thing that we all used to avoid having dependency problems. This is based on the idea that we can tell the difference between a change that breaks our users in one that doesn't even though hirons law tells us better or if we're being charitable. It tells us about changes in API and assumes that non API changes don't matter. Denver identifies correctly when the versions that we have installed
theoretically don't work together. It is possible that in practice that they do if the API that caused the major versions on fees on used or any how's the weather in Paris in here to supporting C plus plus language versions as it turns out. She + + 11 support was not a binary thing. We might still disagreed a little bit on whether any given compiler really implements Express on your requirements as require C plus plus 11 turns out to not be entirely useful collapsing things that are complicated down into a single Dimension Force the force theoretically
satisfying makes great graphs on whiteboards, but it is not very useful practically. December constraints do not promise solutions. They merely promise if you are able to obey these constraints things will work the likelihood of over constraint or leave to unsolvable constraint problems and this growth quadratically the frequency of major number bumps goes up in your dependency graph. You are increasingly likely to be stuck. But when it works, we don't have to worry about Diamond dependencies. So that's great. Those are important because those are hard really why these are hard not
what we currently do to work around it Diamond dependency. Think about you as the pink grass here. You are not an expert in the code that has to change live a the code that didn't change live you tell why did they change this thing? I don't know and whether or not any change that you happened to make to live a to fix this works. It's a whole lot of no idea dog. There are three things I've seen that make this work and Siri that avoid the diamond fantasy issue. Nothing ever changes over time. Good luck with that at 11 and I'm stretching. We're just going to grow a bigger box.
Or the group making the change needs to update everyone the mono repo approach or make it really easy to do the update even by a novice. Rephrase it this way we have so completely solve this problem in the last 5 or 10 years. We just haven't stepped back asked why I look at why we do the things we do and consider the full impact. Look at some of the technical and conceptual changes in the last few years and come back to the idea of what would it take to make upgrades easy for a non-expert. What happened
recently you at tester on the rides the search results for the Google ngram viewer. This is the frequency of the unit test in the Google book SATA. I really wish it went past 2007 cuz I'm 90% sure that that crap just keeps growing up. Unica That would actually just cover how to verify the change. I just live your till or it's rather if live a nice reasonable easy to run runs everywhere unit. Testing sweet. You can make whatever changes you want to live. You tell and see if it still work at cuz keep in mind the changes that we're
talking about are not intended to be Behavioral or semantic changes largely were talking about fix up the apis so that the existing invariance are still holding existing. UNICEF shouldn't have to be updated in general a good unit test go see that other talk. I mention that covers verified and how about where and how to change As it turns out we've talked about this at this conference. We have published papers on this we have a tool that is specifically designed to be an extensible platform for identifying and converting an old bad pattern
into something better. So that kind of covers the rest of those bullets upgrades are easy. If we your libraries Enders promise not to break you without providing a tool for the upgrade the tool will identify the places that are affected by the break and perform the upgrade automatically assuming that we're all right and well-behaved code and being good engineers in providing unit test in that world a complete. Novice can do the upgrade for a project. They don't work in Keep it locally submit the patch
Upstream, whatever. It will not be a silver bullet turn back to Fred Brooks in the mythical man month. Essay is tooling is not going to get us double performance double productivity. We aren't going to magically make these games can't just wave the magic to only wanted make all of problems go away is to solve one particular class of things extraordinarily well, but they are often constrained by practicalities like the code you wrote is insane. The deal is going to be this if your coat is well-behaved. The tools should be able to enable the types of her factoring and changes that we have
collectively been most afraid of the major version Punk changes tools are great for doing non-atomic API nitrate you provide the tool wait for people to apply the tool then if necessary and practical you remove the old API. With these tools and policies I claimed that this is enough to solve Diamond dependencies. No API brakes without tools users are well-behaved unit tests everywhere. First Source distribution if you are dealing in binary compatibility and things like that you are off in the whole different world
at night. Good luck. But the sad reality is almost anything you can do will break someone's build so projects that intends to actually work overtime should be clear about what they promised and what they require from you in exchange. I am trying to get the standard to be better about that stay tuned. No one can actually speak for the whole committee. There's a hundred people there, but I do believe there's rough consensus that we the committee will put out something more robust soon right now very few people in this room know what the
standard actually says about reserving behavior for future changes in the standard itself does not say nearly as much as the committee relies upon. So the details in the next couple slides may change before the committee actually commits to something but roughly I imagine that it'll be something like this rule number one. We reserve the right to add things to name space stood. You don't get to answering system that shouldn't be surprising standard library is going to expand over time and we need to not be worrying about whether it's safe to add things to do it. Of course step back. This
is a prime example of an engineering rule not a programming rule. If you know for sure that you will never have to upgrade compilers or standard libraries. No one else has ever going to use your code. Never going to share it never going to get off that hard drive. You can have whatever you want to put your bills going to work. It's fine. It's not a good idea. but this is an engineering rule not a programming Rule and it's going to break if you do that and you ever try to share that or upgrade that and we're all going to laugh at you if you complain about having done that but there
are of course some things instead you are allowed to do for your own types. You're allowed to specialized it a 50. It does have to be your type specifying a half for some unhashable student type still forbidden best time to Hash or really anything else for a type that you got from someone else's library is in general just bad form. You are preventing them from doing the same operation. It makes Library maintenance nightmarish. Don't Define things for apis you don't own. 4 declarations in a standard case are a particularly subtle
and annoying subset of doing at things to stood you shouldn't forward declare things. You shouldn't add things to your forward declaration assumes that the details of that name in stood never change and it is not your right to enforce. Exactly the details of those names if it's not promised by the standard in an engineering system, you can't add that constraint that's reserved for us. So let me say that again. You are not allowed to forward to clear things. You do not own at least not if you want your build to not break under API maintenance. I pulled this out of
boost code from a couple months ago. Here's an example don't do this if the standard if the committee decides to add an additional template to set with a default printer. So all code that is building currently continues to build this for parameter for declaration is now a bill break. Congratulations. You have food in exchange for it'll break not a good choice. Also, I believe that the standard is going to come to something along the lines of assumed to call only interface. This is going to be bits. Like
don't take the address of functions don't depend on metaprogramming or infection taking the address of a free functioning namespace stood will be a build break if and when we add an overload for that. So, you know, if we decide to put an alligator in the free function first aligned that'll break your gold someday amusingly according to Howard the standard doesn't currently forget this you are not allowed to take the address of member functions and stood so you can't take the address of string size, but there is nothing in the standard for a week until the technically forbids you for doing
this for free functions. That said I'm pretty sure I speak for the committee on this one. We super don't care to build brakes because you did this and we had an overload. There's another important class of usage that the standard doesn't promise is stable over time metaprogramming. This is a stunningly stupid is even take a look. It does the obvious thing in 11:14 and become super wrong and 17 the type of stood Vector in place back changed to return a reference to that new
element. Obviously, no one is actually going to write to this. This is merely slide code, but you can imagine over ten thousand lines of code building bad dependencies on metal properties of things out of the standard. I choose number properties of the standard Library are detectable at compile time and the vast majority of those are subject to change from version 2 version. This code correctly implements is even in C plus plus 11 and 14 and becomes completely wrong and 17 because we change the type of in place back. Don't do that.
So that's kind of an example of this compatibility promise that I think needs to become more clear for all of the libraries that you're depending on if it is being maintained like at a professional level. They need to tell you what they promised what they ask from you in exchange. If we're talking about engineering projects and compatibility overtime everything here needs to be understood as a two-way street the underlying Library be at the standard or boost or anything else needs to be clear about what compatibility of promises and what it doesn't. It is not theoretically satisfying but
those promises are far more complex than they simplistic December compatibility story Denver has lured Us in with the idea that we can collapse compatibility down into one concept brushing aside the fact that it both oversimplifies and over constrains. It also importantly brushes aside the fact that without real compatibility promises and discussions and without tooling to ensure that users of a library are well-behaved even a patch release in December world can break things arbitrarily. Over the years we've gone from nothing ever changes, like early posix
to nothing changes in the fashion that might break things both of which can work butter Ford of annoying and stagnating computer engineering is software engineering is coming up on maybe 50 years depending on where you know, draw the starting point and it's going to go for a while more the idea of something staying completely static in definitely seems like a bad Gamble. And it sent it to rebell against no breaking changes. We've glossed over the fact that we haven't really defined what is and is not a break-in change my focus intensely on API brakes and closed
her eyes to everything else pretending December solves things. But as our dependency graph grows quadratically the odds of this becoming unsatisfiable grow as well. So what if there was a world that works differently there is that third option for avoiding Diamond dependencies after all naked always easy to update even for a non-expert anyone that's with an amount of repo is already experienced. This anyone that works at Google in The Last 5 Years to see notes and action the burden is on the people making API changes to update their users were spoken at length about how we make this
work. It also puts the burden on the people making the change to deploy the change. She's a much better scaling property. So go back to the start of the talk. I need to make code inside and outside Google API compatible. That is my mission. We've had years of experience with the upgrades are easy variety and as a result of the results of our policies and her manolito, and now I would like to offer that to you. So today we're introducing abseil don't go to the website I'm still talking. We're releasing common libraries with an
engineering Focus. We want this to work overtime. It's like the required Fields example, some of what we ask may not entirely make sense it first or it may seem arbitrary and weird. But I promise you overtime. This will be the right answer or we'll figure out how to change it to be the right answer. These are the libraries that are used internally at Google. We released soft launch yesterday. I have a quarter of a billion lines in C plus plus code that depend on this. I have 12000 active developers depending on this day today.
These are the libraries that are used. They're about to be used by other Google open source projects protobuf grpc tensorflow is a big part of why we're doing this right now actually things in this Cove Base 10 to get written against the same set of apis and when we open source, then we don't have a nice canonical supported set of those apis work with the open-source releases every one of those projects. Every one of those teams sends a bunch of effort by hacking their way back out of the Cove Base. Is it going to fix that problem at the root? We spoken for years about the internal
processes in our ability to do large-scale by factoring. I don't want to lose that. Ability to change is important. I spoken about what it takes to be sustainable and I'm very proud of having gotten Google code base to that point ability to react to changes in a big part of that. We also don't want to break you the open-source users. We have to be responsible and provide easy upgrade paths. All of that plus what I've already talked about the last 40 minutes. If you are well-behaved, we won't break you we have to make an API change. Hopefully it's rare, but will ship it tool to just do the
update. I don't believe in sin ver and I further also don't believe in free compiling this. I want you to build from source and build from head. I want you to live at head. The library is you depend on her being updated smoothly with the policies. Like what I've described and your coat is well-behaved. There is no benefit to pinning to a particular version thinking to the current version of your Upstream deaths should be no different than syncing with the rest of your code base and practice until we work out better mechanisms to ensure that all of your code is well-behaved is
going to be a little tricky at first, but it's a concept not a technology the more that you can keep your dips up-to-date the less exposure. You have to unsatisfiable. Problems up here. You'll be you get all the new stuff. We're going to ship some examples scripts for Basil and get Hub that make it easy to sing from Upstream. When you want to hear a larger organization with security policies in the like that clearly won't apply but this is the concept of technology get in the habit of drinking regularly, if something goes wrong when a daily or weekly upgrade is going check your coat against
our compatibility guidelines. Maybe we did something wrong. Maybe there's things we haven't called out or maybe your coat is just being silly more aggressively that we shake those out the easier all upgrades become it was a lot lot harder to do the sword of upgrades that we do internally 5 years ago. We shaking the tree and now it's nice and smooth. Me and remember what I'm doing here is bringing the apis in the user experience. The googlers have lived with for years. I am not saying it's perfect or the ultimate answer but this is what this project needs in order
to still have a chance of maintaining velocity for those quarter of a billion lines of code. Let me go into some detail on what you can't do with abseil code and still qualify as well behaved. Although remember this is of course an engineering restriction. Not a programming one. If all you need is a moment in time go ahead and pack away. Just don't come to us if it doesn't work when you try to do an upgrade. We reserve the right to add things to namespace Absol. Everything on this list has the potential to break existing code
just because we added a new symbol. We will eventually get better static analysis linters client ID checks etcetera updated public to catch as much of this as is practical, but I guarantee you everything on this list is a thing that you could trigger a build break with when I make an internal change or when I add a new name. We also reserve the right to change implementation details. The ABI will not be stable do not rely on I built this six months ago. And now I'm trying to link against the version of it from now and like no we change things all the time. Don't do that don't depend on
internals any namespace with internal in it is not for you and you file a claim with internal in it is also not for you. Please stay away from those. I know that everyone's Lego underscore underscore in the standard means that's reserved for internals, but I can do it just this one time. Don't Define private-public not even once not funny. Don't do that. Our include graph will change please include things includes are not bad on the topic specifically of ABI and internals not being stable. I really like to go see Matt culiacan vs. Talk Wednesday afternoon
for why we find those things so important if we were constrained by any of this than our recent work on changing half tables would have been impossible Improvement requires change. So what is that sell the library zero config is bunch of utility code is the low-level nuts and bolts of C plus plus as we write it. It is spring route is debugging in analysis. One of the things I'm really really excited about is it will include guidance internally for the C plus plus Library teams probably been
five years. Now, we started publishing dates for the week series. I was just sort of a longer-form essay about something that's been coming up. These are largely compatible with the core guidelines just in a sort of water Forum discussion. I've been trying for years to have a smooth venue for shipping all of that. And now I finally have a mandate to do it. So that's nice. We have C plus plus 11 compatible versions of standard types that we are pre adopting. So if you really want stuff out of 17, but you're stuck on 11. Maybe you want to give it a shot a couple cases. We
have alternative designs and priorities the standard for the general goal for everything is support five years back when possible. So, let's look at what that means. 5 year compatibility and zero config means we are going to assume the standard but work around it if needed here is an example the threadlocal keyword for the cheapest bus 11 by all of our compilers everything we care about works fine, but for some reason in apple xcode up until xcode 8 it was disabled. So we have tagged in here Apple
filters and a tweet to text that scenario and everywhere that we are using threadlocal. We have to work around it. The other half of this is 5 years after xcode 8 and the 6 has been released. We're going to delete this and all of those happy work around you get five years. We are planning for the future. Abseil has a bunch of utility coat string routine really amused in the aftermath of Darkness talk we're talking about we really like something like a python split like 5 minutes and I'll skip this for you. So we have three
split it takes string of things and variety of the limiters and simple case. We also returns you have bacterial strains you or list of strings you or up your container of whatever it does a fair amount of nice magic to give you a very powerful expressive basic concept. I just want to split a string and do it in a configurable customizable. Very C. Plus plus you sort of way. Elsa got the other direction training Springs little less magic one of my absolute favorite things start at this is a very attic unformatted just converted to string in concatenate it and it does
blazingly ridiculously fast. I've had a number of Gubler say, you know, if you don't really say anything else perhaps I'll But You released your cat project is still a success is a really simple way of life Improvement for I just needed strength. Does debugging facilities we have leak checking apis? The API is always there. And if you happened to build your code with leak sanitizer enabled then the APR is implemented by League sanitizer. If not, maybe you feel like implementing leak checking with some other thing. That's
fine say maybe I will be there and your code will always build regardless what platform Iran has unsupported platforms, of course back on even more Limited lease supported platforms were working on symbolizing those so you get the names of those we have nice built-in Tides address sanitizer thread sanitizer. You can tell what tools will use internally. And the satisfied annotations, I really like those. reproduction C plus plus 17 types in C plus plus 11 so you have screen view optional any and soon variance
on all compilers in C plus plus What weights you may say types are expensive you have heard Titus speak in other forums and he says types of expensive. So consider Absol optional to return to buy baby food. Now you want to update to a C+ plus 17 world and you don't want to spell Absol optional you want to spell stood off and use the standard clearly. You should use the standard. So you have to go track down every place that that is called and update those things in the same chain. That's kind of annoying when you have to track down
everywhere that F goes so we got updated every function that passes into and you can see like in theory. This might get actually kind of messy a difficult. Turns out no plans for this we check at Bill time. Are you building in C plus plus 17 mode. Do you have to Dawsonville? If so, Absol optional disappears. It is just an alias first it optional. They are never the did they are never separate types. They are at most different spellings in any build for abseil. You should have one of two optional optional
in Spring View in any Etc. This means when you use the new standard the pre adopted types just melt away and you don't have any restriction on how you update those spellings. Both spellings are the same type so you can just update One Pilots time as you feel like doing it, or you can leave it for later for the 5-year policy five years after the relevant standard is available five years after C. Plus plus 17. We will shift a client ID check the updates the spelling everywhere from Advil optional. Optional because we assume that you
have 17 and then we will delete our version. However, this is important. This is part of why we can't have you relying an argument intended look up on ATL ATL is one of those surprising but to the language when you call an unqualified function the overloads that is formed by looking in the associated namespaces for the arguments of that function in this means this code works fine and 11 and 7:40. I have a Absol screen view and I can call unqualified Bearcat and it will say oh one of my arguments is from names based Absol. I will look in their space apps.
Oh, there's an absolute workout done my bill. Disco. Obviously breaks when you update 17 because Absol stops being the associated namespace of that type. It's good strength, you and 17. So if you write your code to depend on things like ATL, you will break over time. Don't do that. We will try to ship static analysis to prevent you from doing that. self Don't Lie No Deal Like I said, we're shipping the guidance tip of the week series. There's about a hundred and thirty of these I checked very recently.
These are cited about 25 thousand times a month internal. So a little important we cite them by number traditionally in code review. So I know the numbers of probably 15 or 20 of them. If I see you doing something that indicates maybe you don't understand how return values and coffees work in C plus plus I'm going to cite tip of the week 77 and it's just kind of a shorthand for you need to go read that go read through that report back figure out what you've done wrong Etc. So we're going
to ship the same ones with the same number not all of them still matter of in public. Some of them don't even matter internally. So there will be holes in the numbering system. I hope you can all get over that. I don't want to learn another set of numbers. This is largely compatible with the core guidelines in in the couple places where we find it is not quite in line. I really look forward to working out under what circumstances is that Guidance the correct guidance or just fixing ours and then there's standard Alternatives how to alienate my friends on the committee. I
promise it's not actually that bad. So the standard design priorities for the standard you do not pay for what you do not use like this has been mentioned five times and talks that I've been to so far the conference and further. Honestly, I'm not sure the committee agrees on a whole lot more than that. But as far as it goes, this is a really important guiding principle for the standard and it is a big big part of why the standard works. This is a very good thing. This is the right thing. A side effect of that is for any problems faced that the standard is solving if there is run time
over head for some designer feature on a reasonable platformer workload. We the committee will find an option to avoid it will design a different solution. So let's look at the example of chromium Chrono needs to work just as well. If you are in high frequency trading where the CPU costs of time operations on nanoseconds actually start to dominate the discussion. Kronos should also work on an embedded microcontroller that has 16 second or 16-bit 1 second fix controller cannot afford the Precision and requirements of the high-frequency
Traders Norwood the microcontroller system even remotely suffice for the traitors. And so they cplusplus solution is of course, we added template are compromises class templates by default new representation for duration in time point is a signed integer. This leads directly to things like by default. You can't express in infinite duration and there is undefined behavior on overflowed that is what signed integers do and this makes perfect complete sense in a world where you cannot afford any additional expense or the safety check don't matter.
But this is clearly not the only sensible set of design priorities or design constraints. What if we wanted something other than don't pay for what you don't use what if we prioritize safety Clarity ease of use and still didn't want to write in Java. So we're shipping time and duration. These are classes not templates. They happened to be I think 96 gets right now, but their representation could change they have saturated fat infinite future in for the duration. If you do math on an infinite, it stays infinite never undefined and
asking for what time is it now is usually the last time I ran a benchmark on this it was twice as fast. We've optimized cuz we run a lot of stuff. We also have a slight design differences for mutant has a little bit more stuff built into it. It has reader look wider locks. So the standards before you text me text. Once you have built your whole system and you discover that you have contention on that new text and that you would be well-served by changing it to a
read lock instead of an exclusive lock. Then you have to go thread shared mutex through all of those apis to make sure that you can take a shared lock. For us is just one type there is a little bit of overhead on it, but it does make the ability to use that feature much more readily available. You don't have to do a p I am faxing for factoring just have to go find the places where you're only grabbing it for read change it to a relock. In debug mode, we have deadlock detection built-in. This is theoretical deadlock detection not practical deadlock
detection. It's not okay. You seem to be hung. It's we are doing the graph Theory to identify what order your mean texts are taken in By Any Given thread and if one thread grabs a and then B and the other thread grabs being in a serious overtime sometime you're going to deadlock. We just notify you of that in debug mode. And also have a slightly harder to misuse API notice if you using the standard new text you have to have a separate condition variable to lock is a music CD is a condition variable and you specifically have to figure something on the condition
variable to say done. Absolute X note the major differences in that finish. How come you text when you unlock the new text says anyone waiting? Can I check any of these conditions and then it goes into value at the condition? You can't it's harder to misuse because you can't forget to Signal which is kind of nice. A build-in put their very very few Flags to the build traps that will try to Intuit everything from compiler and puts things are provided by your
tools are not things that are user-specified one that we do have is Absol alligator know through the standard go back once to be applicable everywhere. But his also very hesitant to allow the possibility of build mode at the standards level. I'm going to be pragmatic in some cases. The result isn't entirely satisfying so many platforms don't have throwing allocation failure. If you allocate there's no memory of ailable your process crashes or the operating system Moon killer starts killing off something else. however, because the standard allows for the possibility that all
allocation is an exception any type that may allocate during move construction can't be no except pictures of all of those types are slower to resize using a vector of a type on a platform where you aren't actually going to throw every time that you resize that Vector you are paying. I'm cell recognizes that this is annoying and provides Bill system hook so you can Define centrally does my default alligator throat and guidance for how you can tag your own move Constructors accordingly. Then if you build on a non throwing platform vectors of
those types just work better and I'm throwing platforms. It's all still good incompatible incorrect. We aren't saying that you can't work on a platform the throes we're just saying that many of you aren't on one and maybe you should have a more effective efficient Vector resize We are not competing with the standard standard is still much bigger. These aren't better designs. These are designs resulting from different priorities and different engineering Legacy. You should decide which set priorities works for you and standard is still unquestionably the right thing for your offer
Billy. Does a brief introduction for a sale before we wrap up? Let's Circle back around and get kind of the big picture with abseil as an example is considered what makes cplusplus particularly well suited or not for that head titled talk after all. We have some sandwiches. We don't have the standard build flags are build modes. The one definition of rule makes pre building anything with potentially different build configuration. Very dangerous. Very bad taken together these mean that Source distribution is pretty common. And while these technical challenges in general every
challenge is an opportunity and the result of source distribution being as technically necessary as it is in C plus plus means that live at head is may be more useful necessary and impactful. I also think it's the case in C plus plus he's a particularly challenging language. Maybe it is because I am so steeped in it. But it to me, it feels like other languages provide fewer surprising mechanisms for a change to break her abuser. Like if we were doing out sale in Java, we wouldn't have rules like don't depend on ATL or don't use the global namespace. I'm not sure there is job equivalents
that have the same language level. So maybe they do maybe I'm just not up enough in Java to know where all of this the pitfalls lie, but my reputation I do suspect that we're special here. This all means that we have to be a little bit more clear about what we require from users. Also on the downside of a standard system does make all of this more challenging than it would be otherwise The upside we don't have a standard package manager something I can live at head world is not going to fly nearly as well in Python where the community has completely formed
around. This is the way that we do dependencies in package management. We do have good and consistent unit test according to a recent stack Overflow survey for C plus plus if you take Google test and boost test that covers about 75% of unit test framework usage does nice because it means you the non-expert can run the tests for a thing that broke without having to know a whole lot about how do I even run these tests only a couple of it? And of course in order to make tooling work, we need good tooling the things that we do these days on a pretty regular basis would have been waived
office clearly impossible 10 years ago. It is still not perfect. We're missing off the shelf support for some common patterns, but it's all incremental things that are missing off the core revolutionary Tech. It's like we've invented cold fusion. We just haven't figured out how to rig it up for the power or maybe we've got cold fusion, but it needs a slightly different distribution Network. And so we need to build that out and demonstrate demand at the same time. Answer the call to action concretely. What does it take to push us as an industry and a community
from where we are to a live at head world? I need you to consider engineering vs. Programming. When you're doing a thing does that thing? What is the lifespan of that thing that need to live indefinitely Rosetta need to live until Thursday? You need to be aware that there's a difference between those and you need to behave differently. I said in a talk over the summer computer programming right now. It's one of the only two names I know of where there's something like a for order of magnitude difference between how short something might live and how long
something might live right? It is entirely possible that you write a thing any work done with it the first time it runs and it is entirely possible that you write a thing and it lives for 50 years. It is insanity for us to believe that the same rules and guidance and principles apply on both ends of that Spectre. Please be aware of what you are doing. Understand your dependencies. What does the standard provide? What does the standard ask of you? behave accordingly Right will behave code this is I need a better term for this. I
really sort of wanted it to be up to code, but that was confusing. Use up-to-date versions of things. I don't pin to some six-month-old dependency. You don't need to buy tools when provided right test you can do all of this. We can change the way we conceptualize change specially this ridiculous idea of breaking changes. We can understand the engineering quality of libraries that we depend on rather than just the programming sufficiency. We can find a far better world.
As users if you help us by living at head when you can cooperating with us, as we figure this out will help lead you to a better world as Library authors. If you follow the same ideals tell your users what to expect make change carefully and make it easy to work with will help lead you to a better world where you can make the changes you desire without harming your users. It is going to be a bumpy road to get their change is not easy, but I have been saying for years. It is important that it is impossible that is true for code that is true for communities and I hope it can
be true for this one. And of course abseil is no different will change to there will be a whole bunch of more stuff that comes this is just the initial drop my plans go out probably at least 3 years. While you are still here, I'm really recommend sort of spiritual follow-up talks not cool. What kind of things mentioned earlier talking about Google and have tables on Wednesday for my team. John Cohen is talking about what it takes to move to rename a type with learned a little bit about that in the last year. Gennady Rosenthal we'll talk about ABI
issues and part of why it is so important that you not depend on if we can file representation of this code. And also today I will give it a Hands-On with abseil assuming I'm still conscious which should answer some of your questions here. I cannot even remotely claim the Lion Share the responsibility for this. This is the work of many fine people. Thank you all so very much. And volunteers not quite on my team some former team. And for those of you from my team that are watching this remotely I recognize that you have more
important things going on. Thank you for bringing up the next generation of ab sailors. And with that I will turn it over to the audience for questions. It's well-known that Google codebase does not support to use exceptions. How well does Absol play with exceptions? aspirational so by that I specifically mean I'm not aware of any glaring places that it's a problem if you can identify. Oh this obviously needs to be exception safe and currently isn't will definitely accept that patch a low-level Library needs to be supportive of
all comers that said There Are Places not all exceptions are smart. If you decide that your hash filter is going to throw I'm just going to take it. No accepted laugh at you. There are some things that just aren't completely Preposterous and not a good design. Like exceptions should not work everywhere. They should work in sensible place and we'll try to make that work but it's going to be sort of a balancing act cuz yeah, it's not our area of expertise so we'll have to learn from you. I thank you for the great talk.
My question is about compatibility and new features. So unified Colson tax. I also known as in different languages as extension methods. What kind of concerns do you think there are or how could the standard move forward to actually have something like extension methods? So my concern with unified syntax initially is specifically I don't want you extending my types. Because if I then need to add that same API. I'm constrained by what you did or I'm breaking your code or is the semantic change I would be perfectly accepting of unified syntax. Not as
arbitrary user gets to arbitrarily extend my library. I would be perfectly happy with unified syntax. As you can have extension points within the same module boundary things like that, but I need control over how you use my library. And the initial proposals for unified syntax. I was concerned. Okay. Thank you. How you talked about the kinds of guarantees that the app cell makes and what you think the standard will making you mentioned the notion of a call only interface. So I mean, it's quick, easy pass pass. If you right,
you know generic code to have to you know, check these sort of things. So basically things like if you wanted to check is constructible as opposed to actually constructing something that wouldn't be covered. So basically if you're you know an application developer, but you have to write some piece of generic code for your company for use case. You have no guarantees at all from the standard or from abseil. I mean why why depend on on abseil if your genetic code doesn't have any guarantees just keep writing your own genetic
code all the way down there is bequest true and if you want to control like it's on you to control it between no guarantee and it's not going to work if you were checking if it's constructible in order instructed. And then you could drop it. That's one sign. If you are checking if it's constructible and then you go do a computation or some random other thing, right? That's a completely different at that's a horse of a different color issue becomes. It is easy for us is far
easier for us to specify there's no guarantees. If you reprobates you depend on these metal properties of things because listing off the things that you could potentially use the existing behavior for in a way that's likely to be fine in the future. I don't know how to come up with that one. And when in doubt like a big part of why today is a big deal is I don't get to live in my little hobbit-hole of internal Google anymore. Like I have to participate with rest of world. So if you have that I would like to
defend on this you could ask send an email. I know you're completely insane or not. I can't actually imagine how in practice it's going to be a problem. You're fine. Right but first things as complicated as programming It's awfully reductive to try to just narrow it all down to something good to be too silly written in a list into practice asking is a really good answer. Thank you Google. So the code base is I mentioned about 250 million lines of Google offered C plus plus code. It is big. Yes, the original
factoring tools that Chandler initially Cobble together to give my team. These were man produces. The code base itself is not stored in the map reduce. I don't think that's quite what you meant, but you do basically Parallel build and run the tool over each translation unit separately and then reduce it down into like to get rid of the Dukes and headers and things like that. So you can generate said that it's across code base is not going to be what we rely on and because the mapreduce infrastructure two things one, the mapreduce infrastructure isn't quite the right
thing for the rest of the world and to largely we wind up doing that because our code bases freaking bananas huge for most people it client ID check and run it overnight on your code should be fine. Festivals. Thank you for the great talk about author of a library and I'm interested in how to make the alphabet easy. As you said that specifically what do you suggest should be in the tools? Like they should I provide tools for my users to operate quickly and
how should they work or so is the question. How do I upgrade? Like what? What version of the library is checked in or how do they upgrade their usage of the library to an incompatible API? The first one what do you suggest should be in the tools to make it 8 don't think it's your responsibility to provide tools for your user changing their version that users should know that you are providing something that will be stable and accurate in overtime and should just upgrade aggressively.
Riverhead So what is the purpose of the tools actually the tools are for when changes to the users code are necessary in order to react to a changing implementation or a pee when they do that update their bills will break or their their code will not execute correctly as a result of some change in their underlined dependency. Tool to execute fix their codebase move on. We have a quarter of a billion lines of code already depending on this when we make a change we have to audit.
Okay. Thank you very much. Do I see both snake kazon passcode cave in your public API. Yes, so we sneaked taste when we are specifically trying to match something out of the standard and we Pascal case or camelcase because that's how the vast majority of our code is written. All right, well already ruined. Not know. It's okay. It was just a joke. I think you We have initiative with my company that is quite similar to the library or future standards and some proposals.
More General tool set could be made most of that Library are here today, but I haven't won more technical questions regarding your ADL requirements. Do you rely on ATL internally in your library? Generally not there may be a couple places that snuck through but I believe that we have explicitly qualified everything not fully qualified, but everything is packed. That's partly because we want the implementation and usage and testing of our code to look like how the user is going to use it so that we know more fully like that look, right.
Are you give an example of a 04 Grand Prix coordinator walk around which you outlines in the library? And you said that you have 5 years old for wish you were to move it. I want to know how I am going to my tenant because it should be enormous number of places in the library where you have some kind of stuff and it should be just like human readable. And then when you come over it's around that automation is going to ever pay off. Like I think there's probably I don't know 20 or 30 sort of work around that we've got in there right now for those sorts of random
little collection. Spending any significant time automation to work around 20 or 30 things. Probably not worth it much easier to just Have a reminder set for five years from now and have it pop up in your inbox be like, okay, I get to leave a hundred lines of code today. Thank you. So I was curious about the ATL saying like a lot of operator overloading uses ATL and I think you like kind of covered it in the talk. But like I want to be able to like a
outlet you see out on a string View and like that uses ATL. so like how do you expect to solve that I don't want to see out you don't need to use a DL for like function invitations. Everything's going to work out fine in the normal expected fashion without going to work just fine. It is really just unqualified call especially into Absol where things become a problem. So so it's not like don't use ATL. It's like don't use ATL for function call radio when you're just being lazy. If it's an API that specifically is like necessitates ATL
like streams. Hi guide to question. Number one is Windows as a support a platform for you all the way we'll we'll try it is not our area of expertise like one of those things that I really like about all of this. This is the stuff that's running introduction. This is Battle tested but much like, you know any given Army in a battle is is Battle hardened against the things that they've experienced right? Like the Crusaders battle-hardened won't matter when the Martians show up. So I'm sure that
there are going to be things that surprised this when we branched out into deeper and more lasting ties onto other platforms and we'll try to work around in. The second question is now you Advocate providing tools for Library vendors so that they can upgrade that users. Does that mean that every one of us has to provide like a client Plug-In or something or do you see this working? I think the The Toy Story is evolving for us like our bread-and-butter is client ID plugins. I really hope that this
Spurs more innovation in having other platforms that do that I recognize that there are going to be some windows cobase is it still just can't deal with crying for whatever reason and we're going to have to negotiate all of that but a big part of all of this is a lot of what we're currently doing is in Siri. one thing and then practice the world is a very different place. And so I'm just going to try to push it all down into it's just be practical just do these things in practice and see how it works. And if it's insufficient,
then we'll know where to invest more resources going forward. Okay, so we will leave at 8 and we didn't clean ourselves to a particular version of a library from sources. I was great. But what about Bill X? play Mother by another CPU use AWS like I don't know like this is also a place where our priorities are going to change or going to show through our experiences. We have a really massive Bill farm and why don't care about you adding an extra include and I know that that's not everyone to experience. It may turn out that makes it in palatable but practically speaking
Dylan times are an annoyance that is also a stalled technical problem. It is one of resources. Maintenance of a library and an ecosystem is not a soft technical problem. And we need to claw back some of that in order to solve it or have it prayers. So that said I can build everything on have sale on the laptop in 30 seconds. So so think of you as saying that bill X is not on the top lights of your priority list is a programming problem. I'm trying to plan for
how does this work for the next 10 years. That's an engineering problem. Sorry. Okay. Thanks. Hi, I got a question with a question. Even if we can resolve the double-time problem because I don't know we get some infrastructure that as awesome as you are there still an issue of Brothers released like to know knots daily birthday every free moment for 6 months and that we have to support for five years or even ten years. Can we still live with that? Maybe it's going to be very like depending on exactly what promises you're making in
that code going to be dependent on are you exporting abseil types 3 or apis? Cuz that's a whole different world. Like there's not a single simple answer because fundamentally all of these things are really really complicated. I say often software engineering is the solving the hardest current solvable problems because everything else he's he's already been and everything that isn't quite solvable is off the other end of the cliff. And so everything that we're doing here is solving
the stuff on that ragged Edge, and we're trying to build better and better infrastructure for leaning further out the cliff. It's not going to be easy. There's not a off the shelf, right? But what about I don't know if I have a bag because I have to fix and rebuild for 5 year old version if you do not provide or finding out how do I you know, I get you if your stuff and then rebuild the refrain from 5 years ago. You should in that instant probably pin to a five year old version for your five-year-old maintenance thing and practically speaking. I recognize that
not everyone is going to be able to pull off the whole thing. One of the things as protobuf in the RPC and etcetera starts depending on us rather than have willy-nilly releases of that growing dependency chain. What I'm going to do the weather in Practical not is every six months or so, I will just tag whatever is currently there and say will support this for a couple years if anything important comes up, I don't recommend that it doesn't scale. But practically speaking it's this is a big ship. It's going to take awhile to steer it
super got one more time for anyone else. That wasn't mine. I will do a bunch of questions in this afternoon session. So please take a look at the library and then we'll talk. But congratulations on releasing at 2. So package managers. I think I heard you say that you think the lack of package managers is actually a boon to the living head philosophy. I tend to be of the opposite opinion that the lack of package management is one of the things that hold C plus plus back. So did I hear
you correctly? And do you see the black a package management as a good thing or would it be possible to have package managers that work in the livid head or less? I believe there would be. Like there's definitely in Siri package Management systems that work better for little head. Right? If we just do a thing that is hey you're sober again for C plus plus code and if you use this tool chain here 3 compiled code and otherwise, I guess maybe we have Source distribution and maybe we have compatible build systems and I don't know what else like that's not going to
solve anything. That's just going to read it more down this path that I don't think works. And I think there is a solution where we make it clear. Where does the code live? We make it clear how to pull it and make it clear like what is current and that would be great. I think that would be a much better world. So it's not all about it's just the most likely scenarios seem like bad ones. Thanks. Thank you all. Best films future event with multiple cameras link to presentation slides add titles and edit your event live for a full broadcast experience,
you know, look at a lot of ways. Football pro pilot you a little time to do a profile for it. I'll see exactly what it is. That's making this faster or slower by looking at the profile like this. I worked at Sesame Street. I got brought on to be a writer's assistant on a show called Sesame Street English which was to teach English to kids in China and Japan. It seems very simple the shows that they put together but it's it's actually really hard to design a show
that is not only for young kids, but also the parents. Compassion like this is therapeutic. I hope you all get something out of this. But if you don't but there are people been good for me. So thank you seven years ago. I was working. I wasn't working for my previous employer which was large multinational Investment Bank. I have what was up to that point the worst day of my career and then came the anger anger at ourselves because we knew we were responsible for America's first space disaster. We were out to more words into our vocabularies mission controllers
while never again shirt for my responsibilities because we are forever accountable for what we do confident will never again take anything for granted. We will never stop learning from now on the teams and Mission Control will be perfect because as a team, we must never fail one of the things we're all in a very fortunate position. We've been very lucky our lives and so forth and I think is part of the mission. It's also good sometimes take that fortune and give back. To make sure that you take
a platform and use it towards were the fathers. That's good karma. That's good stuff from Universe your organization. Please email or call us directly to discuss your particular event. We look forward to discussing your goals and helping make your event a success.
Buy this talk
Доступ ко всем записям докладов мероприятия
Buy this video
With ConferenceCast.tv, you get access to our library of the world's best conference talks.