Eli Bendersky
eli.thegreenplace.net · Personal blog · on HN since 2007
Eli Bendersky writes technical posts on compilers, parsing, JIT, Go, Python, and low-level systems programming.
What HN saysCommenters repeatedly name it among the best individual developer blogs, praising its breadth and decades of content.
428HN people shared it
220linked it in comments
752stories submitted
15Kstory points
2 months agolast shared
2007people per year2026
Most-shared posts
- 1Computed goto for efficient dispatch tables (2012)27 people · 60 points · first shared 2012 · 26 comments on HN
- 2Why coding interviews aren't all that bad20 people · 6 points · first shared 2012 · 1 comments on HN
- 3The Expression Problem and its solutions (2016)15 people · 199 points · first shared 2016 · 85 comments on HN
- 4Measuring context switching and memory overheads for Linux threads13 people · 56 points · first shared 2018 · 3 comments on HN
- 5Parsing expressions by precedence climbing (2012)12 people · 47 points · first shared 2012 · 1 comments on HN
- 6Co-routines as an alternative to state machines (2009)10 people · 208 points · first shared 2009 · 69 comments on HN
- 7How to JIT – an introduction (2013)10 people · 38 points · first shared 2013 · 1 comments on HN
- 8Top-Down operator precedence parsing10 people · 32 points · first shared 2010 · 9 comments on HN
- 9The context sensitivity of cs grammar10 people · first shared 2011
- 10A polyglot's guide to multiple dispatch9 people · 265 points · first shared 2016 · 63 comments on HN
- 11Adding a new statement to Python9 people · 154 points · first shared 2010 · 14 comments on HN
- 12How debuggers work: Part 19 people · 73 points · first shared 2011 · 28 comments on HN
- 13Understanding lvalues and rvalues in C and C++8 people · 110 points · first shared 2011 · 29 comments on HN
- 14Load-time relocation of shared libraries (2011)7 people · 31 points · first shared 2011 · 1 comments on HN
- 15Benefits of dependencies in software projects as a function of effort (2017)7 people · 23 points · first shared 2017 · 4 comments on HN
What HN people wrote when they linked it
jonstewart · 2025-12-23
Not corporate, but two of the best individual developer blogs are Eli Bendersky's and Rachel by the Bay. They've both been blogging prolifically for a decade+, Eli with a focus on, broadly, compilers and Rachel on SRE/debugging.
Raymond Chen's The Old New Thing is also required reading for anyone that works with Windows.
https://eli.thegreenplace.net/
https://rachelbythebay.com/w/
https://devblogs.microsoft.com/oldnewthing/
jjice · 2024-01-31
I like Eli Bendersky's blog a lot. He talks about a variety of topics and he satisfies my occasional Go interest since I don't work in it regularly: https://eli.thegreenplace.net/
Mr Money Mustache has been my favorite blog for probably about eight or nine years now. Some people have negative opinions about the financial independence space or they say he's too hardcore for them, but I love a lot of his posts and they've led me to make happier decisions in my life. He's always got a different way of looking at things and sometimes I acknowledge that those aren't for me, and sometimes I adopt them. https://www.mrmoneymustache.com
idbfs · 2023-06-22
Worth noting that the release announcement was written by Eli Bendersky, of https://eli.thegreenplace.net/ fame. It's a fantastic technical blog with literally decades of content.
lurrr · 2020-09-21
Plenty of good ones already, I'll just leave my favorite.
https://eli.thegreenplace.net/
shaklee3 · 2020-02-08
For low-level software, these are great:
https://eli.thegreenplace.net/
https://travisdowns.github.io/
https://preshing.com/
zzril · 2026-07-24
For linux, there's this excellent series of articles by Eli Bendersky:
https://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1
https://eli.thegreenplace.net/2011/01/27/how-debuggers-work-part-2-bre…
https://eli.thegreenplace.net/2011/02/07/how-debuggers-work-part-3-deb…
(Unfortunately, the articles don't include links to their respective follow-ups, but I'm pretty sure it ends after part 3...)
commandersaki · 2026-03-26
My favourite trick is either commenting out a whole command or placing a comment at the end of a command to make it easier to find in my persistent history (thanks eliben) [0], using the # character.
I tried this in zsh and it wasn't the default behaviour which immediately made me nope from the shell altogether, among all the other quirks. I've just been using bash for far too long to switch to something different.
[0] https://eli.thegreenplace.net/2013/06/11/keeping-persistent-history-in…
naasking · 2025-09-08
Read the Haskell-specific follow-up which I mentioned, type classes have a correspondance with traits so the problems with this approach are the same:
https://eli.thegreenplace.net/2018/more-thoughts-on-the-expression-pro…
thasso · 2025-06-11
If you are interested in debuggers, there was a post series by Sy Brand a few years back:
https://blog.tartanllama.xyz/writing-a-linux-debugger-setup/
Eli Bendersky also wrote about debuggers (I think his post is a great place to start):
https://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1
I was fascinated with debuggers a while back exactly because they were so mysterious to me. I then wrote a ptrace debugger myself [1]. It features pretty simple implementations of the most common stuff you would expect in a debugger. Though I made the grave mistake of formatting all the code in GNU style.
[1]: https://github.com/thass0/spray/tree/main/src
D4ckard · 2025-04-25
This is a great series of posts which have inspired me to write a debugger when they were posted here before. Very fun! This is another insightful series of the topic: https://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1
kurinikku · 2024-11-17
OP here. Thank you for the kind words! For those who enjoyed this, I would also point out Eli Bendersky's excellent SICP series https://eli.thegreenplace.net/tag/sicp
eliben · 2024-09-29
Yes, all the time! The built-in net/http has great TLS support
https://eli.thegreenplace.net/2021/go-https-servers-with-tls/
smt88 · 2024-07-08
Rust has memory-safe handling of circular references, but it can also be done with "unsafe" blocks.
It's (much) more involved than using C++, but that's a worthwhile tradeoff for something as important as a browser engine.
More info: https://eli.thegreenplace.net/2021/rust-data-structures-with-circular-…
cstrahan · 2024-03-11
YAML is kind of like C++:
> You like C++ because you're only using 20% of it. And that's fine, everyone only uses 20% of C++, the problem is that everyone uses a different 20% :)
https://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back
The YAML footguns are too numerous to reproduce here, so here are some sources:
https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-in…
https://www.arp242.net/yaml-config.html
https://noyaml.com/
YAML isn't terrible if you only ever have to read what you wrote. Now consider that there are 63 different ways to write multi-line strings in YAML -- how many of those have you committed to memory? Yeah... now throw 10-100 developers into the mix, each with their own favorite alternative syntaxes -- good luck making sense of your YAML.
devta · 2023-12-26
trealira · 2023-11-09
> Hand-written parsers are even worse. Using an LR parser generator is worth the time investment.
I'm curious, what makes you say this? From what I've read online secondhand, people tend to recommend handwritten recursive descent parsing and Pratt/TDOP parsing, because it's easier to add good error messages and later add context sensitive productions (e.g. the way Clang resolves class-wide declarations while parsing C++: https://eli.thegreenplace.net/2012/07/05/how-clang-handles-the-type-va…
ripley12 · 2023-09-08
Yes, I think you're generally right. I'm a big fan of this blog post: https://eli.thegreenplace.net/2018/measuring-context-switching-and-mem…
> The numbers reported here paint an interesting picture on the state of Linux multi-threaded performance in 2018. I would say that the limits still exist - running a million threads is probably not going to make sense; however, the limits have definitely shifted since the past, and a lot of folklore from the early 2000s doesn't apply today. On a beefy multi-core machine with lots of RAM we can easily run 10,000 threads in a single process today, in production. As I've mentioned above, it's highly recommended to watch Google's talk on fibers; through careful tuning of the kernel (and setting smaller default stacks) Google is able to run an order of magnitude more threads in parallel.
rollcat · 2023-07-27
This is one of the most random, slightly off-topic, and absolutely amazing stories I've ever read in my life. So much of it rings familiar, down to (almost) failing the exam on trivia questions :)
BTW have a look at this blog post: <https://eli.thegreenplace.net/2023/faas-in-go-with-wasm-wasi-and-rust/… It uses a lot of off-the-shelf components like a WASM runtime instead of a custom 8080 emulator, and net/http rather than rolling your own HTTP server - but it's fascinating, how close your crazy project ended up from actually viable real-world use cases.
sneed_chucker · 2023-05-31
For tech stuff, it's gotta be Eli Bendersky's blog. He's been at it a long time and has some extremely high quality entries.
https://eli.thegreenplace.net/
geospeck · 2023-05-25
Thanks for the post!
Another great blog post series about implementig Raft in Go that I found is this one https://eli.thegreenplace.net/2020/implementing-raft-part-0-introducti…
henrik_w · 2023-05-10
Great blog! In addition to the technical posts, I also enjoy Eli's quarterly summaries of what he's been reading (which is a lot). The latest one is this:
https://eli.thegreenplace.net/2023/summary-of-reading-january-march-20…
mrtracy · 2023-02-22
Co-routines can be a great structured-programming tool for implementing state machines. A good article which explains this idea explicitly: https://eli.thegreenplace.net/2009/08/29/co-routines-as-an-alternative…
That said, overhead always needs to be considered; the overhead cost of using a CPP co-routine would be considerable for implementing a state machine that transitions rapidly.
eestrada · 2023-02-22
Because native multithreading is expensive when it comes to (a) memory consumption per thread of execution and (b) context switching. Also, if your program spends a lot of time just waiting on outside resources (most notably slow/blocking IO), coroutine concurrency is bother faster and more lightweight. If your program is CPU bound, then coroutines/async have little-to-no value over native multithreading.
That being said, yeah, most async workflows are obtuse and difficult to follow and they force all consumers of your interface to also use the async primitives if they want the benefits. Go seems to be one of the few languages that does async/coroutines right.
See: https://eli.thegreenplace.net/2018/go-hits-the-concurrency-nail-right-…
f311a · 2023-01-29
If you want to go really deep, I would recommend reading some blogs about Python internals:
https://tenthousandmeters.com/tag/cpython/
https://rushter.com/blog/tags/cpython/
https://eli.thegreenplace.net/tag/python-internals
https://realpython.com/cpython-source-code-guide/
I'm not aware of any good books about Python's internals.
woodruffw · 2022-06-12
`ptrace(2)` and `userfaultfd(2)` show up when doing program tracing/analysis, among other places. I don't know of a great resource for the latter, but Eli Bendersky has a terrific series on debuggers that covers `ptrace(2)`[1].
[1]: https://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1
Pr0ject217 · 2022-02-07
EDIT:
Paste this hacky snippet into your browser's console to save all of the links into your clipboard:
(() =>
{
let result = [...document.querySelectorAll('td a')]
.map((link) =>
link &&
!link.href.includes('ycombinator') &&
!link.href.includes('javascript:void')
? link.href
: ''
)
.filter(Boolean);
result = [...new Set(result)];
result.sort();
copy(result.join('\n\n'));
})();
Just to help, here's a compiled-list of all of the links shared here so…
mfrw · 2022-02-07
I find content written by Eli Bendersky pretty informative: https://eli.thegreenplace.net/
eatonphil · 2021-12-15
Eli Bendersky has another great, even simpler introduction (from 2013) to JIT compiling but with hardcoded instructions [0]. And a more recent post on JIT compiling Brainfuck [1].
[0] https://eli.thegreenplace.net/2013/11/05/how-to-jit-an-introduction
[1] https://eli.thegreenplace.net/2017/adventures-in-jit-compilation-part-…
sateesh · 2021-11-28
That is the beauty of this book, there is no need for any extra resources. Install SICP package in Dr. Racket [1] and start reading the book. Try your best to solve the exercises, and don't give up easily on the exercises. Thinking over the exercises and solving them is the best way to assimilate learning from SICP. I read only the first 3 chapters, and relied on notes from Eli Bendersky [2] to check when stuck with exercises.
1. https://stackoverflow.com/questions/19546115/which-lang-packet-is-prop…
2. https://eli.thegreenplace.net/2007/06/19/introducing-the-sicp-reading-…
spijdar · 2021-09-03
Caveat: I've barely used Go personally.
Just speculating on what GP specifically meant, but Go lacks the ability to pack structs, and probably lacks the equivalent of tricks like computed gotos [0] to increase bytecode interpreter speeds. In general, Go seems to (intentionally) lack a lot of low-level control of code generation, preferring a "there's one way to do things, and it either works, or it's a bug we'll fix" approach.
Which is probably for the best in "most" software, but interpreters typically use weird hacks to squeeze more performance out of the rock. Wren is a good example [1] of some of these optimizations, and has splendid comments/documentation.
[0] https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-d…
[1] https://github.com/wren-lang/wren/blob/main/src/vm/wren_vm.c