Skip to content
HHackerTube.videoSurprise me

CppCon 2018:H. Wright “Large-Scale Changes at Google: Lessons Learned From 5 Yrs of Mass Migrations”

CppCon 2018:H. Wright “Large-Scale Changes at Google: Lessons Learned From 5 Yrs of Mass Migrations” on HackerTube: recommended by 2 Hacker News commenters across 2 separate months, 2019–2024.

CppCon

talk · advanced · evergreen

Open on YouTube

Hyrum Wright shares lessons from five years of mass code migrations in Google's huge C++ codebase. He covers why to migrate, how hard it really is, and how Google updates core libraries and their users continually.

Why Hacker News recommends it

HN points to it in monorepo and refactoring discussions as a great account of large-scale changes at Google.

people recommended it
2
separate months
2
strong recommendations
0
discussed on HN
2019–2024
“The discussions from Hyrum Wright from Google about large-scale refactoring are great in this respect.”
— ted_dunning, Nov 2024, in “Monorepo – Our Experience”

What HN commenters said

3 Hacker News comments link this video. Each one links back to its thread.

ted_dunningNov 2024Recommends

Coupling happens due to other reasons than poor contracts. The discussions from Hyrum Wright from Google about large-scale refactoring are great in this respect. ▶ this video

in “Monorepo – Our Experience” · View on HN

svatJan 2019Recommends

See Hyrum Wright's talks on Large-Scale Changes at Google: [link] (CppCon2014), ▶ this video (CppCon 2018), and paper by Googlers on ClangMR ( [link] ). It's great! And if you'd like to learn more about how monorepos work in practice there's a couple of papers: [link] and [link] (Also worth reading: [link] )

in “Monorepos: Please don’t” · View on HN

joshuamortonMay 2021Cites it

> Refactors are rarely as simple as moving a few file names or symbols around, at least where I work. While we do have some automation to help (and not break existing consumers), it’s significantly more involved in an SOA architecture for tier1 services. These sorts of big refactors also generally come with data model changes, performance profiling etc. This tool seems fantastic for parts of that, but not all of it. Yes, I'd refer to that as a migration, which absolutely is a lot of effort, but a tool like this isn't going to be particularly helpful with a migration precisely because the majority of the effort with such a migration will be like...doing all the data stuff and traffic stuff. Changing the code is a minimal part. A refactor is often not a thing that even registers at a smaller company, because its on the scale of a few files. But "Large Scale Changes" are a thing when you end up having millions of lines of code ( ▶ this video ), and tools like this one are useful for those kinds of changes. But a single LSC won't get you promoted. And rf is neat, but in a very go way, it's not particularly exciting if you're familiar with [link] or [link] or clangmr or [link] , or outside of google Semgrep and Bowler and others, since its essentially the same, but built in go for go. > Just as a friendly aside, your tone seems strangely defensive (though this may just be my fault reading this tired at 3AM) Not at all. I was however, pointing out that "this was really just a way to bra

in “Rf: an experimental refactoring tool for Go” · View on HN

Topics & tags