4 ms·

Why not call this for what it is? It's CSP in C. Go is not the only language in which CSP is used as the concurrency model. I understand using "Go-style" as an

Why not call this for what it is? It's CSP in C. Go is not the only language in which CSP is used as the concurrency model. I understand using "Go-style" as an adjective to describe this makes it easier for the uninitiated but it's doing everyone a disservice IMHO.

zucker42 5y ago
Looks like it is "go-style" because the API/syntax is modelled after the go API. In particular the "choose" macro from the example looks to be designed to mimic "select" even though otherwise macros might be dispreferred. There's another library linked that has similar functionality with a less go-like API. Just a guess.
- stingraycharles 5y ago
  As someone who worked with a decent variety of languages that all claim their fame to CSP (Erlang, Clojure and Go), suffice to say that these all look very similar. It’s the tooling _around_ the CSP where the real differences are.
  - deleted 5y ago
    [deleted]
  - gpderetta 5y ago
    Isn't erlang closer to actors than CSP? I.e. no rendez-vous. Edit: this has been better discussed elsethread.
- yakubin 5y ago
  I think Concurrent ML (1991) had select before Go. Go itself took it from Newsqueak (1994) and Limbo (1995) I think. The name itself probably comes from the UNIX select(2) syscall, which first appeared in 4.2BSD (1983).
adrusi 5y ago
Well it's specifically CSP using cooperative multitasking (sadly no multithreading support unlike go) and a go-like API. CSP is a lot less specific than that.
mmcgaha 5y ago
I think because many people's first exposure to CSP was in go, go-style-concurrency has become the crescent wrench of CSP.
intrepidhero 5y ago
I'm very much a novice in concurrent programming so I looked that up: https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce... > ...communicating sequential processes (CSP) is a formal language for describing patterns of interaction in concurrent systems. > ... based on message passing via channels. That seems like a mathematical language that could describe goroutines and channels but also seems like it could describe python's multiprocessing and queue constructs. I think of those as very different things given the (vastly different) applications. When I think of "go-style" I think of lightweight threads (I can have 1000s), where as python processes are heavy (100 is pushing it?). So maybe the specifics of the implementation have as much to do with the go-style as the abstract concept? My understanding here is fuzzy for sure and I welcome corrections and more detail.
- jlokier 5y ago
  There are no queues in CSP, although you can make one by making a queue process. In CSP, the sending side of a message is always logically simultaneous with the receiving side. So it's like Go's default channels where the sender and receiver both block until ready to transfer, and different from Python's multiprocessing and queue constructs, where the sender doesn't block. CSP was used in Occam¹ on Transputers² in the 1980s. In Occam, it was normal to have a large number of tiny processes, some of them maybe only a few instructions (such as an implementation of a queue), and the thread switching and communication primitives were actual CPU instructions. The CPUs were joined with dedicated message communication links into large meshes, providing hardware parallelism with a very different model than today's SMP multi-core. A similar architecture exists today, XMOS³. Go implements a model similar to CSP on today's SMP multi-core systems and OSes, emphasising many efficient, small threads running loops that communicate synchronously. Channels are unbuffered by default, making them like CSP. They can be made buffered, which adds a queue, as if a CSP queue process was added. Go is much less rigid than Occam, because you can also make new channels and spawn new threads efficiently, which are essential features in modern sofware. Python multiprocessing doesn't provide efficient, small threads. You need larger thread units to get good performance out of it. It also emphasises queuing. So it's quite different from CSP. Erlang implements a model like Occam and Go of many, efficient, small threads, but the messaging is always asynchronous. The communication is similar to Go with buffered channels. ¹ https://en.wikipedia.org/wiki/Occam_(programming_language) https://en.wikipedia.org/wiki/Occam_(programming_language) ² https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer ³ https://en.wikipedia.org/wiki/XMOS https://en.wikipedia.org/wiki/XMOS
freedomben 5y ago
Interesting, I didn't realize CSP was so specific. I heard someone say that Erlang's model was CSP too. They aren't called "channels" but they're very similar in that you have two different process/threads that are reading/writing to/from an ordered stream that feels the same as reading/writing to/from a Go channel. What would Erlang's model be called? Does "the Actor Model" cover it?
- Jtsummers 5y ago
  Yes, Erlang is based more on the actor model. CSP is synchronous, so sending to a channel will block if the receiver isn't ready. Erlang and actors are asynchronous in this matter. They will send regardless of whether the receiver is in a state where it can receive the message. Practically, Go (and libmill) allow buffered channels so that you only block if the channel's buffer is full. CSP is based on anonymous processes. Actors have identity, and this would be the process IDs in Erlang. Erlang and the actor model don't use channels (though you can use processes to mimic them).
  - masklinn 5y ago
    > Practically, Go (and libmill) allow buffered channels so that you only block if the channel's buffer is full. Go also allows rendezvous channel (channels with an empty buffer, so either side can only proceed when the other arrives: the actual message exchange is synchronous).
  - freedomben 5y ago
    Nice, thanks that makes a lot of sense and definitely an important difference.
- paskozdilar 5y ago
  Technically, Erlang is based on Actor model. But both models are formally equivalent, i.e. you can simulate one model in another. Go can somewhat emulate Actor model using concurrency control structures and buffered channels with non-blocking send to emulate mailboxes.
deleted 5y ago
[deleted]
aidenn0 5y ago
Libdill[1] is the structured concurrency (i.e. CSP) library by this author. Libmill is specifically trying to look as much like Go as possible. 1: http://libdill.org/ http://libdill.org/
paskozdilar 5y ago
Go is (I think?) the first popular language that's CSP oriented. Just like many Actor model languages are often referred to as "Erlang-style".
rubenbe 5y ago
There is even the xcore cpu by xmos has CSP support in hardware.

