Problems with Go channels (2016)
jtolio.com
jtolio.com
The lure to use channels is too strong for new users.
The nil and various strange shapes of channel methods aren't really a problem they're just hard for newbs.
Channels in Go should really only be used for signalling, and only if you intend to use a select. They can also act as reducers, fan out in certain cases. Very often in those cases you have a very specific buffer size, and you're still only using them to avoid adding extra goroutines and reverting to pure signalling.
I have a little pain when I do a cli as the work appears during the run and it’s tricky to guarantee you exit when all the work is done and not before. Usually Ihave a sleep one second, wait for wait group, sleep one more second at the end of the CLI main. If my work doesn’t take minutes or hours to run, I generally don’t use Go.
https://github.com/twpayne/go-pubsub/blob/master/pubsub.go#L...
Ugh... I hope I never have to work with channels again.
The inner channel is a poor man's future. Came up with this to have lua runtimes be able to process in parallel while maintaining ordering (A B C in, results of A B C out)
We're a video game studio as well using C#, and while game programmer != backend programmer, I can at least delegate small fixes and enhancements out to the team more easily.
For your own application code, you don't have to use exceptions you can write custom Result objects and force callers to pattern match on the types (and you can always wrap library/std exceptions in that result type).
Structured Concurrency looks like a banger of a feature - it's what CompletableFuture should've been.
VirtualThreads still needs a few more years for most production cases imo, but once it's there, I truly don't see a point to choose Go over Java for backend web services.
Plus these days Java GC has addressed most of the problems that plagued Java on backend for years. The memory usage is still higher than with Go simply because more dynamic allocations happens due to the nature of the language, but GC pauses are no longer a significant problem. And if they do, switching to Go would not help. One needs non-GC language then.
fwiw - My favorite language is Rust, but Async Rust has ruined it for me.
I do love Rust a lot as well but most of the time I am finding myself using either Elixir or Golang.
Application languages are generally managed/GC'd languages with JITs or AOT compilation for doing higher-performance apps. Examples would be Java, Go, Ocaml, Haskell, etc.
System languages are generally concerned with portability, manual memory layout, and direct hardware access as opposed to managed APIs. Examples would be C/C++, Rust, Zig, Pascal, etc.
Scripts are programs that carry out a specific task and then exit. If failure occurs, it is usually on the operator to fix the issue and run the script again. I agree that bash, AppleScript, Python, etc. are geared towards these types of programs.
Applications are programs with interfaces (not necessary graphical, but can be) that are used interactively. If failure occurs, the software usually works with the user to address the problem. It's not completely unheard of to use Go here, but I wouldn't call that its strength.
Systems are "forever"-running programs to provide foundational services other programs. If failure occurs, the software usually does its best to recover automatically. This is what Go was designed for – specifically in the area of server development. There are systems, like kernels, that Go wouldn't be well suited for, but the server niche was always explicit.
Your pet definitions are fine too – it is a perfectly valid take – but know that's not what anyone else is talking about.
OCaml needs more coherence and unity. It offers too much choice.
If you want strong control and very unforgiving type system with even more unforgiving memory lifetime management so you know your program can get even faster than corresponding C/C++ programs, then Rust is a no-brainer.
But I did not pick it for the speed, though that's a very welcome bonus. I picked it for the strong static typing system mostly. And I like having the choice to super-optimize my program in terms of memory and speed when I need to.
Modelling your data transformations with enums (sum types) and Result/Option was eye-opening and improved my programming skills in all other languages I am using.
> you know your program can get even faster than corresponding C/C++ programs
Whether that's true or not, I make no claims. Not a compiler developer.
And yeah I'd be quite content with 1-2% margin compared to C as well.
Another thing about that library, like so many "Rust wins" that we are seeing: There is loads of unsafe code.
Haskell also has software transactional memory where one can implement one's own channels (they are implemented [1]) and atomically synchronize between arbitrarily complex reading/sending patterns.
[1] https://hackage.haskell.org/package/stm-2.5.3.1/docs/Control...
In my not so humble opinion, Go is a library in Haskell from the very beginning.
If you take enough steps back and really think about it, the only synchronization primitive that exists is a futex (and maybe atomics). Everything else is an abstraction of some kind. If you're really determined, you can build anything out of anything. That doesn't mean it's always a good idea.
Looking back, I'd say channels are far superior to condition variables as a synchronized cross-thread communication mechanism - when I use them these days, it's mostly for that. Locks (mutexes) are really performant and easy to understand and generally better for mutual exclusion. (It's in the name!)
As you think back even to the very early days of computing, you'll find individuals or small teams like Grace Hopper, the Unix gang, PARC, etc that managed to change history by "building something useless". Granted, throughout history that happened less than 1% of the time, but it will never happen if you never try.
Maybe Google no longer has any space for innovation.
Friendly fyi... GMail was not a "20% project" which I mentioned previously: https://news.ycombinator.com/item?id=39052748
Somebody (not me but maybe a Google employee) also revised the Wikipedia article a few hours after my comment: https://en.wikipedia.org/w/index.php?title=Side_project_time...
Before LLMs and ChatGPT even existed ... a lot of us somehow hallucinated the idea that GMail came from Google's 20% Rule. E.g. from 2013-08-16 : https://news.ycombinator.com/item?id=6223466
I had success in using a CSP style, with channels in many function signatures in a ~25k line codebase.
It had ~15 major types of process, probably about 30 fixed instances overall in a fixed graph, plus a dynamic sub-graph of around 5 processes per 'requested action'. So those sub-graph elements were the only parts which had to deal with tear-down, and clean up.
There were then additionally some minor types of 'process' (i.e. goroutines) within many of those major types, but they were easier to reason about as they only communicated with that major element.
Multiple requested actions could be present, so there could be multiple sets of those 5 process groups connected, but they had a maximum lifetime of a few minutes.
I only ended up using explicit mutexes in two of the major types of process. Where they happened to make most sense, and hence reduced system complexity. There were about 45 instances of the 'go' keyword.
(Updated numbers, as I'd initially misremembered/miscounted the number of major processes)
To debug stuff by reading the code, each message ends up having 30 potential destinations.
If a request involves N sequential calls, the control flow can be as bad as 30^N paths. Reading the bodies of the methods that are invoked generally doesn’t tell you which of those paths are wired up.
In some real world code I have seen, a complicated thing wires up the control flow, so recovering the graph from the source code is equivalent to the halting problem.
None of these problems apply to async/await because the compiler can statically figure out what’s being invoked, and IDE’s are generally as good at figuring that out as the compiler.
The problem space itself could have probably grown to twice the number of lines of code, but there wouldn't have needed to be any more developers. Possibly only the original two. The others were only added for meeting deadlines.
As to the graph, it was fixed, but not a full mesh. A set of pipelines, with no power of N issue, as the collection of places things could talk to was fixed.
A simple diagram represented the major message flow between those 30 nodes.
Testing of each node was able to be performed in isolation, so UT of each node covered most of the behaviour. The bugs were three deadlocks, one between two major nodes, one with one major node.
The logging around the trigger for the deadlock allowed the cause to be determined and fixed. The bugs arose due to time constraints having prevented an analysis of the message flows to detect the loops/locks.
So for most messages, there were a limited number of destinations, mostly two, for some 5.
For a given "request", the flow of messages to the end of the fixed graph would be passing through 3 major nodes. That then spawned the creation of the dynamic graph, with it having two major flows. One a control flow through another 3, the other a data flow through a different 3.
Within that dynamic graph there was a richer flow of messages, but the external flow from it simply had the two major paths.
Yes, reading the bodies of the methods does not inform as to the flows. One either had to read the "main" routine which built the graph, or better refer to the graph diagram and message flows in the design document.
Essentially a similar problem to dealing with "microservices", or plugable call-backs, where the structure can not easily be determined from the code alone. This is where design documentation is necessary.
However I found it easier to comprehend and work with / debug due to each node being a prodable "black box", plus having the graph of connections and message flows.
[1] Of those, only the first had any exerience with CSP or Go. The CSP expereince being with a library for C, the Go experience some minimal use a year earlier. The other developers were all new to CSP and Go. The first two developers were "senior" / "experienced".
I would tentatively make the claim that channels (in the abstract) are at heart an interface rather than a type of synchronisation per se. They can be implemented using Mutexes, pure atomics (if each message is a single integer) or any number of different ways.
Of course, any specific implementation of a channel will have trade-offs. Some more so than others.
You could address the concern by choosing a CPU architecture that included infinite capacity FIFOS that connected its cores into arbitrary runtime directed graphs.
Of course, that architecture doesn’t exist. If it did, dispatching an instruction would have infinite tail latency and unbounded power consumption.
That sounds reasonable. From what little Erlang/Elixir code I’ve seen, the sending and receiving of messages is also hidden as an implementation detail in modules. The public interface did not expose concurrency or synchronization to callers. You might use them under the hood to implement your functionality, but it’s of no concern to callers, and you’re free to change the implementation without impacting callers.
You're going to be surprised when you learn that futexes are an abstraction too, ultimately relying on this thing called "cache coherence".
And you'll be really surprised when you learn how cache coherence is implemented.
Go's design consistently at every turn chose the simplest (one might say "dumbest", but I don't mean it entirely derogatory) way to do something. It was the simplest most obvious choice made by a very competent engineer. But it was entirely made in isolation, not by a language design expert.
Go designs did not actually go out and research language design. It just went with the gut feel of the designers.
But that's just it, those rules are there for a reason. It's like the rules of airplane design: Every single rule was written in blood. You toss those rules out (or don't even research them) at your own, and your user's, peril.
Go's design reminds me of Brexit, and the famous "The people of this country have had enough of experts". And like with Brexit, it's easy to give a lame catch phrase, which seems convincing and makes people go "well what's the problem with that, keeping it simple?".
Explaining just what the problem is with this "design by catchphrase" is illustrated by the article. It needs ~100 paragraphs (a quick error prone scan was 86 plus sample code) to explain just why these choices leads to a darkened room with rakes sprinkled all over it.
And this article is just about Go channels!
Go could get a 100 articles like this written about it, covering various aspects of its design. They all have the same root cause: Go's designers had enough of experts, and it takes longer to explain why something leads to bad outcomes, than to just show the catchphrase level "look at the happy path. Look at it!".
I dislike Java more than I dislike Go. But at least Java was designed, and doesn't have this particular meta-problem. When Go was made we knew better than to design languages this way.
But they were working in a bit of a vacuum. Not only were they mostly addressing the internal needs of Google, which is a write-only shop as far as the rest of the software industry is concerned, they also didn't have broad experience across many languages, and instead had deep experience with a few languages.
In it, he seems to believe that the primary use of types in programming languages is to build hierarchies. He seems totally unfamiliar with ideas behind ML or haskell.
Go was the third language he played a major part in creating (predecessors are Newsqueak and Limbo), and his pedigree before Google includes extensive experience on Unix at Bell Labs. He didn't create C but he worked directly with the people who did and he likely knows it in and out. So I stand by my "deep, not broad" observation.
Ken Thompson requires no introduction, though I don't think he was involved much beyond Go's internal development. Robert Griesemer is a little more obscure, but Go wasn't his first language either.
> Did the C++ committee really believe that was wrong with C++ was that it didn't have enough features?
C++ was basically saved by C++11. When written in 2012 it may have been seen as a reasonable though contrarian reaction, but history does not agree. It's just wrong.
I'm very much NOT saying that every decision Go made was wrong. And often experts don't predict the future very well. But I do think that this gives further proof that while not a bad coder by any means, no Pike is very much not an expert in PL. Implementing ideas you had from the 1980s adding things you've learned since is not the same thing as learning lessons from the industry in that subfield.
I don't think the word encompasses "have done it several times before, but has not actually even looked at the state of the art".
If you're a good enough engineer, you can build anything you want. That doesn't make you an expert.
I have built many websites. I'm not a web site building expert. Not even remotely.
I also think it's only from the perspective of a select few, plus some purists, that the authors of Go can be considered anything other than experts. That they made some mistakes, including some borne of hubris, doesn't really diminish their expertise to me.
If Go had been designed in the 1980s then it would have been genius. But now we know better. Expertise is more than knowing state of the art as of 30 years prior.
For one thing, Go took a number of forward-thinking stances (or ones which were, at least, somewhat unusual for its time and target audience), like UTF-8 strings (granted, Thompson and Pike created the encoding in the first place), fat pointers for strings and slices, green threads with CSP (though channels proved to be less useful than envisioned) and no function coloring, first-class functions, a batteries-included standard library, etc.
The only things I can think of which Go did that seemed blatantly wrong in that era would be the lack of generics and proper enums. Null safety, which IMO proved to be the killer development of that era, was not clearly formed in industry yet. Tony Hoare hadn't even given his famous "billion-dollar mistake" talk yet, though I'm sure some idea of the problem already existed (and he did give it in 2009, a couple of years into Go's development but also before its first public release). I know others find the type system lacking, but I don't think diving hard into types is obviously the best way to go for every language.
If one were to seriously investigate whether expertise was valued by Pike et al., I think it would start by looking at Erlang/OTP. In my opinion, that ecosystem offers the strongest competition against Go on Go's own strengths, and it predates Go by many years. Were the Go designers aware of it at all? Did they evaluate its approach, and if so, did they decide against it for considered reasons? Arguing against C++ was easy coming from their desired goals, but what about a stronger opponent?
Typescript added "improper" enums several years later. Which is especially interesting as it is the one feature in Typescript that doesn't map directly to Javascript. I'm not sure even that one was the settled science back then.
Generics were well established at that time, but that one didn't escape the Go authors. From day one it was explicitly called out as a feature Go should have, but that they hadn't figured out how to integrate it. https://youtu.be/rKnDgT73v8s?t=3257 Despite Taylor's admirably insistent efforts to find a solution (with 8+ proposals to his name, dating back to before Go was released to the public!), it ultimately required convincing an outside expert to lend a hand.
> I know others find the type system lacking
It may be lacking by today's standards where types are all the rage, but at the time we should also remember that it was the case that types simply weren't cool. People had grown tired of "doing XML sit-ups" and had fully embraced dynamic languages in reaction to that. Go was built in that time, for that time, explicitly intending to be a language that felt like a dynamic language but with the performance advantages of a static language. https://youtu.be/rKnDgT73v8s?t=471
Except that it did. Just because people aren’t rewriting borg and spanner in go doesn’t mean it isnt default choice for many of infra projects. And python got completely superseded by go even during my tenure
If Java is not a failure then neither is Go.
If Go is a failure then so is Java.
Personally I think it is inaccurate to judge a mainstream, popular and widely adopted language as a failure just because it did not meet the goal set at the initiation of the project, prior to even the first line of code getting written.
Hopefully saving this comment will work.
Go, unlike Brexit, has pivoted to become the solution to something other than its stated target. So sure, Go is not a failure. It was intended to be a systems language to replace C++, but has instead pivoted to be a "cloud language", or a replacement for Python. I would say that it's been a failure as a systems language. Especially if one tries to create something portable.
I do think that its simplicity is the rejection of the idea that there are experts out there, and/or their relevance. It's not decisions based on knowledge and rejection, but of ignorance and "scoping out" of hard problems.
Another long article could be written about the clearly not thought through use of nil pointers, especially typed vs untyped nil pointers (if that's even the term) once nil pointers (poorly) interact with interfaces.
But no, I'm not comparing the outcome of Go with Brexit. Go pivoting away from its stated goals are not the same thing as Brexiteers claiming a win from being treated better than the EU in the recent tariffs. But I do stand by my point that the decision process seems similarly expert hostile.
Go is clearly a success. It's just such a depressingly sad lost opportunity, too.
Ok, I'll ask the obvious question. Who are these experts and what languages have they designed?
> Another long article could be written about the clearly not thought through use of nil pointers, especially typed vs untyped nil pointers (if that's even the term) once nil pointers (poorly) interact with interfaces.
You're getting worked up about something that's hardly ever an issue in practice. I suspect that most of your criticisms are similar.
The first is simple confusion, such as trying to handle "all nils" the same way. This is not necessary, though I have seen some developers coming from other languages get hung up on it. In my experience, the only real use for "typed nil" is reflection, and if you're using reflection, you should already know the language in and out.
However, the other aspect is that methods with pointer receivers on concrete types can have default behavior when the receiver is nil, while interfaces cannot. In the expression foo.Bar(), you can avoid a panic if foo is *T, but when foo is an interface, there is no way around the panic without checking foo's value explicitly first. Since nil is the default value of all interface types, even if you create a dummy/no-op implementation of the interface, you still risk nil panics. You can mitigate but never truly remove this risk.
More specifically, it was intended to replace the systems that Google wrote in C++ (read: servers). Early on, the Go team expressed happy surprise that people found utility in the language outside of that niche.
> but has instead pivoted to be a "cloud language"
I'm not sure that is really a pivot. At the heart of all the "cloud" tools it is known for is a HTTP server which serves as the basis of the control protocol, among other things. Presumably Go was chosen exactly because of it being designed for building servers. Maybe someone thought there would be more CRUD servers written in it too, but these "cloud" tools are ultimately in the same vein, not an entirely different direction.
> or a replacement for Python
I don't think you'd normally choose Go to train your ML/AI model. It has really only gunned for Python in the server realm; the very thing it was intended to be for. What was surprising to those living in an insular bubble at Google was that the rest of the world wrote their servers in Python and Ruby rather than C++ like Google – so it being picked up by the Python and Ruby crowd was unexpected to them – but not to anyone else.
I don't think anyone ever claimed Golang will displace Python in the ML area. But in a world where Golang and Elixir exist (two languages with stacks that make starting a new web / API projects extremely easy, almost trivial), not to mention old-timers like Ruby, the amount of people reaching for Python for web / API projects is depressingly high. "Sunk cost fallacy", "one-trick pony", "Stockholm syndrome" and a few others come to mind when thinking about the programmers doing it.
Or how append() sometimes returns a new slice and sometimes it doesn't (so if you forget to assign the result, sometimes it works and sometimes it doesn't). Which is understandable if you think about it in terms of low-level primitives, but in Go this somehow became the standard way of managing a high-level list of items.
Or that whole iota thing.
What is the whole iota thing?
For what it is, the iota design is really good. Languages like C and Typescript having having the exact same feature hidden in some weird special syntax look silly in comparison, not to mention that the weird syntax obscures what is happening. What Go has is much more clear to read and understand (which is why it gets so much grief where other languages with the same feature don't – there is no misunderstandings about what it is).
But maybe you are implying that no language should present raw enums, rather they should be hidden behind sum types? That is not an unreasonable take, but that is not a design flaw. That is a different direction. If this is what you are thinking, it doesn't fit alongside the other two which could be more intuitive without completely changing what they are.
I actually think Java is the better PL, but the worse runtime (in what world are 10s GC pauses ever acceptable). Java has an amazing standard library as well - Golang doesn't even have many basic data structures implemented. And the ones it does, like heap, are absolutely awful to use.
I really just view Golang nowadays as a nicer C with garbage collection, useful for building self contained portable binaries.
Java is a child of the 90s. My full rant at https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim... :-)
This seems like a very odd/outdated criticism. 10s CMS full STW GCs are a thing of the past. There are low-latency GCs available for free in OpenJDK now with sub-millisecond pause times. Where I've seen the two runtimes compared (e.g. Coinbase used both langs in latency-sensitive exchange components) Java's has generally come out ahead.
Actually... https://100go.co/
In reality, you've just made your code unpredictable and there's a good chance you don't know what'll happen when your buffered channel fills up and your code then actually blocks. You may have a deadlock and not realize it.
So if the default position is unbuffered channels (which it should be), you then realize at some point that this is an inferior version of cooperative async/await.
Another general principle is you want to avoid writing multithreaded application code. If you're locking mutexes or starting threads, you're probably going to have a bad time. An awful lot of code fits the model of serving an RPC or HTTP request and, if you can, you want that code to be single-threaded (async/await is fine).
I feel so validated by this comment.
Thank you. I've fixed a lot of bugs in code that assumes because a channel is buffered it is non-blocking. Channels are always blocking, because they have a fixed capacity; my favorite preemptive fault-finding exercise is to go through a codebase and set all channels to be unbuffered, lo-and-behold there's deadlocks everywhere.
If that is the biggest mistake, then the second biggest mistake is attempting to increase performance of an application by increasing channel sizes.
A channel is a pipe connecting two workers, if you make the pipe wider the workers do not process their work any faster, it makes them more tolerant of jitter and that's it. I cringe when I see a channel buffer with a size greater than ~100 - it's a a telltale sign of a misguided optimization or finger waving session. I've seen some channels sized at 100k for "performance" reasons, where the consumer is pushing out to the network, say 1ms for processing and network egress. Are you really expecting the consumer to block for 100 seconds, or did you just think bigger number = faster?
- A struct that represents the mutable state I’m wrapping
- A start(self) method which moves self to a tokio task running a loop reading from an mpsc::Receiver<Command> channel, and returns a Handle object which is cloneable and contains the mpsc::Sender end
- The handle can be used to send commands/requests (including one shot channels for replies)
- When the last handle is dropped, the mpsc channel is dropped and the loop ends
It basically lets me think of each logical concurrent service as being like a tcp server that accepts requests. They can call each other by holding instances of the Handle type and awaiting calls (this can still deadlock if there’s a call cycle and the handling code isn’t put on a background task… in practice I’ve never made this mistake though)
Some day I’ll maybe start using an actor framework (like Axum/etc) which formalizes this a bit more, but for now just making these types manually is simple enough.
And compared to the article, there's no dead coroutine, and no shared state managed by the coroutine: seeing the `NewGame` function return a `*Game` to the managed struct, this is an invitation for dumb bugs. This would be downright impossible in Rust, and coerces you in an actual CSP pattern where the interaction with the shared state is only through channels. Add a channel for exit, another for bookeeping, and you're golden.
I often have a feeling that a lot of the complaints are self-inflicted Go problems. The author briefly touches on them with the special snowflakes that are the stdlib's types. Yes, genericity is one point where channels are different, but the syntax is another one. Why on earth is a `chan <- elem` syntax necessary over `chan.Send(elem)`? This would make non-blocking versions trivial to expose and discover for users (hello Rust's `.try_send()` methods).
Oh and related to the first example of "exiting when all players left", we also see the lack of proper API for go channels: you can't query if there still are producers for the channel because gc and pointers and shared channel objetc itself and yadda. Meanwhile in rust, producers are reference-counted and the channel automatically closed when there are no more producers. The native Go channels can't do that (granted, they could, with a wrapper and dedicated sender and receiver types).
Care to show any example? I'm interested!
> Contrary to popular belief, it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code.
> The feature that the async mutex offers over the blocking mutex is the ability to keep it locked across an .await point.
BTW, you can create a deadlock equivalent with channels if you write "wait for A, reply with B" and "wait for B, send A" logic somewhere. It's the same problem as ordering of nested locks.
1. send a close message on the channel that stops the goroutine
2. use a Context instance - `ctx.Done()` returns a channel you can select on
Both are quite easy to grasp and implement.
Since CSP is mentioned, how much would this apply to most applications anyway? If I write a small server program, I probably won't want to write it on paper first. With one possible exception I never heard of anyone writing programs based on CSP (calculations?)
CSP is really in the realm of formal methods. No you wouldn't formulate your server program as CSP, but if you were writing software for a medical device, perhaps.
This is the FDR4 model checker for CSP, it's a functional programming language that implements CSP semantics and may be used to assert (by exhaustion, IIRC) the correctness of your CSP model.
I believe I'm in the minority of Go developers that have studied CSP, I fell into Go by accident and only took a CSP course at university because it was interesting, however I do give credit to studying CSP for my successes with Go.
Assuming the number of players are set up front, and players can only play or leave, not join. If the expectation is that players can come and go freely and the game ends some time after all players have left, I believe this pattern can still be used with minor adjustment
(please overlook the pseudo code adjustments, I'm writing on my phone - I believe this translates reasonably into compilable Go code):
type Message struct {
exit bool
score int
reply chan bool
}
type Game struct {
bestScore int
players int // > 0
messages chan Message
}
func (g *Game) run() {
for message := range g.messages {
if message.exit {
g.players = g.players - 1;
if g.players == 0 {
return
}
continue
}
if g.bestScore < 100 && g.bestScore < message.score {
g.bestScore = message.score
}
acceptingScores := g.bestScore < 100
message.reply <- acceptingScores
}
}
func (g *Game) HandlePlayer(p Player) error {
for {
score, err := p.NextScore()
if err != nil {
g.messages <- { exit: true
}
return err
}
g.messages <- { score, reply }
if not <- reply {
g.messages <- { exit: true }
return nil
}
}
}I'd really, really recommend that you try writing the code, like the post encourages. It's so much harder than it looks, which neatly sums up my overall experience with Go channels.
Among the errors in the multiplayer case is the lack of score attribution which isn’t a bug with channels as much as it’s using an int channel when you needed a struct channel.
In both cases, you’d need to keep track of connected players to stop the game loop and teardown the Game instance. Closing the channel during that teardown is not a hurdle.
What am I missing?
I was thinking the same, the only problem is the author not keeping track of players
On HandlePlayer return err you would decrement a g.players counter, or something, and in the Game.run just do if !g.hasPlayers() break close(g.scores)
The solution requires nothing special, just basic logic that should probably be there anyway
If anything this post shows that mutexes are worse, by making bad code work
Most experienced Golang practitioners have reached the same conclusions as this blog post: Just don't use channels, even for problems that look simple. I used Go professionally for two years, and it's by far the worst thing about the language. The number of footguns is astounding.
But in general the conclusion still stands. Channels brings unnecessarily complexity. In practice message passing with one queue per goroutine and support for priority message delivery (which one cannot implement with channels) gives better designs with less issues.
Full rebuttal by jerf here: https://news.ycombinator.com/item?id=39317648
Rather than fiddle with Close() calls, from memory what I found worked was setting a short (or in the past) deadline on the Conn (SetReadDeadline). This as it is documented as applying even to an existing blocked call, and makes that blocked call eventually return an error.
So when I wanted to tear down the TCP connection and clean up the various goroutines associated with using the connection, I'd unblock any blocking i/o, then eventually one had an easy Close() call on the connection.
UDP was simpler, as each i/o operation had a short timeout. I've not investigated what could be done for pipe and fifo i/o.
Similarly with Context, if your function calls other functions with Context but always passes in Background(), you deprive your callers of the ability to provide their own Context, which is kinda important. So in practice you still end up adding that argument throughout the entire call hierarchy all the way up to the point where the context is no longer relevant.
Context is only needed where one has a dynamic graph where one wishes to cleanly tear down that graph. One can operate blocking tx/rx within a fixed graph without the need for any Context to be present.
Possibly folks are thinking of this only for "web services" type of things, where everying is being exchanged over an HTTP/HTTPS request.
However channels / CSP can be used in much wider problem realms.
The real gain I found from the CSP / Actor model approach to things is the ability to reason through the problems, and the ability to reason through the bugs.
What I found with CSP is that I accept the possibility of accidentally introducing potential deadlocks (where there is a dependancy loop in messaging) but gain the ability to reason about state / data evolution. As opposed to the "multithreaded" access to manipulate data (albeit with locks/mutexes) where one can not obviously reason through how a change occurred, and its timing.
For the bugs which occur in the two approaches, I found the deadlock with incorrect CSP to be a lot easier to debug (and fix) vs the unknown calling thread which happened to manipulate a piece of (mutex protected) shared state.
This arises from the Actor like approach of a data change only occurring in the context of the one thread.
As the article pointed out lack of support for unbounded channels complicates reasoning about absence of deadlocks. For example, they are not possible at all with Erlang model.
Of cause unbounded message queues have own drawbacks, but then Erlang supports safe killing of threads from other threads so with Erlang a supervisor thread can send health pings periodically and kill the unresponsive thread.
If you run a microbenchmark which seems like what has been done, then channels look slow.
If you try the contention with thousands of goroutines on a high core count machine, there is a significant inflection point where channels start outperforming sync.Mutex
The reason is that sync.Mutex, if left to wait long enough will enter a slow code path and if memory serves, will call out to a kernel futex. The channel will not do this because the mutex that a channel is built with is exists in the go runtime - that's the special sauce the author is complaining doesn't exist but didn't try hard enough to seek it out.
Anecdotally, we have ~2m lines of Go and use channels extensively in a message passing style. We do not use channels to increment a shared number, because that's ridiculous and the author is disingenuous in their contrived example. No serious Go shop is using a channel for that.
Talk about knocking down strawmen: it's a stand-in for shared state, and understanding that should be a minimum bar for serious discussion.
The article that the OP article references does not show the code for their benchmark, but I must assume it's not using a large number of goroutines.
> sync.Mutex, if left to wait long enough will enter a slow code path and if memory serves, will call out to a kernel futex. The channel will not do this because the mutex that a channel is built with is exists in the go runtime
Do you have any more details about this? Why isn’t sync.Mutex implemented with that same mutex channels use?
> [we] use channels extensively in a message passing style. We do not use channels to increment a shared number
What is the rule of thumb your Go shop uses for when to use channels vs mutexes?
https://go.dev/play/p/qXwMJoKxylT
go test -bench=.* -run=^$ -benchtime=1x
Since my critique of the OP is that it's a contrived example, I should mention so is this: the mutex version should be a sync.Atomic and the channel version should have one channel per goroutine if you were attempting to write a performant concurrent counter, both of those alternatives would have low or zero lock contention. In production code, I would be using sync.Atomic, of course.
On my 8c16t machine, the inflection point is around 2^14 goroutines - after which the mutex version becomes drastically slower; this is where I believe it starts frequently entering `lockSlow`. I encourage you to run this for yourself.
> Do you have any more details about this? Why isn’t sync.Mutex implemented with that same mutex channels use?
Why? Designing and implementing concurrent runtimes has not made its way onto my CV yet; hopefully a lurking Go contributor can comment.
The channel mutex: https://go.dev/src/runtime/chan.go
Is not the same mutex as a sync.Mutex: https://go.dev/src/internal/sync/mutex.go
If I had to guess, the channel mutex may be specialised since it protects only enqueuing or dequeuing onto a simple buffer. A sync.Mutex is a general construct that can protect any kind of critical region.
> What is the rule of thumb your Go shop uses for when to use channels vs mutexes?
Rule of thumb: if it feels like a Kafka use case but within the bounds of the local program, it's probably a good bet.
If the communication pattern is passing streams of work where goroutines have an acyclic communication dependency graph, then it's a no brainer: channels will be performant and a deadlock will be hard to introduce.
If you are using channels to protect shared memory, and you can squint and see a badly implemented Mutex or WaitGroup or Atomic; then you shouldn't be using channels.
Channels shine where goroutines are just pulling new work from a stream of work items. At least in my line of work, that is about 80% of the cases where a synchronization primitive is used.
> On my machine, the inflection point is around 10^14 goroutines - after which the mutex version becomes drastically slower;
How often are you reaching 10^14 goroutines accessing a shared resource on a single process in production? We mostly use short-lived small AWS spot instances so I never see anything like that.
> Why? Designing and implementing concurrent runtimes has not made its way onto my CV yet; hopefully a lurking Go contributor can comment. > If I had to guess, the channel mutex may be specialised since it protects only enqueuing or dequeuing onto a simple buffer. A sync.Mutex is a general construct that can protect any kind of critical region.
Haha fair enough, I also know little about mutex implementation details. Optimized specialized tool vs generic tool feels like a reasonable first guess.
Though I wonder if you are able to use channels for more generic mutex purposes is it less efficient in those cases? I guess I'll have to do some benchmarking myself.
> If the communication pattern is passing streams of work where goroutines have an acyclic communication dependency graph, then it's a no brainer: channels will be performant and a deadlock will be hard to introduce.
I agree with your rules, I used to always use channels for single processt thread-safe queues (similar to your Kafka rule) but recently I ran into a cyclic communication pattern with a queue and eventually relented to using a Mutex. I wonder if there are other painful channel concurrency patterns lurking for me to waste time on.
I apologize, that should've said 2^14, each sub-benchmark is a doubling of goroutines.
2^14 is 16000, which for contention of a shared resource is quite a reasonable order of magnitude.
Like closures, channels are very flexible and can be used to implement just about anything; that doesn't mean doing so is a good idea.
I would likely reach for atomics before mutexes in the game example.
I think that was one of the successes of Go
Every big enough concurrent system will conclude sync primitives are dangerous and implement a queue system more similar to channels
Mutexes always look easier for starters, but channels/queues will help you model the problem better in the long term, and debug
Also as a rule of thumb you should probably handle panics every time you start a new thread/goroutine
Is it worth learning it? What problems are best solved with it?
If you are intending to do something that has multiple concurrent tasks ongoing at the same time, I would definitely reach for Go (and maybe be very careful or skip entirely using channels). I also would reach for Go if you intend to work with a large group of other software engineers. Go is rigid; when I first started programming I thought I wanted maximum flexibility, but Go brings uniformity to a group of engineers' output in a way that makes the overall team much more productive IMO.
Basically, I think Go is the best choice for server-side or backend programming, with an even stronger case when you're working with a team.
Go implementations of CSP somewhat mitigated the problems raised in the book by supporting buffered channels, but even with that with CSP one end up with unnecessary tasks which also brings the problem of their lifetime management as the article mentioned.
But there are a couple of problems I can think of.
The first is over-scoping: a structural interface is matched by everything that appears to implement it. This can complicate refactoring when you just want to focus on those types that implement a "specialized" form of the interface. So, the standard library's Stringer interface (with a single `String() string` method) is indistinguishable from my codebase's MyStringer interface with the exact same method. A type can't say it implements MyStringer but not Stringer. The solution for this is dummy methods (add another method `MyStringer()` that does nothing) and/or mangled names (change the only method to `MyString() string` instead of `String() string`) but you do have to plan ahead for this.
The second is under-matching: you might have intended to implement an interface only to realize too late that you didn't match its signature exactly. Now you may have a bunch of types that can't be found as implementations of your interface even though they were meant to be. If you had explicit interface implementation, this wouldn't be a problem, as the compiler would have complained early on. However, this too has a solution: you can statically assert an interface is supposed to be implemented with `var _ InterfaceType = ImplementingType{}` (with the right-hand side adjusted as needed to match the type in question).
I really doubt this comes up in smaller, one-team repos. But in the coding jungle I often deal with, I spend much more time tracing code because of this issue than I'drefactoring. Make no mistake: I like Go, but this irks me.
I think this article on channels suffers from "Seinfeld is Unfunny" syndrome, because the complaints about channels have largely been received and agreed upon by experienced Go developers. Channels are still useful but they were way more prominent in the early days of Go as a solution to lots of problems, and nowadays are instead understood as a sharp tool only useful for specific problems. There's plenty of other tools in the toolbox, so it was easy to move on.
Whereas, nil is still a pain in the ass. Have any nontrivial data that needs to turn into or come from JSON (or SQL, or XML, or ...)? Chances are good you'll need pointers to represent optionality. Chaining structVal.Foo.Bar.Qux is a panic-ridden nightmare, while checking each layer results in a massive amount of boilerplate code that you have to write again and again. Heck, you might even need to handle nil slices specially because the other side considers "null" and "[]" meaningfully distinct! At least nil slices are safe in most places, while nil maps are panic-prone.
As the author of the post, it's really gratifying to hear that this is your assessment nowadays. I agree, and while I'm not sure I had much to do with this turn of events (it probably would have happened with or without me), curbing the use of channels is precisely why I wrote the post. I felt like Go could be much better if everyone stopped messing around with them. So, hooray!
I did expect that this exercise would come after the first one though, and doing this on top of a solution to the first exercise is a bit harder. That said, I also don't mean to claim either are impossible. It's just tough to reason about.
The valid use case for channels is to signal to consumer via channel close in Context.Done() style that something is ready that then can be fetched using separated API.
Then if you need to serialize access, just use locks.
WorkGroup can replace channels in surprisingly many cases.
A message passing queue with priorities implemented on top of mutexes/signals can be used in many cases that require complex interactions between many components.
Still, this example has other issues (naked range over a channel?!) potentially contributing to the author’s confusion.
However, this post was also written almost a decade ago, so perhaps it’s a result of being new to the language? If I cared to look, I’d probably be able to find the corresponding HN thread from that year full of arguments about this, hah.
It is not clear from the example, but I presume there would multiple players, i.e there will calls of the form:
g.HandlePlayer(p1)
g.HandlePlayer(p2)
..
This isn't your rule of thumb, it's the only practical way to do it. The problems arise when you have multiple goroutines writing to a channel, which is the case here.
> Still, this example has other issues (naked range over a channel?!) potentially contributing to the author’s confusion.
You sound way more confused than the author. I think you've misunderstood what the (admittedly very abstract) example is supposed to be doing.
If you don't understand how to use channels, you should learn first. I agree that you might have to learn by experimenting yourself, and that
a) there is a small design flaw in Go channels, but one that is easily fixed; and
b) the standard documentation does not teach good practices for using channels.
First, the design flaw: close(channel) should be idempotent. It is not. Is this a fatal flaw? Hardly. The work around is trivial. Create a wrapper struct with a mutex that allows you to call Close() on the struct, and that effects an idempotent close of the member channel. Yes this is a bit of work, but you do it once, put it in a re-usable library, and never bother to think much about it again.
b) poor recommended practices (range over channel). The original article makes this mistake, and it is what causes his problem: you can never use range over a channel in production code. You must always do any select on a channel alongside a shutdown (bailout) channel, so there will always be at least two channels being select-ed on.
So yes. The docs could be better. It was immediately obvious to me when I learned Go 12 years ago that nobody at Google ever shuts down their services deliberately. Fortunately I was learning Test Driven Development at the time. So I was forced to figure out the above two rules pretty quickly.
Once those two trivial fixes are in place, Go sails. There are Go libraries on github that do this for you. You don't even have to think. But you should.
Handling errors is only as verbose as you want it to be. You do realize you can call a function instead of writing if err != nil so much, right? Sheesh.
Go _is_ something of a sharp tool. Maybe we need to put a warning on it: for mature audiences only.
What if you spawned a new goroutine that waits for a waitgroup to complete and then closes the channel?
This has been said for other languages, and it turns out no one is mature enough to consistently make it work without issues. The world has moved on; we can have proper tools that won't shoot your leg off.
Why risk misusing the sharp tool when you can just use something safe to accomplish the same thing?
I quickly fell in love with Golang... and quickly fell out of love with it as well. It's a language that is super easy to love but it just does not seem to be suited for big codebases at all.
But in any case you will end up using a wrapper on either