Russ Cox
research.swtch.com · Personal blog · on HN since 2008
Russ Cox, a Go team engineer, writes about programming languages, algorithms, versioning, and clever programming tricks.
What HN saysCommenters call it a great blog and link his posts on QArt codes, Go's minimal version selection, and fast floating-point printing.
554HN people shared it
381linked it in comments
279stories submitted
9.9Kstory points
2 months agolast shared
2008people per year2026
Most-shared posts
- 1The Generic Dilemma (2009)37 people · 33 points · first shared 2012 · 19 comments on HN
- 2QArt – Pictures in QR code with no inherent errors36 people · 190 points · first shared 2012 · 6 comments on HN
- 3Zip Files All the Way Down (2010)31 people · 166 points · first shared 2012 · 10 comments on HN
- 4Plan 9 from User Space (aka plan9port)31 people · 89 points · first shared 2009 · 6 comments on HN
- 5A Tour of the Acme Editor25 people · 367 points · first shared 2012 · 86 comments on HN
- 6Go and Versioning: Minimal Version Selection25 people · 130 points · first shared 2018 · 89 comments on HN
- 7Gorace25 people · first shared 2013
- 8Version SAT22 people · 114 points · first shared 2016 · 19 comments on HN
- 9Go Data Structures: Interfaces (2009)21 people · 159 points · first shared 2012 · 72 comments on HN
- 10Go and Versioning21 people · 4 points · first shared 2018 · discussion on HN
- 11Lessons from the Debian/OpenSSL Fiasco (2008)18 people · 2 points · first shared 2013 · discussion on HN
- 12Using Uninitialized Memory for Fun and Profit17 people · 158 points · first shared 2012 · 18 comments on HN
- 13Libtask: a Coroutine Library for C and Unix17 people · 35 points · first shared 2009 · 8 comments on HN
- 14Our Software Dependency Problem13 people · 488 points · first shared 2019 · 171 comments on HN
- 15Timeline of the xz open source attack10 people · 1.1K points · first shared 2024 · 461 comments on HN
What HN people wrote when they linked it
pbohun · 2026-08-21
Russ also has a great blog, with the most recent entry on fast floating-point printing and parsing. I believe these performance improvements have landed in the latest version of Go.
https://research.swtch.com/fp
squirrellous · 2026-07-20
Here are some that come to mind right now:
https://research.swtch.com/
https://danluu.com/
https://apenwarr.ca/log/
MarkSweep · 2026-07-13
Russ Cox created libtask, a similar library that runs on multiple UNIXes (UNIXEN?). Based on the COPYRIGHT file, it may be based on libthread.
https://swtch.com/libtask/
It’s a great little library. Very easy to read and understand.
wrs · 2025-08-21
The classic Russ Cox QArt code doesn't suffer from this. [0]
[0] https://research.swtch.com/qart
maxmcd · 2025-08-06
For what it's worth I think Go's MVS somewhat meets the desire here. It does not require lockfiles, but also doesn't allow use of multiple different minor/patch versions of a library: https://research.swtch.com/vgo-mvs
I believe Zig is also considering adopting it.
If there are any dependencies with the same major version the algorithm simply picks the newest one of them all (but not the newest in the package registry), so you don't need a lockfile to track version decisions.
Go's go.sum contains checksums to validate content, but is not required for version selection decisions.
anderskaseorg · 2024-08-27
The mechanism is a clever application of quines (self-reproducing programs), first explained in the classic lecture “Reflections on Trusting Trust” by Ken Thompson:
https://dl.acm.org/doi/pdf/10.1145/358198.358210
Russ Cox obtained the actual code for Thompson’s compiler backdoor and presented it here:
https://research.swtch.com/nih
everybodyknows · 2024-08-01
Nomination for RSC's greatest technical contribution: module versioning. Absolutely fundamental to the language ecosystem.
https://research.swtch.com/vgo-intro
dekhn · 2024-05-02
Rob Pike called Russ Cox "future winner of the Kyoto prize".
My favorite is https://research.swtch.com/qart (see also: https://spinroot.com/pico/pjw.html)
MonkeeSage · 2024-04-03
Essentially the code patches ifunc resolvers to call into a supplied malicious object by surreptitiously modifying c files at build time (when ./configure && make is run) and links the compromised object files with a `now` linker flag that causes the ifuncs to be resolved immediately at library load time, which calls the patched resolvers while the process linkage table is still writable, which is the important part that allows them to just hijack the RSA_public_decrypt function in memory when the library is loaded.
There's an excellent technical breakdown of the backdoor *injection process here: https://research.swtch.com/xz-script
rsc · 2024-03-26
It's not as exciting as it sounds. He wanted to play around with learning Paxos, which is a big state machine, and he used yacc to do it. I shared an office with him for a couple years in the early days of Go, and he was working on it while I was working on other things. I helped him track down at least one bug in the Go port of yacc that way. I think the grammar he was writing was completely regular, but yacc is nicer to use than lex.
Ken discussed yacc briefly in Coders at Work, which I quoted at https://research.swtch.com/yyerror:
Seibel: And are there development tools that just make you happy to program?
Thompson: I love yacc. I just love yacc. It just does exactly what you want done. Its complement, lex, is horrible. It does nothing you want done.
Seibel: Do you use it anyway or do you write your lexers by hand?
Thompson: I write my lexers by hand. Much easier.
turndown · 2023-09-04
Others have shown that your degenerate example really does optimize it all away, but I'll just say that we really do exist in a theoretical fairy dust C++ spec environment, because when we compile a piece of code we compile it against the abstract machine. This is one of those insane gotchas of programming languages - unless you're writing assembly yourself you must pass the bar set by the abstract machine and nothing else. I recommend [0], along with every link in the article, and every article on the blog.
0: https://research.swtch.com/ub
hgs3 · 2023-08-23
Agreed. Version resolution is the interesting problem.
Most package managers use a SAT solver to resolve dependencies. The Dart team has a detailed write up on their SAT-based approach which is worth a read [1]. For contrast, Russ Cox presents an algorithm that doesn't use a SAT solver (intended for Go) [2].
[1] https://github.com/dart-lang/pub/blob/master/doc/solver.md
[2] https://research.swtch.com/vgo-mvs
Groxx · 2023-08-12
I'm guessing this is following the same / highly similar motivation as rsc's coroutines post about a month ago: https://research.swtch.com/coro
I welcome people embracing function closures more, as I feel they're a drastically under-used language tool (particularly in Go where everyone crams everything into single-func interfaces which are almost exclusively far worse). More exposure to it helps people become comfortable with it, and now that we have generics it's finally not a pile of pain and agony at all times. And just using functions makes it very flexible / doesn't repeat the "X for me but not for thee" issues of past Go versions.
I'm not entirely sure how I feel about this proposal though. It kinda feels like it's trying to put a round peg into a square hole. If you try hard enough, everything can go in the square hole! But that doesn't mean it's a good fit.
timsneath · 2023-02-11
There are some good examples of why that's not sufficient in Russ' blog post, which is worth reading. They include performance regressions that may not be immediately visible, understanding cache utilization, and better optimizing the toolchain for real-world machine configurations. It's worth reading his article for a better understanding of the goals here:
https://research.swtch.com/telemetry-intro
(Disclosure: I work on developer tools at Google.)
gilgad13 · 2022-11-18
I imagine that opinions such as this have influenced this recommendation: https://research.swtch.com/deps . I think there is some spirit in Go of not taking on a ton of small dependencies, but that may be a hold-over from before Go had a built-in package manager.
I think as an organization grows to some combination of available resources and severity of an outage this view becomes more and more common.
fmajid · 2022-10-20
Read also this excellent article by Russ Cox (of Go fame) on the issue:
https://research.swtch.com/deps
This is at heart an economics problem: how to provide a public good (software security) in the presence of free riders. The way society handles this kind of risk is through insurance, but there are a number of things that need to happen to enable a sustainable economic basis to fund the necessary dependency-vetting to happen.
Edit: I wrote up my thoughts on the way forward here:
https://blog.majid.info/supply-chain-vetting/
kcbanner · 2022-07-22
"This is the story of a clever trick that's been around for at least 35 years, in which array values can be left uninitialized and then read during normal operations, yet the code behaves correctly no matter what garbage is sitting in the array. Like the best programming tricks, this one is the right tool for the job in certain situations. The sleaziness of uninitialized data access is offset by performance improvements: some important operations change from linear to constant time."
https://research.swtch.com/sparse
andrewcl · 2022-06-10
Likely worth a read for those that found this interesting is Russ Cox's article on dependencies, Our Software Dependency Problem, at https://research.swtch.com/deps. This post is a bit more detailed and balanced in my opinion.
teabee89 · 2022-04-09
I recommend reading "What NPM Should Do Today To Stop A New Colors Attack Tomorrow" by Russ Cox (Go's lead): https://research.swtch.com/npm-colors
typical182 · 2022-04-01
That's not correct. You can unilaterally decide to update the version of E without waiting for anyone. Alternatively, if only C for example decides to update their required version of E, you would get that version of E if you updated your version of C (directly or indirectly), without needing to directly do anything with E yourself.
Slightly longer explanation of the mechanics here: https://news.ycombinator.com/item?id=30871730
The best complete explanation is probably here: https://research.swtch.com/vgo-principles
MisterTea · 2022-03-16
Prior art:
http://man.postnix.pw/plan_9/2/thread (Plan 9's thread(2). Personal note: I absolutely LOVE working with this library)
https://swtch.com/libtask/ (Rus Cox's portable library (Someone on the 9fans mailing list ported it to a micro-controller))
See Also:
https://seh.dev/go-legacy/ (A nice code tour of the historical CSP lineage of Go)
https://swtch.com/~rsc/thread/ (Bell Labs and CSP Threads)
chasil · 2021-10-31
Stephen Bourne was a great fan of ALGOL, and had C preprocessor directives to "ALGOLify" C.
https://research.swtch.com/shmacro
The Bourne shell thus adopted ALGOL syntax, distinct from anything else in UNIX.
David Korn brought a pile of C, and wedged it into a max 64k program space (for Xenix), and his upward-compatible Korn shell (ksh88) had many, many features.
Then there were the "UNIX Wars"...
https://en.wikipedia.org/wiki/Unix_wars
The fallout of this was the choice of a few Korn features, but not all (no arrays, coprocesses, [some] eval, regex, et al.)
The wars defined the POSIX shell. Yes, it can be infuriating.
xrd · 2021-06-14
I loved this article and going down the rabbit hole with the associated links was excited to see a discussion from Russ Cox (golang) about how QR codes rely on RS (and another great article)
https://research.swtch.com/qart
jgwil2 · 2021-05-27
Some good programming/mathematical logic content here: https://stopa.io/
Russ Cox of Go: https://research.swtch.com/
Thaxll · 2020-09-10
It's short sighted to think that the Go package managment is "simple", there was a lot of thoughts and considerations that was put into it and improvements over other languages ( even recent one like Rust ).
Good read: https://research.swtch.com/vgo-principles which answers some of your questions.
loeg · 2020-05-24
Here's the best prior art I know of in this space: https://swtch.com/libtask/
I would not recommend taking this approach in C.
blablabla123 · 2020-01-11
In times of security fixes sometimes there is only one secure version but the whole ecosystem is built around the fact that older, flawed version can still be included. Another drawback is performance, npm install is amazingly slow. In fact package resolution is NP-complete: https://research.swtch.com/version-sat
I generally agree but the problem is even worse :)
cube2222 · 2019-08-30
For anybody wondering if vgo is production ready, we've been using it since it came out in go 1.11 and so far didn't have any problems.
Existing workflows don't break because there's the vendor command and dependency management is instantaneous. You can also roll it out gradually as it doesn't have any problems depending on non-module repositories (using commit hashes and dates)
There's a great blog post series too if you're interested in the internals of go modules: https://research.swtch.com/vgo (it's also one of the good counterexamples to people claiming go ignored x years of PL research and history)
dwilding · 2019-01-26
Just what I was thinking!
I find things like this fascinating. Ever since discovering quines, I've thought that it would be neat to use some kind of quine as humanity's radio "calling card" in space. As a puzzle/joke for other beings to enjoy.
Just for fun I've mocked up what such a message could look like [0]. I'm not convinced it totally works... But in any case, I'd thoroughly recommend checking out the inspiration [1] if you haven't seen it already.
[0]: https://firstcontact.space
[1]: https://research.swtch.com/zip
tln · 2018-11-03
This is fantastic.
From this, I learned that making your URLs uppercase makes for a more compact code! The links at the bottom are great reads as well, especially:
https://research.swtch.com/qart
I hope that QR codes become more widely used, now that iOS and Android both include QR capabilities directly in the native camera apps.