zucker42 5y ago

Looks like it is "go-style" because the API/syntax is modelled after the go API. In particular the "choose" macro from the example looks to be designed to mimic "select" even though otherwise macros might be dispreferred. There's another library linked that has similar functionality with a less go-like API. Just a guess.

stingraycharles 5y ago
As someone who worked with a decent variety of languages that all claim their fame to CSP (Erlang, Clojure and Go), suffice to say that these all look very similar. It’s the tooling _around_ the CSP where the real differences are.
- deleted 5y ago
  [deleted]
- gpderetta 5y ago
  Isn't erlang closer to actors than CSP? I.e. no rendez-vous. Edit: this has been better discussed elsethread.
yakubin 5y ago
I think Concurrent ML (1991) had select before Go. Go itself took it from Newsqueak (1994) and Limbo (1995) I think. The name itself probably comes from the UNIX select(2) syscall, which first appeared in 4.2BSD (1983).

adrusi 5y ago

Well it's specifically CSP using cooperative multitasking (sadly no multithreading support unlike go) and a go-like API. CSP is a lot less specific than that.

mmcgaha 5y ago

I think because many people's first exposure to CSP was in go, go-style-concurrency has become the crescent wrench of CSP.

intrepidhero 5y ago

I'm very much a novice in concurrent programming so I looked that up: https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce... > ...communicating sequential processes (CSP) is a formal language for describing patterns of interaction in concurrent systems. > ... based on message passing via channels. That seems like a mathematical language that could describe goroutines and channels but also seems like it could describe python's multiprocessing and queue constructs. I think of those as very different things given the (vastly different) applications. When I think of "go-style" I think of lightweight threads (I can have 1000s), where as python processes are heavy (100 is pushing it?). So maybe the specifics of the implementation have as much to do with the go-style as the abstract concept? My understanding here is fuzzy for sure and I welcome corrections and more detail.

jlokier 5y ago
There are no queues in CSP, although you can make one by making a queue process. In CSP, the sending side of a message is always logically simultaneous with the receiving side. So it's like Go's default channels where the sender and receiver both block until ready to transfer, and different from Python's multiprocessing and queue constructs, where the sender doesn't block. CSP was used in Occam¹ on Transputers² in the 1980s. In Occam, it was normal to have a large number of tiny processes, some of them maybe only a few instructions (such as an implementation of a queue), and the thread switching and communication primitives were actual CPU instructions. The CPUs were joined with dedicated message communication links into large meshes, providing hardware parallelism with a very different model than today's SMP multi-core. A similar architecture exists today, XMOS³. Go implements a model similar to CSP on today's SMP multi-core systems and OSes, emphasising many efficient, small threads running loops that communicate synchronously. Channels are unbuffered by default, making them like CSP. They can be made buffered, which adds a queue, as if a CSP queue process was added. Go is much less rigid than Occam, because you can also make new channels and spawn new threads efficiently, which are essential features in modern sofware. Python multiprocessing doesn't provide efficient, small threads. You need larger thread units to get good performance out of it. It also emphasises queuing. So it's quite different from CSP. Erlang implements a model like Occam and Go of many, efficient, small threads, but the messaging is always asynchronous. The communication is similar to Go with buffered channels. ¹ https://en.wikipedia.org/wiki/Occam_(programming_language) https://en.wikipedia.org/wiki/Occam_(programming_language) ² https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer ³ https://en.wikipedia.org/wiki/XMOS https://en.wikipedia.org/wiki/XMOS

freedomben 5y ago

Interesting, I didn't realize CSP was so specific. I heard someone say that Erlang's model was CSP too. They aren't called "channels" but they're very similar in that you have two different process/threads that are reading/writing to/from an ordered stream that feels the same as reading/writing to/from a Go channel. What would Erlang's model be called? Does "the Actor Model" cover it?

Jtsummers 5y ago
Yes, Erlang is based more on the actor model. CSP is synchronous, so sending to a channel will block if the receiver isn't ready. Erlang and actors are asynchronous in this matter. They will send regardless of whether the receiver is in a state where it can receive the message. Practically, Go (and libmill) allow buffered channels so that you only block if the channel's buffer is full. CSP is based on anonymous processes. Actors have identity, and this would be the process IDs in Erlang. Erlang and the actor model don't use channels (though you can use processes to mimic them).
- masklinn 5y ago
  > Practically, Go (and libmill) allow buffered channels so that you only block if the channel's buffer is full. Go also allows rendezvous channel (channels with an empty buffer, so either side can only proceed when the other arrives: the actual message exchange is synchronous).
- freedomben 5y ago
  Nice, thanks that makes a lot of sense and definitely an important difference.
paskozdilar 5y ago
Technically, Erlang is based on Actor model. But both models are formally equivalent, i.e. you can simulate one model in another. Go can somewhat emulate Actor model using concurrency control structures and buffered channels with non-blocking send to emulate mailboxes.

deleted 5y ago

[deleted]

aidenn0 5y ago

Libdill[1] is the structured concurrency (i.e. CSP) library by this author. Libmill is specifically trying to look as much like Go as possible. 1: http://libdill.org/ http://libdill.org/

paskozdilar 5y ago

Go is (I think?) the first popular language that's CSP oriented. Just like many Actor model languages are often referred to as "Erlang-style".

rubenbe 5y ago

There is even the xcore cpu by xmos has CSP support in hardware.