CppCon 2017: Titus Winters “C++ as a "Live at Head" Language”
Why Hacker News recommends it
Recommended whenever versioning, semver, monorepos and backward compatibility are debated, for its nuanced treatment of dependencies.
What it is
Titus Winters' CppCon 2017 talk argues for C++ and Google's Abseil to be maintained as a live at head language, relying on testing and automated tooling rather than never changing or promising no compatibility. It covers Hyrum's law and the limits of semantic versioning.
Recommended by 7 HN commenters across 7 different months, 2017 to 2022.
What Hacker News said
Recommends nsm · 2017-12 · 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 [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.
Recommends ot · 2018-02 · 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. [this video]
Recommends jacobparker · 2019-04 · 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: [this video] by Titus Winters (from Google).
Recommends kinjba11 · 2019-10 · 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: [this video]
Recommends s3cur3 · 2020-07 · 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. [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.
Recommends klodolph · 2020-10 · 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: [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
Recommends ithkuil · 2020-11 · 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 [this video] (even if the scope is broader than your question) (ex-googler)
Cites ndh2 · 2018-01 · on “C++ and the Culture of Complexity (2013)”
Lots of posts here frame it like "Yes, it's a bit of a complex language, but the C++ committee has the difficult job of keeping everything backwards compatible, so it's understandable." But that's not the reality. The reality is that they (or Stroustroup) made that decision, and that decision was a mistake. The correct way to deal with backwards compatibility issues is the way Go does it, namely to write tools to automatically upgrade code to a newer API [1]. And as that smug Google guy explained here [2], they have something like this for C++, too. They just don't bother sharing it with us peasants. The fundamental mistake of C++ is to religiously keep backwards-compatibility with everythin