←back to thread

Go channels are bad

(www.jtolds.com)
298 points jtolds | 6 comments | 02 Mar 16 15:40 UTC | HN request time: 0.212s | source | bottom
1. divan ◴[02 Mar 16 17:48 UTC] No.11211592[source]▶
I didn't get the point of example with Game and Player. The code behaves exactly how it's told to. If you need some logic to handle conditions where all players have been disconnected - you should implement it, no matter how. Maybe you want to wait for some time for a new players and teardown only after this timeout. Or, maybe, you want to reuse this game object, moving to some kind of pool (like sync.Pool). Or, perhaps, you really want to wait forever for returning players. It's not 'mutex vs channels' example in any way.

It's not 'fix goroutine leak' it's "write the logic you want", it's that simple.

Next, channels are slow, really? Send-receive operation on unbuffered channel typically takes around 300ns. Nanoseconds. 300 nanosecond in exchange of nice and safe way to express concurrent things - I wouldn't even call it a tradeoff. It's not slow at all in vast majority of cases. Of course, if you write that software that do care about nanoseconds and channels becomes your bottleneck - congratulations, you're doing great, and you probably have to switch to C++, Rust or even Assembler.

But, please, don't mislead people telling them, that channels are slow. They could be slow for your exact case, but it's not the same.

I don't really get the tone and arguments of the article. Some of the points are totally valid, but they easily falls into the 'hey folks, be careful about this small thing you may misunderstand at the beginning' category. Pity.

replies(3): >>11211665 #>>11211666 #>>11211933 #
2. nemothekid ◴[02 Mar 16 18:00 UTC] No.11211666[source]▶
>* Of course, if you write that software that do care about nanoseconds and channels becomes your bottleneck - congratulations, you're doing great, and you probably have to switch to C++, Rust or even Assembler.*

Thats ridiculous. I could switch my entire language... or I could just use a lock?

First off, looking at Tyler's post, he measured unbuffered channels taking 2200ns vs 400ns for the lock solution - a 5x speed up. That is a large gain, especially when dealing a program that may have high lock contention. Switch from Go to C++ or Rust my not even gain you that much in terms of throughput - they are both compiled code and moving to either language will only mainly alleviate of magic STW pauses - acquiring a lock likely won't be any faster.

Second, in the point of Game and Player, the logic to handle conditions where players disconnect is still simpler to implement with locks - its 2 lines, and there is no need to bring in sync.Pool, or introduce arbitrary timeouts.

Channels are slower than locks. In more complex applications, channels are easier to reason about than locks, but those tends to be in cases where you care more about message passing than state synchronization.

replies(1): >>11211692 #
3. dllthomas ◴[02 Mar 16 18:00 UTC] No.11211665[source]▶
I've done work where 300 nanoseconds is a noticeable chunk of my time budget...

(not, of course, in go...)

4. pcwalton ◴[02 Mar 16 18:04 UTC] No.11211692[source]▶
> Switch from Go to C++ or Rust my not even gain you that much in terms of throughput - they are both compiled code and moving to either language will only mainly alleviate of magic STW pauses

That is not the only performance-related difference between those language implementations. It's not even the most significant one.

For instance, there is a large difference between a compiler with LLVM's optimizations and one without an SSA backend at all.

replies(1): >>11212719 #
5. stcredzero ◴[02 Mar 16 18:36 UTC] No.11211933[source]▶
Of course, if you write that software that do care about nanoseconds and channels becomes your bottleneck - congratulations, you're doing great, and you probably have to switch to C++, Rust or even Assembler.

Why not profile to identify which channels are a bottleneck and just replace them with a Disruptor?

https://github.com/smartystreets/go-disruptor

6. ngrilly ◴[02 Mar 16 20:24 UTC] No.11212719{3}[source]▶
The new Go SSA backend was merged into tip a few days ago:

https://groups.google.com/d/topic/golang-dev/49VaiLCDbeQ/dis...