rsc
Tridge doesn't owe anyone anything as far as rsync is concerned. Yet he is spending his time maintaining it, only to be attacked for his efforts.
To respond to the specific technical point, there really _is_ a flood of security reports arriving everywhere in the past few months. The jury is out on whether Mythos is that much better than alternatives, but even the publicly available models are _highly_ capable of finding real problems, and they are being employed to that end quite effectively. Here are the counts of security issues fixed in each monthly Go minor release going back to the start of 2024:
0 2024-01-09 Go 1.21.6, Go 1.20.13
0 2024-02-06 Go 1.21.7, Go 1.20.14
5 2024-03-05 Go 1.22.1, Go 1.21.8
1 2024-04-03 Go 1.22.2, Go 1.21.9
2 2024-05-07 Go 1.22.3, Go 1.21.10
2 2024-06-04 Go 1.22.4, Go 1.21.11
1 2024-07-02 Go 1.22.5, Go 1.21.12
0 2024-08-06 Go 1.22.6, Go 1.21.13
3 2024-09-05 Go 1.23.1, Go 1.22.7
0 2024-10-01 Go 1.23.2, Go 1.22.8
0 2024-11-06 Go 1.23.3, Go 1.22.9
0 2024-12-03 Go 1.23.4, Go 1.22.10
2 2025-01-16 Go 1.23.5, Go 1.22.11
1 2025-02-04 Go 1.23.6, Go 1.22.12
1 2025-03-04 Go 1.24.1, Go 1.23.7
1 2025-04-01 Go 1.24.2, Go 1.23.8
1 2025-05-06 Go 1.24.3, Go 1.23.9
3 2025-06-05 Go 1.24.4, Go 1.23.10
1 2025-07-08 Go 1.24.5, Go 1.23.11
2 2025-08-06 Go 1.24.6, Go 1.23.12
1 2025-09-03 Go 1.25.1, Go 1.24.7
10 2025-10-07 Go 1.25.2, Go 1.24.8
* 2025-10-13 Go 1.25.3, Go 1.24.9
0 2025-11-05 Go 1.25.4, Go 1.24.10
2 2025-12-02 Go 1.25.5, Go 1.24.11
6 2026-01-15 Go 1.25.6, Go 1.24.12
2 2026-02-04 Go 1.25.7, Go 1.24.13
5 2026-03-05 Go 1.26.1, Go 1.25.8
10 2026-04-07 Go 1.26.2, Go 1.25.9
11 2026-05-07 Go 1.26.3, Go 1.25.10
3 2026-06-02 Go 1.26.4, Go 1.25.11
You can see that 2026 has been quite different from the previous years. There are plenty of other contemporaneous accounts from other security teams about the load increase they've seen (which again is almost entirely not Mythos).
Also, the number of reports we are receiving has gone up far faster than the number of actual vulnerabilities. Over the 75-month period from January 2020 to early April 2026, the final 30 days accounted for ~16% of the reports.
It is easy to believe that Tridge is seeing a similar flood of reports. More reports means more fixes means more code changes means more bugs.
https://www.lysator.liu.se/c/pikestyle.html http://www.literateprogramming.com/pikestyle.pdf
I apologize for the traffic. We clearly need to look at the “thundering herd” you are observing. That shouldn’t be happening at all.
Separately, the bug we fixed last time were about repeatedly cloning a repo in sequence even if it was unchanged, not about redundant parallel fetches. We fixed that only for Git, because Git makes it very easy to look at a branch or tag and get the tree hash, without downloading the full repo. This is exposed as the go command’s -reuse flag. The relevant Git code is at https://go.dev/src/cmd/go/internal/modfetch/codehost/git.go#... (CheckReuse).
What we need from any VCS to implement the reuse check is a cheap way to download a list of every tag and branch along with a cryptographic file tree checksum for each one, without doing a full repo clone. At the time, I convinced myself Mercurial did not support this. Perhaps I was wrong or perhaps it does now. If anyone can help us understand how that works, we could implement the -reuse flag for Mercurial too. (Any other VCSs would be great too, but Git is #1 by a very wide margin and I believe Mercurial is #2 also by a wide margin.)
Again, apologies for all the traffic, and thanks to Ted for the excellent analysis. We will look into both.
Better to structure your code so that you do the pointer manipulation (and allocation) in Go code instead, and leave assembly only for what is absolutely necessary for performance (usually things like bulk operations, special instructions, and so on).
In my August announcement, I was careful to say I wasn't leaving the Go project. I'm still involved with the Go project and expect to keep being involved. I'm just not officially on the Go team at Google anymore. Stepping back from the actual team to give others room to lead always seemed to me both likely and appropriate.
https://go.googlesource.com/mod/+/refs/heads/master/module/m... https://go.googlesource.com/mod/+/refs/heads/master/module/m...
If you want to use c-shared mode and dlopen, then yes that only works with glibc, but that mode barely works at all anyway. It's not actively supported at all.
I don't intend to make more of those, but that was a lot of fun.
> Creeping dependencies can also affect the size of your project. During the development of Google’s Sawzall—a JIT’ed logs processing language—the authors discovered at various times that the main interpreter binary contained not just Sawzall’s JIT but also (unused) PostScript, Python, and JavaScript interpreters. Each time, the culprit turned out to be unused dependencies declared by some library Sawzall did depend on, combined with the fact that Google’s build system eliminated any manual effort needed to start using a new dependency.. This kind of error is the reason that the Go language makes importing an unused package a compile-time error.
You're quite welcome, and thank you for this comment. I never expected when we started that Go would have such a positive impact on people's lives, bringing new people into programming and software engineering. That's definitely the impact I'm most proud of.
I don't believe this is true at all. They are both highly active in external Go development, far more active than I have been these past few years. (It's true that neither gives talks or blogs as much as I do.)
(saagarjha seems to be talking about 'git bisect', which is not really what the post is about.)
If there are two different call stacks that get to the function in question, but only one of them is where the failure begins, you absolutely want to distinguish those.
In practice we do cut off the stacks, using just 16 frames, but that's to avoid O(stack depth) overhead, not to coalesce different things.