CppCon 2017: Titus Winters “C++ as a 'Live at Head' Language”

—
—
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.
—
Titus Winters: Google, C++ Codebase Cultivator, NYC

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.
—

*-----*
*-----*

[Omnifarious]

I've been saying this for years (since I worked at Amazon in 2003/4/5). It's very gratifying to learn that this person has come to the same conclusion.

It was so frustrating to be stuck with an old version of RH and an old version of gcc at Amazon then. My argument then was that they should give developers desktops that had everything new, and a test environment that had all the old stuff. Stupid dependencies would get sanded off over time.

Depending on a particular version is really inefficient and terribly brittle. It's the wrong answer. I've always felt that way. I've really disliked tools for Python like virtualenv because they encourage a model I think is fundamentally broken.

[victornoagbodji]

"Engineering is programming integrated over time" -- Titus Winters. i need this quote framed somewhere (i am not a c++ dev lol, love you guys all the same)

[usx]

I worked at Amazon in 2015. I really didn't like the versioning and stupid dependencies among the different versions of different libraries.
Now I am at google and the developer experience is blissful <3

[howardhinnant]

Concerning absl::Duration.  Why not write a absl::int96 (or however you want to do your safe and saturating arithmetic), and then use std::chrono::duration<absl::int96, Ratio>?  You could even type alias this to absl::Duration.  The advantage of this technique is that now your absl::int96 work is available for all kinds of other needs, in addition to addressing a need in time keeping.  And you assure your users that you are using a time-tested and familiar interface (chrono).

[daggawagga]

Where does the name Abseil come from? I couldn't find that on Google (yet).

[von_nobody]

One question, if you can automatically change usage of some library in code base, then why you need to do this at all? This mean that this code base do not depends on most of this api. This is equivalent to crating couple of wrappers and use them in your code and change manually only this couple of function not whole code base.

[ShakkIsLife]

I hope Chandler is presenting this year!

[fdwr]

1:10:19 "I don't want you extending my types."
It's merely your library. It's MY app. If I want to accept the possibility of my app breaking in the future after updating to a newer abseil, that's my burden to gauge. UFC = 👍.

[FedJimSmith]

Google is great at many things... I like this

[joe-tirz]

Programming. The act of creating programs

[ABaumstumpf]

hearing the words at 1:23:10 is... well, disheartening. It is one of the problems that affect millions and costs a lot of resources during development.
"Buy another CPU" is not a solution for development - if you have the time and money to create large build-systems that are available to everyone ok. But if you need to change some parts of the code right then and there for say a live-hotfix.... yeah, it is not nice if you know that your small bugfix, cause it is in a template-heavy reagion linked by many, will take many hours to compile.
This is a problem not just for the compilers and build-tools but of the language it self - the way includes, global lifetime etc works can force a compiler to translate the exact same files docents or even hundreds of times just to compile the project once. And templates are already costly as they are, if you then have constexpr too then yeah - the language forces the compilers to do a lot of work there.

The answer also kinda goes against what the rest of the talk says:
"Hey, with these changes you can save a lot of resources in the long run - but for compiletime no, we don't care".

[JiveDadson]

I waited for 29 minutes to find out what "live at head" means. I have decided I don't need to know that badly.