9 ms·

This has finally let me figure out what annoys me about Go, its a cargo-cult language. People saw that Erlang's Actors/processes were really popular and made it

by octo_t 13y ago

This has finally let me figure out what annoys me about Go, its a cargo-cult language. People saw that Erlang's Actors/processes were really popular and made it easy to write good, concurrent software. They then went away and implemented their own language with lightweight processes and message passing, but missed the fact that actors are the price you have to pay for the benefits of not sharing mutable data. And Go completely skipped that part (the most important part).

sbov 13y ago
Channels are basically queues with beefed up language support. Not sure what's so annoying about that considering it's a very common concurrency pattern across many languages.
timclark 13y ago
Doesn't go just implement Hoare's communicating sequential processes, as does Erlang? They share the same inspiration. You don't need to share state data between your goroutines if you don't want to either just like you don't have to use mnesia to share state between erlang processes if you don't want to. I don't think you can really accuse go of being a cargo cult language either, Rob Pike has implemented CSP multiple times (http://swtch.com/~rsc/thread/ http://swtch.com/~rsc/thread/).
- ridiculous_fish 13y ago
  It is easy to accidentally share state between goroutines. For example, we wish to print out elements of a list: values := []string{"a", "b", "c"} for _, v := range values { go fmt.Println(v) } Each of these goroutines shares the same variable v, so this code contains a serious race condition.
  - Jabbles 13y ago
    It may be easy, but it's not that easy. values := []string{"a", "b", "c"} for _, v := range values { go func(){fmt.Println(v);}() } Does have a race condition. values := []string{"a", "b", "c"} for _, v := range values { go func(s string){fmt.Println(s);}(v) } Does not have a race condition.
    - flyinRyan 13y ago
      You're still shaving v here, we can just see from the snipped that the shared v isn't used inside the anon function. But I suspect what the GP meant by "easy" is not having to think about this sort of thing. Your solution is good when you know you need to do this, but it can't even happen in Erlang so it's not a "gotcha" to watch out for.
      - Jabbles 13y ago
        Sharing v isn't the problem. The problem occurs when v is evaluated. The parent's post has no race condition, as v is evaluated before the goroutine starts. The top example of my post has a race condition because there is no guarantee when v will be evaluated wrt to the loop. The bottom example has no race condition because v is evaluated on every iteration and assigned to s, which is used by the goroutine at some point afterwards.
        flyinRyan 13y ago
        My point still stands: to fix this, you have to realize that (a) v could be shared here and (b) that sharing could be a problem. I suspect the first time most newbies get hit with a race condition here they're going to be beyond baffled.
- smosher 13y ago
  Doesn't go just implement Hoare's communicating sequential processes, as does Erlang? They share the same inspiration. Nope: The original Communicating Sequential Processes model[24] published by Tony Hoare differed from the Actor model because it was based on the parallel composition of a fixed number of sequential processes connected in a fixed topology, and communicating using synchronous message-passing based on process names (see Actor model and process calculi history). Later versions of CSP abandoned communication based on process names in favor of anonymous communication via channels, an approach also used in Milner's work on the Calculus of Communicating Systems and the π-calculus.¹ ¹: https://en.wikipedia.org/wiki/Actor_model#Contrast_with_other_models_of_message-passing_concurrency https://en.wikipedia.org/wiki/Actor_model#Contrast_with_othe...

by octo_t 13y ago

sbov 13y ago

Channels are basically queues with beefed up language support. Not sure what's so annoying about that considering it's a very common concurrency pattern across many languages.

timclark 13y ago

Doesn't go just implement Hoare's communicating sequential processes, as does Erlang? They share the same inspiration. You don't need to share state data between your goroutines if you don't want to either just like you don't have to use mnesia to share state between erlang processes if you don't want to. I don't think you can really accuse go of being a cargo cult language either, Rob Pike has implemented CSP multiple times (http://swtch.com/~rsc/thread/ http://swtch.com/~rsc/thread/).

ridiculous_fish 13y ago
It is easy to accidentally share state between goroutines. For example, we wish to print out elements of a list: values := []string{"a", "b", "c"} for _, v := range values { go fmt.Println(v) } Each of these goroutines shares the same variable v, so this code contains a serious race condition.
- Jabbles 13y ago
  It may be easy, but it's not that easy. values := []string{"a", "b", "c"} for _, v := range values { go func(){fmt.Println(v);}() } Does have a race condition. values := []string{"a", "b", "c"} for _, v := range values { go func(s string){fmt.Println(s);}(v) } Does not have a race condition.
  - flyinRyan 13y ago
    You're still shaving v here, we can just see from the snipped that the shared v isn't used inside the anon function. But I suspect what the GP meant by "easy" is not having to think about this sort of thing. Your solution is good when you know you need to do this, but it can't even happen in Erlang so it's not a "gotcha" to watch out for.
    - Jabbles 13y ago
      Sharing v isn't the problem. The problem occurs when v is evaluated. The parent's post has no race condition, as v is evaluated before the goroutine starts. The top example of my post has a race condition because there is no guarantee when v will be evaluated wrt to the loop. The bottom example has no race condition because v is evaluated on every iteration and assigned to s, which is used by the goroutine at some point afterwards.
      - flyinRyan 13y ago
        My point still stands: to fix this, you have to realize that (a) v could be shared here and (b) that sharing could be a problem. I suspect the first time most newbies get hit with a race condition here they're going to be beyond baffled.
smosher 13y ago
Doesn't go just implement Hoare's communicating sequential processes, as does Erlang? They share the same inspiration. Nope: The original Communicating Sequential Processes model[24] published by Tony Hoare differed from the Actor model because it was based on the parallel composition of a fixed number of sequential processes connected in a fixed topology, and communicating using synchronous message-passing based on process names (see Actor model and process calculi history). Later versions of CSP abandoned communication based on process names in favor of anonymous communication via channels, an approach also used in Milner's work on the Calculus of Communicating Systems and the π-calculus.¹ ¹: https://en.wikipedia.org/wiki/Actor_model#Contrast_with_other_models_of_message-passing_concurrency https://en.wikipedia.org/wiki/Actor_model#Contrast_with_othe...