←back to thread

159 points mpweiher | 1 comments | | HN request time: 0s | source
Show context
jmyeet ◴[] No.43673300[source]
The biggest mistake I see people make with Go channels is prematurely optimizing their code by making channels buffered. This is almost always a mistake. It seems logical. You don't want your code to block.

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).

replies(2): >>43673452 #>>43675569 #
1. sapiogram ◴[] No.43673452[source]
> 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.

I feel so validated by this comment.