14 Hacker News comments link this video. Each one links back to its thread.
ithkuilNov 2020Recommends
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)
in “An ex-Googler’s guide to dev tools” · View on HN
klodolphOct 2020Recommends
> 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 project, and do so in a very automatic and reliable way, you can provide people with tools tools for updating downstream code when upstream code changes. I think people are focusing too much on Bazel as only a build system and not as part of a platform for building developer tooling, and people are focusing too much on Bazel’s original incarnation as a build system for a massive monorepo. I think there’s also a reality that we must deal with that is—as software gets larger and more complex, and as we have more dependencies, relying on version pinning for stability is losing ground as a technique for making our software more reliable. We have many more dependencies in our software now, so just subscribing to a mail feed of all of the version bumps in the libraries you use would be enough to dr
in “Bazel Build System Support for LLVM” · View on HN
s3cur3Jul 2020Recommends
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.
in “Stop Abusing Semver” · View on HN
kinjba11Oct 2019Recommends
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
in “Why async fn in traits are hard” · View on HN
jacobparkerApr 2019Recommends
> 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).
in “Keeping master green at scale” · View on HN
otFeb 2018Recommends
Relevant talk by Google at CppCon last year focused on C++, but really talks about getting rid of versioning in general. ▶ this video
in “Advantages of monolithic version control” · View on HN
Show 8 more comments
nsmDec 2017Recommends
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.
in “Why Google stores billions of lines of code in a single repository (2016)” · View on HN
XunjinAug 2022Cites it
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]: ▶ this video
in “C23 is finished: Here is what is on the menu” · View on HN
JamesSwiftSep 2020Cites it
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] - ▶ this video
in “Go’s Major Versioning Sucks – From a Fanboy” · View on HN
rurounijonesJul 2020Cites it
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 ▶ this video (Linked from another comment) and he goes into good details about issues with Semver.
in “Stop Abusing Semver” · View on HN
joshuamortonMay 2020Cites it
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: ▶ this video
in “Goals and Priorities for C++” · View on HN
lytigasMar 2020Cites it
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: ▶ 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.
in “What If C++ Abandoned Backward Compatibility?” · View on HN
joshuamortonMay 2019Cites it
> 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 major issues and incompatibilities. (think IPV4 -> IPV6 for an example where a "global" `parse_addr` function would have made everyone's lives easier). You can bet on the assumption that mangle_name will never change, but then you aren't doing software engineering[1] All of these are the wrong solution 4. Core utilities like this get factored out into their own files. In a multi-repo environment, everyone depends on the entire core/util repo. In a monorepo environment, you depend on the granular files you need. 4 is the only correct solution, and note that in a monorepo environment it results in you depending on fewer things than in a multi-repo environment. Yes there are a lot of ways to do things wrong, But that's true no matter what tooling you use. When used "correctly", monorepos have
in “Benefits of a Monorepo” · View on HN
ndh2Jan 2018Cites it
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 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] ▶ this video
in “C++ and the Culture of Complexity (2013)” · View on HN