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).
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/).
values := []string{"a", "b", "c"}
for _, v := range values {
go fmt.Println(v)
}
values := []string{"a", "b", "c"}
for _, v := range values {
go func(){fmt.Println(v);}()
}
values := []string{"a", "b", "c"}
for _, v := range values {
go func(s string){fmt.Println(s);}(v)
}
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.
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_othe...