Top all-time · #3512
JT Olio
Personal blog · jtolio.com · on HN as jtoldsprogrammingsystems
JT Olio's personal blog at jtolio.com covers programming and systems. Since 2018, 22 different Hacker News readers have linked it 28 times, most often “Problems with Go channels (2016)”. It is still writing: the last post was on 2026-01-27, and you can follow it by feed.
Too few sampled comments (17) to say how often HN recommends it.?
Why HN links it
Jtolio's posts are cited in Go and concurrency debates, mainly his 2016 argument that Go channels are an anti-pattern, plus a post on pure lambda calculus whiteboard problems.
Summarised by Claude from a sample of 17 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Most-linked posts?
- Problems with Go channels (2016)12 people · 15 mentions · first linked 2018-05-07
- Whiteboard problems in pure Lambda Calculus (2017)3 people · 3 mentions · first linked 2018-07-23
- Just update rules between neurons2 people · 2 mentions · first linked 2023-03-26
- A "Pure Go" Linux Environment, Ported by Claude, Inspired by Fabrice Bellard2 people · 2 mentions · first linked 2026-01-28
What Hacker News says?
> There is nothing wrong with hiding the nature of the async under the hood of a sync function as long as the abstraction is clean, which in most cases it quite easily can be. This is the question and I would disagree. Hiding the asynchronous nature of any given function is a dangerous illusion. Languages that promote it through stackful coroutines ultimately lead to programs that are difficult to reason about and o…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “The Various Kinds of IO – Blocking, Non-Blocking, Multiplexed and Async”Submitted Problems with Go channels (2016) as a story · 160 points
HN discussionThis reminds me of a blog post about using pure lambda calculus for whiteboard problems [1]. I'm always fascinated by these "minimum viable language projects", since I think they sort of get into a fundamental concept: what is computing exactly? [1] https://www.jtolio.com/2017/03/whiteboard-problems-in-pure-l...
Comment linking /2017/03/whiteboard-problems-in-pure-lambda-calculus/
on “JSFuck (2012)”Submitted Python 3, Pygame, and Debian Bookworm on the Miyoo A30 as a story · 158 points
HN discussionChannels are also hardly foolproof. You need to internalize the (non-obvious) channel axioms[1], and there are many other pitfalls and annoyances like: - Needing to determine ownership of closable objects passed across channels. - Defining what special token (or OOB signaling mechanism) is used for marking end of data. - Synchronizing who is closing the channel Go channels are quite painful to use and often a simple…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “Half a million lines of Go”Submitted Whiteboard problems in pure Lambda Calculus (2017) as a story · 87 points
HN discussionChannels are not always the best solution (unless you're referring to Rust channels?) https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s...
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “Taming Go’s memory usage, or how we avoided rewriting our client in Rust”Submitted A "Pure Go" Linux Environment, Written by Claude, Directed by Fabrice Bellard as a story · 3 points
HN discussionsorry for the delay i don't know that much about concurrency in general, so take this with a grain of salt i feel like monitors are potentially an improvement over bare locks, but they tend to perform poorly in manycore settings and are still vulnerable to deadlock, perhaps more so due to their implicit nature. (i see that you point this out with respect to java, and also that it doesn't really have monitors.) funda…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “Niklaus Wirth, or the Importance of Being Simple”Submitted Writing advanced web applications with Go as a story · 3 points
HN discussionYou can easily cause a C/Go program to crash/abort due to runtime type errors. If you've written C, you've miscast something at some point. Go in particular relies extremely heavily on runtime reflection. Both languages have poor type systems. Go's race detector is useful and we've caught bugs using it, but it's nicer when the compiler prevents you from having those bugs in the first place. >quite good concurrency p…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “Bayard: a full-text search and indexing server written in Rust”Submitted A "Pure Go" Linux Environment, Ported by Claude, Inspired by Fabrice Bellard as a story · 2 points
HN discussionhttps://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... I'd add that these aren't just theoretical (EDIT: I forgot that his article linked to this paper). https://songlh.github.io/paper/go-study.pdf Go doesn't actually implement CSP correctly. That would require some changes. This provides a high-level overview. https://stackoverflow.com/questions/32651557/golang-main-dif... Threading is hard and gets a lot…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “A Tour of Standard ML”Submitted I finally figured out Twitter (2009) as a story · 2 points
HN discussionI think different people read "Go concurrency model" to mean different things. If we're talking about green threads (goroutines), I'm a huge fan. Having had a lot of success using Gevent in the Python world, it was great coming over to the Go world where that pattern was baked into the language. If we're talking about channels, I'm really not a fan. Not nearly as easy to use as the equivalent Queue library over in P…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “Updating the Go Memory Model”Submitted Go channels are bad and you should feel bad (2016) as a story · 2 points
HN discussionNot sure if it's the case nowadays, but Go channels were historically around 4x slower than the equivalent mutex-based code. This is a Big Deal™ if you're writing performance sensitive code or in a hot loop. https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... https://www.datadoghq.com/blog/go-performance-tales/
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “Updating the Go Memory Model”Submitted A "Pure Go" Linux Environment, Ported by Claude as a story · 1 points
HN discussionThis share by communicating mantra needs to die. Channel based code in go has a tendency to require nontrivial cleanup. Each time you need to compose a channel you you end up introducing another goroutine (for example just to map a type or merge multiple channels). Now that goroutine needs to be closed, then you end up with an additional close channel, and sometimes you need to drain channels to prevent locks. They…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “Go Things I Love: Channels and Goroutines”Submitted Just update rules between neurons as a story · 1 points
HN discussionThe terminology could use some refinement. Not sure "message passing" is the right phrase to describe Go channels. Most encounters I've had with "message passing"--whether it was AJAX, Win32 PostMessage, or grade school--have been non-blocking. Go channels block. edit: Here's a pretty good write-up from 2016 on why channels are an anti-pattern: https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s...
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “Understanding Real-World Concurrency Bugs in Go [pdf]”Submitted Just update rules between neurons as a story · 1 points
HN discussionThis is all very nice as an idea or a mythical background story ("Go was designed entirely around CSP"), but Go is not a language that encourages "sharing by communicating". Yes, Go has channels, but many other languages also have channels, and they are less error prone than Go[1]. For many concurrent use cases (e.g. caching), sharing memory is far simpler and less error-prone than using channels. If you're looking…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “A million ways to die from a data race in Go”Communicating through channels is completely orthogonal to the type of coroutines (stackless or stackful). I would argue that Kotlin does channels strictly better than Go, since Kotlin channels do not have any of the problem of Go channels[1]: 1. No blocking forever on nil channels (WTF?) 2. Close is idempotent: No panic when closing a channel twice. Now you don't require 1 or 2 extra channels to measure proper clos…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad
on “Even in Go, concurrency is still not easy”Not true: https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... I'm pretty sure the implementation has seen some improvements since then. But using a channel for async await is the same as using a global mutex every time you await. That is bound to be contentious on high load.
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “Even in Go, concurrency is still not easy”You could take a look at what this guy[1] did. It was a great read for me as a real beginner in lambda calculus. [1]: https://www.jtolio.com/2017/03/whiteboard-problems-in-pure-l...
Comment linking /2017/03/whiteboard-problems-in-pure-lambda-calculus/
on “An integer formula for Fibonacci numbers (2015)”I'm pretty sure the designers of Rust knows about CSP. Rust has Channels in the standard library after all: https://doc.rust-lang.org/rust-by-example/std_misc/channels.... Rust Channel have the nice additional that they don't panic, and don't have all the weird Go Channel Axioms[1] that you have to wrap your head around to get things to work correctly[2]. For what it's worth, I don't think Java Virtual Threads (a.k.…
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “The Rust I wanted had no future”If this is too much research for you, wait until you have to deal with the many problems of Go channels in the real world. (Reasonably well-known though controversial article: [1]) Don't even get me started on Rust. Concurrency and parallelism is hard. Yes, I've written a shit ton of code in all aforementioned languages. [1] https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s...
Comment linking /2016/03/go-channels-are-bad-and-you-should-feel-bad/
on “The easy way to concurrency and parallelism with Python stdlib”
