This talk critically examines traditional software engineering practices, particularly C++ dependency management, and advocates for Google's "live at head" philosophy as a more sustainable approach. The speaker challenges Semantic Versioning (SemVer), arguing that its oversimplified compatibility model and the inherent difficulty of defining "breaking changes" (due to "Hiram's Law" where users depend on all observable behaviors) lead to complex, often unsolvable, dependency trees. In contrast, Google's internal monorepo strategy, which enables continuous, large-scale automated refactorings with the burden of providing upgrade tools placed on library authors, is presented as a successful alternative for evolving codebases. To extend this paradigm to the broader C++ community, Google is introducing Abseil, a set of open-source common C++ libraries. Abseil embodies an "engineering focus" on long-term maintainability, encouraging users to "build from source and build from head" by providing clear compatibility guidelines (e.g., avoiding reliance on ABI stability, internal details, or Argument Dependent Lookup) and automated tooling for seamless upgrades. It offers utility code, debugging facilities, C++11 compatible pre-adoptions of C++17 types, and alternative designs for components like time and mutexes that prioritize safety and ease of use over strict "zero overhead" principles. The core message urges the C++ community to distinguish between short-term "programming" and long-term "software engineering," understand explicit dependency promises, adopt "well-behaved" code practices, and embrace continuous integration with automated tooling to foster a more resilient and adaptable software ecosystem.
Summarizing "C++ as a 'Live at Head' Language"
0:00 - Introduction & The Core Problem: The speaker introduces Titus Winters, praising his role in making Google's C++ codebase sustainable. The central theme is the distinction between "programming" (making something work once) and "software engineering" (programming integrated over time, focusing on long-term maintainability and change).
3:03 - Google's Historical Monoculture: Google's past tight control over its toolchain and production environment enabled a "monoculture" that facilitated large-scale, confident changes across its massive codebase.
4:30 - The Need for Change: Mobile and cloud development introduced diverse portability needs, challenging Google's monoculture and requiring a new approach without sacrificing its ability to evolve code at scale.
7:06 - Google's Open Sourcing Strategy: Google is open-sourcing its common C++ libraries (Abseil) to enable broader code sharing, aiming to apply its internal development principles externally.
8:17 - Defining Software Engineering: Software engineering is "programming integrated over time," encompassing challenges like library updates, OS deprecations, language revisions, and changing requirements.
9:57 - Protobufs and "Required Fields" Example: An anecdote illustrates how "required fields" in Protobufs, seemingly logical for immediate functionality, become problematic over time due to deployment complexities and backward compatibility, highlighting the tension between programming and engineering concerns.
15:00 - Critique of Semantic Versioning (SemVer): The speaker argues that SemVer (major.minor.patch) is a "compromised position" for dependency management. It oversimplifies compatibility, relies on a flawed ability to perfectly identify "breaking changes," and often leads to "unsatisfiable dependency trees" as dependency graphs grow quadratically.
21:15 - "Breaking Change" Ambiguity & Hiram's Law: Defining a "breaking change" is shown to be highly ambiguous. Almost anything, from whitespace changes to adding a C++ function overload, can break a user's code. "Hiram's Law" (users will depend on every observable behavior of an API) further complicates this.
26:56 - Solving Diamond Dependencies: "Live at Head" via Monorepo Principles: The "monorepo approach" (where the team making a change is responsible for updating all users) is presented as a solution to diamond dependencies. This relies on automated refactoring tools and rigorous testing to make updates easy even for non-experts.
30:08 - Empowering Change with Tools & Policies: Automated refactoring tools, coupled with policies where library vendors provide upgrade tools for breaking changes and users write "well-behaved" code with unit tests, make large-scale changes and major version bumps manageable.
31:30 - C++ Standard Compatibility Guidelines: The C++ standard is moving towards clearer rules for library users (e.g., don't add to namespace std, don't forward declare types you don't own).
34:52 - Risks of Metaprogramming and ADL: Users are cautioned against relying on metaprogramming, introspection, or Argument Dependent Lookup (ADL) for library types, as these can easily break over time with language and library evolution.
37:25 - The "Live at Head" Vision: Instead of pinning versions, users should "build from source and build from head" (always use the latest version). This works if library maintainers provide tools for graceful upgrades and users adhere to "well-behaved" coding practices.
39:40 - Introducing Abseil: Google's Common C++ Libraries: Google is launching Abseil, open-source C++ common libraries that underpin much of Google's internal codebase and future open-source projects like Protobuf and TensorFlow. Abseil is designed with an "engineering focus" for long-term sustainability.
41:40 - Abseil's "Live at Head" Approach: Abseil encourages users to "live at head." It provides tools for syncing from upstream and strictly defines "well-behaved" code.
43:39 - Abseil Compatibility Requirements for Users: Users of Abseil must not: add to namespace absl, rely on ABI stability or internal details, misuse includes, or rely on ADL (especially for pre-adopted types that might alias to std:: in C++17).
Utility Code: Includes highly optimized string routines (absl::StrSplit, absl::StrCat), debugging, and analysis tools (leak checking, stack traces).
C++11 Compatible C++17 Types: Offers absl::string_view, optional, any, variant that seamlessly alias to their std:: counterparts in C++17 builds, facilitating migration.
Alternative Standard Designs: Provides absl::Time and absl::Duration (classes with saturating arithmetic and infinite values, optimized for Google's scale) and absl::Mutex (with integrated reader/writer locks, debug deadlock detection, and a safer API) that prioritize safety and ease of use over strict "zero overhead" principles, unlike the standard library's defaults.
Build System Flexibility: Includes hooks like absl::allocator_knows_throwing to optimize vector resizing for platforms with non-throwing allocators.
Guidance: Ships with internal "Tip of the Week" essays on C++ best practices.
1:01:09 - C++ Challenges and Opportunities: C++ faces unique challenges for "live at head" (lack of standard build flags/package managers, subtle breaking changes) but also opportunities (source distribution common, consistent unit testing, advanced refactoring tools).
Distinguish Engineering from Programming: Be mindful of code's intended lifespan.
Understand Dependencies: Know library promises and user requirements.
Write "Well-Behaved Code": Use up-to-date versions, apply tools, write tests.
Cooperate and Contribute: Users embrace "live at head," authors provide clear expectations and upgrade tools.
1:08:26 - Q&A Highlights: Discussions included Abseil's exception safety (aspirational), concerns about unified code syntax (extension methods), generic code guarantees (less explicit), Google's refactoring tool infrastructure (MapReduce-based), API naming conventions (snake_case/PascalCase mix), Windows support (aspirational for some features), build times (less of a priority for Google, which has a massive build farm), version pinning for old code (still necessary), and the potential for "live at head" compatible package managers.
Error: value error Invalid operation: The response.text quick accessor requires the response to contain a valid Part, but none were returned. The candidate's finish_reason is 1.