4 ms·

The terminology could use some refinement. Not sure "message passing" is the right phrase to describe Go channels. Most encounters I've had with "message pass

The 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-should-feel-bad/ https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s...

zzzcpan 8y ago
It's fine. It's still message passing and it's obvious they refer to Go flavored CSP style message passing whenever they talk about it, not anything else.
- eternalban 8y ago
  (I've been using Go since it was released and like the language.) Go tried CSP in the beginning but in CSP the 'sequential process' preempts only on blocking (IO) or until finished. Also message passing is just that. You can't reach out and modify a message after you have posted it, IRL. This means messages are 'safe' to use concurrently since they are copies. That, in conjuction with strict CSP ssemantics (processes always run to completion with no preemptive cooperation) gets you 'safe concurrency' at the price of performance and at scale 'reasoning' about what is happening. So, the practical decisions were (a) honors system message passing via references, (b) preemption at IO and elsewhere, and (c) introduction of mutex, etc. to fall back to [more performant] 'light weight threads' and 'locks' paradigm.
api 8y ago
I don't see why blocking is an issue given that goroutines are light weight threads. They are really cheap and can be created as needed, eliminating much of the need for async patterns. It's one of the nicest things about Go given that async is just manually implemented lightweight threading. I would say though that go channels have not turned out to be as useful as I thought they would be. I dont find myself using them that much. But maybe it's just my style or the type of stuff I am writing.
- ec109685 8y ago
  Lightweight threads are different than async models. With the latter work continues until io or a manual yield happens. With threads, your workload can be preempted outside your control.
- jstewartmobile 8y ago
  Blocking is a pretty big deal. With something like pipes or sockets, there are timeouts and saner handling of breakages. With Go channels, one false move, and you've got a panic or an infinite wait. I like Go, just not a big fan of channels.
- pcwalton 8y ago
  > It's one of the nicest things about Go given that async is just manually implemented lightweight threading. No, async/await is typically stackless, while goroutines have stacks. That's a significant difference.
- littlestymaar 8y ago
  Blocking implies you can get deadlocks if you're not cautious, whereas with async you just can't.

zzzcpan 8y ago

It's fine. It's still message passing and it's obvious they refer to Go flavored CSP style message passing whenever they talk about it, not anything else.

eternalban 8y ago
(I've been using Go since it was released and like the language.) Go tried CSP in the beginning but in CSP the 'sequential process' preempts only on blocking (IO) or until finished. Also message passing is just that. You can't reach out and modify a message after you have posted it, IRL. This means messages are 'safe' to use concurrently since they are copies. That, in conjuction with strict CSP ssemantics (processes always run to completion with no preemptive cooperation) gets you 'safe concurrency' at the price of performance and at scale 'reasoning' about what is happening. So, the practical decisions were (a) honors system message passing via references, (b) preemption at IO and elsewhere, and (c) introduction of mutex, etc. to fall back to [more performant] 'light weight threads' and 'locks' paradigm.

api 8y ago

I don't see why blocking is an issue given that goroutines are light weight threads. They are really cheap and can be created as needed, eliminating much of the need for async patterns. It's one of the nicest things about Go given that async is just manually implemented lightweight threading. I would say though that go channels have not turned out to be as useful as I thought they would be. I dont find myself using them that much. But maybe it's just my style or the type of stuff I am writing.

ec109685 8y ago
Lightweight threads are different than async models. With the latter work continues until io or a manual yield happens. With threads, your workload can be preempted outside your control.
jstewartmobile 8y ago
Blocking is a pretty big deal. With something like pipes or sockets, there are timeouts and saner handling of breakages. With Go channels, one false move, and you've got a panic or an infinite wait. I like Go, just not a big fan of channels.
pcwalton 8y ago
> It's one of the nicest things about Go given that async is just manually implemented lightweight threading. No, async/await is typically stackless, while goroutines have stacks. That's a significant difference.
littlestymaar 8y ago
Blocking implies you can get deadlocks if you're not cautious, whereas with async you just can't.