←back to thread

Go channels are bad

(www.jtolds.com)
298 points jtolds | 5 comments | 02 Mar 16 15:40 UTC | HN request time: 1.029s | source
Show context
hacknat ◴[02 Mar 16 16:36 UTC] No.11211002[source]▶
I think I've just come to accept that sychronization is the pain point in any language. It's callbacks, promises, and the single event loop in nodejs. It's channels in golang.

No one can come up with a single abstraction for synchronization without it failing in some regard. I code in go quite a bit and I just try to avoid synchronization like the plague. Are there gripes I have with the language? Sure, CS theory states that a thread safe hash table can perform just about as well as a none-thread safe, so why don't we have one in go? However...

Coming up with a valid case where a language's synchronization primitive fails and then flaming it as an anti-pattern (for the clicks and the attention, I presume) is trolling and stupid.

replies(3): >>11211077 #>>11211292 #>>11211863 #
zzzcpan ◴[02 Mar 16 17:14 UTC] No.11211292[source]▶
> I think I've just come to accept that sychronization is the pain point in any language.

No, it's not. Everything is easier with event loops, because everything is always synchronized. And since it is, there is no need for concurrent hash tables, locks, channels, you name it. There is also no more shutdown and cancellation problems, you get them for free and easier than anything. The only thing left is a __consistent__ API with callbacks. But as long as you go with higher order functions you are not going to have any problems.

replies(1): >>11211318 #
1. hacknat ◴[02 Mar 16 17:18 UTC] No.11211318[source]▶
What if you need to do a compute intensive task on a large data structure? You know you might need to take advantage of more than one core and sharing memory between the threads will be difficult. Assuming you're talking about nodeJS, nodeJS serializes and deserializes objects in and out of C++ land in order to do compute intensive tasks. Hardly a catch all!

Are event loops good at some things? Of course! Are the good at everything. Are you high?

replies(1): >>11211620 #
2. zzzcpan ◴[02 Mar 16 17:51 UTC] No.11211620[source]▶
Well, no, I'm not talking about nodejs. Just in general, about event loops in programming languages.

> What if you need to do a compute intensive task on a large data structure?

That's a very specialized thing, not something general, that everyone needs. But either way there is no problem abstracting it away with higher order functions in event loops.

However, everyone will most definitely need networking and doing networking by sharing memory between threads is very very hard. Event loops are much easier for that.

replies(2): >>11212220 #>>11212288 #
3. jerf ◴[02 Mar 16 19:16 UTC] No.11212220[source]▶
Either your event handlers are going to be called in a nondeterministic order, or they won't.

If they are going to be called in a nondeterministic order, you still have access control issues and can get yourself into all sorts of concurrency-style problems.

If they aren't going to be called in a nondeterministic order, perhaps because you just have a single cascade of events (open socket, write this, get that, close socket), then in a language like Go you just write the "synchronous"-looking code, and you don't have to write the code as if it's evented. You have only marginally more sharing problems than the event loop.

Raw usage of event loops are a false path. They solve very few problems and introduce far more.

replies(1): >>11212641 #
4. hacknat ◴[02 Mar 16 19:25 UTC] No.11212288[source]▶
>That's a very specialized thing, not something general

While polling for i/o may be common the next most common problem in computers is solving computationally complex tasks. Why is Intel making all these cores? I guess no one actually needs them, they just think they do.

5. zzzcpan ◴[02 Mar 16 20:12 UTC] No.11212641{3}[source]▶
> Either your event handlers are going to be called in a nondeterministic order, or they won't.

The order is not going to be completely deterministic, but your whole program operates on explicitly deterministic units of computation that never implicitly execute in parallel (event handlers). This eliminates all of those issues with concurrent memory access.

Writing "synchronous" looking code cannot be a substitute, since it makes these units of computation implicit. After which it's no longer possible to distinguish which function call is going to yield, therefore dealing with concurrent memory access is going to be needed, just like in any multithreaded program.

So, no, event loops are superior to multithreaded model in almost every way.