Skip to content
0:00 / 0:00

#abseil#hyrum'slaw#monorepo

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

CppCon

189K subscribers • 103 videos on Hallway • Conference channel

YouTube
  • Recommended by 7 people: 7 on Hacker News.
  • Presented by Titus Winters, Software Engineer at Google
  • Linked in the descriptionCppCon/CppCon2017
  • An opinion. It argues one side of a question engineers disagree on.

Advanced. Deep dive for people who know the field.

53K views9 years ago7 recommendations

Programming languagesTools and practiceC++TestingRefactoring and legacy code

Titus Winters explains Google's approach to maintaining C++ codebases by building from source at head, relying on automated refactoring and testing instead of strict ABI stability.

CppCon.org — Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2017 — 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. — Videos Filmed & Edited by Bash Films: BashFilms.com Work at Hudson River Trading (HRT): tinyurl.com/safxfctf --- Videos Filmed & Edited by Bash Films: BashFilms.com

Why it's here

7 people recommend this

What people say. Highly recommended for its insights into dependency management, monorepos, Hyrum's Law, and the challenges of long-term software maintenance.

nsmon Hacker News • Recommends

On “Why Google stores billions of lines of code in a single repository (2016)”

There is a great talk by their C++ dev team about how a build everything from source, mono repo really helps with C++ change enablement link to this video Personally, I’d have to agree that at a minimum a mono repo per distinct product role (server side in one mono repo, desktop software in one mono repo) is immensely valuable.

oton Hacker News • Recommends

On “Advantages of monolithic version control”

Relevant talk by Google at CppCon last year focused on C++, but really talks about getting rid of versioning in general. link to this video

jacobparkeron Hacker News • Recommends

On “Keeping master green at scale”

> You are totally correct that to achieve the same performance, correctness, and overall master level "green"ness in a multirepo system you would have to either define or detect dependencies and dependent repos, build the entire affected chain, and test the result. That part is much easier in monorepo. You also would need to do that as an atomic operation (in the mono-repo + especially with a commit queue you're building on the atomicity of git). Having to unwinding that transaction if you aren't atomic can get you into a big mess at larger scales. Here's a good related talk: C++ as a "Live at Head" language: link to this video by Titus Winters (from Google).

kinjba11on Hacker News • Recommends

On “Why async fn in traits are hard”

Semantic versioning isn't a silver bullet, unfortunately, due to the 'Diamond Dependency Problem'. That is, A depends on B and C, but B and C depend on different versions of D. Easy to fix, until you scale that up to thousands of nodes in a dependency graph. This talk is one of the better ones about this: link to this video

s3cur3on Hacker News • Recommends

On “Stop Abusing Semver”

For another perspective on “semver is a lie,” see the “Live at Head” talk from Titus Winters of the Google core C++ team. link to this video TL;DW: By Hyrum’s law, at sufficient scale, there’s no such thing as a non-breaking change (including changing comments). Embrace that, and test sufficiently that you can always take the latest dependency but detect when it breaks.

klodolphon Hacker News • Recommends

On “Bazel Build System Support for LLVM”

> If you go listen to Google people talk about dependency/version management. It's like they think it's global lock vs inconsistency. Monorepo or chaos. This false choice irks me. I watched this talk: link to this video I’d say this is a much more nuanced look at dependencies & versioning. We all know these days that something like semantic versioning is not enough, because it is too easy to depend on behavior which the developers of your dependencies did not expect you to depend on. So you need something more powerful than just having a bunch of developers get together and agree not to break each others’ code. Bazel is a part of that solution—if you can analyze and understand the dependencies in a pro…

ithkuilon Hacker News • Recommends

On “An ex-Googler’s guide to dev tools”

Usually that problem is dealt with combination of: * Automation. * Ability to change other people's code safely, possibly gated by code review approval. Cultural and technical (e.g. unit tests must exist and be maintained) barriers may apply. * Making incremental changes that are backward compatible (at least until you migrated all clients so you can cleanup later) I recommend this talk link to this video (even if the scope is broader than your question) (ex-googler)

ndh2on Hacker News • Mentions

On “C++ and the Culture of Complexity (2013)”

…or C++, too. They just don't bother sharing it with us peasants. The fundamental mistake of C++ is to religiously keep backwards-compatibility with everything for all eternity. It's so easy to say that backwards-compatibility is a good thing. It's obvious! But ultimately that decision is the reason for all the problems that C++ has. 1 link 2 link to this video…

joshuamortonon Hacker News • Mentions

On “Benefits of a Monorepo”

> add a huge tree of dependencies without having to think about it. Keep in mind that the alternative is "I have to build (or pull a prebuilt version of) the entirety of every repo that I depend on". An entire repo is always going to be larger than a single target. Yes you're right that pulling in the entirely of {{some large tool}} because you want `tool.strings.util.mangle_name` is bad. The alternatives are 1. (multi-repo) You stick mangle name in its own repo (think `left-pad`) 2. (monorepo) Depend on `tool` in its entirety 3. (either, though more common in multi-repo) Everyone re-implements mangle_name. If the way the name is mangled is important, and it changes in the future, you have m…

lytigason Hacker News • Mentions

On “What If C++ Abandoned Backward Compatibility?”

Some here are saying "Why not just use Rust/D/Zig/Nim/Crystal if you're going to break backwards compatibility?" I believe the proposal is closer to "We've removed this old feature, run this tool to replace it with the new one." C++ will keep looking like C++, not like Rust. Here's Google's "Codebase Cultivator" explaining the idea for their Abseil library: link to this video I remember watching another talk where they propose something similar for the language itself, but I can't find it at the moment.

joshuamortonon Hacker News • Mentions

On “Goals and Priorities for C++”

Specifically, absl (Google's C++ library already provides this guarantee). In general the idea is that they will provide backwards compatibility for 5 years, and provide tooling to update source code to new constructs. This is covered somewhere in this talk: link to this video

rurounijoneson Hacker News • Mentions

On “Stop Abusing Semver”

Not that cut and tried as it depends what "goes into production" means. As an example: Lets say I have an open-source library that I am developing. It is currently version 0.x.y and someone depends on it (without my knowledge because that is usually how it is). Is that now in Production? Should I be forced to make it 1.0.0 even though I am still making large numbers of breaking changes? That is a simple example off the top of my head. I am watching link to this video (Linked from another comment) and he goes into good details about issues with Semver.

JamesSwifton Hacker News • Mentions

On “Go’s Major Versioning Sucks – From a Fanboy”

100% agree. Semver is a _social_ construct not a _technical_ one. There is Semver the spec as originally designed, and Semver as it is currently observed. Semver has become something other than it was originally intended, likely because the idea of "breaking changes" ends up being way more encompassing than people wanted to admit 1. To ignore that reality is a futile fight. 1 - link to this video

Xunjinon Hacker News • Mentions

On “C23 is finished: Here is what is on the menu”

This kind of comment is not helpful at all, I use Rust today however, yet I cannot sometimes deny, it's better to use C depending on the target and restrictions by hardware compilers. Every language has downsides/upsides and time. There is a nice quote by Titus Winters: “Engineering is programming integrated over time”0, this helped me a lot in learning that context matter for tools/languages/frameworks, and you can learn with their mistakes. 0: link to this video