[masklinn]

> Go allows you to share memory between goroutines (i.e. concurrent code).

Go will share memory, by default, and special attention must be taken preventing or avoiding it. It's not an allowance.

> In fact, the Go team explicitly tells you not to do that

And yet they have refused to implement a correct model, even though they have no problem imposing their view when it fits them (and having the interpreter get special status in breaking them, see generics).

[burntsushi]

> Go will share memory, by default, and special attention must be taken preventing or avoiding it.

Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes, even if channels are implemented using shared memory under the hood.

That is, the default concurrency model militated by Go is not shared memory, but that of CSP. It's disingenuous to affix Go with the same kind of concurrency model used in C.

> And yet they have refused to implement a correct model

What is a correct model? Erlang's model isn't correct. It's just more safe.

> (and having the interpreter get special status in breaking them, see generics)

What's your point? Purity for purity's sake?

[masklinn]

> Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes

Except since Go has support for neither immutable structures not unique pointers, the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this.

> That is, the default concurrency model militated by Go is not shared memory, but that of CSP. It's disingenuous to affix Go with the same kind of concurrency model used in C.

It's not, go passes mutable objects over its channel and all routines share memory, you get the exact same model by using queues in C.

> What's your point? Purity for purity's sake?

That the Go team has no issue breaking the rules they impose on others, so that point is irrelevant.

[fulafel]

> since Go has support for neither immutable structures not unique pointers, the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this.

Channels are pass-by-value. If you pass a struct, it's copied, and both sides can mutate their own copies as much as they want.

You can get still bugs if you make channels of pointers (or have pointers in your message structs etc).

[masklinn]

> You can get still bugs if you make channels of pointers (or have pointers in your message structs etc).

Confirming that

> the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this.

[burntsushi]

> Except since Go has support for neither immutable structures not unique pointers, the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this.

I never claimed otherwise. But I do think you underestimate the utility of idioms.

> you get the exact same model by using queues in C.

No, you don't. C doesn't have lightweight threads, which means it can't support a useful CSP model of concurrency.

Just because Go allows shared memory doesn't mean its main concurrency model isn't CSP. Go doesn't force CSP on you, but that is nevertheless the primary concurrency model of the language.

[pjmlp]

> No, you don't. C doesn't have lightweight threads, which means it can't support a useful CSP model of concurrency.

Well there are a few libraries available for it.

And Windows C developers can make use of fibers.

[kenko]

>> (and having the interpreter get special status in breaking them, see generics)

>What's your point? Purity for purity's sake?

I assume the point is that the Go developers are saying "purity for thee, but not for me" (if you think generics are impure or unnecessary), or "generics for me, but not for thee", which is just annoying.

[burntsushi]

> which is just annoying

I got that. I'm asking, why?

The decision to use generics or not has nothing to do with purity. It's about trade offs. If a decent balance can be struck with special privileged functions built into the language, I don't see how that is intrinsically bad.

[kenko]

It's not a decision about whether or not to use generics, it's a decision about whether or not to make it possible to use generics.

The developers have decided that they should make it possible for themselves to use generics, but impossible for you to use generics. Do you really not see why that's annoying? That's not a matter of tradeoffs, because they've already made generics possible---for themselves. At best they might be thinking something like "only WE are capable of grokking when generics are appropriate; everyone else would abuse them", which is rather arrogant, no? Lots of people have been saying that go is "missing" generics. The official response seems to be "no it isn't, you don't really need them." The unoffical response (evidenced by the use of generics in the compiler) is apparently "you're right, go is missing generics, so we'll include them, but just for ourselves".

[burntsushi]

> It's not a decision about whether or not to use generics, it's a decision about whether or not to make it possible to use generics.

Fine. That's what I meant.

> Do you really not see why that's annoying?

I can if you believe in purity over all else.

> That's not a matter of tradeoffs, because they've already made generics possible---for themselves.

Sorry, but what? Are you really trying to claim that adding generics for the entire language has exactly the same trade offs as adding a few built in functions that are generic?

> At best they might be thinking something like "only WE are capable of grokking when generics are appropriate; everyone else would abuse them", which is rather arrogant, no?

I think you've significantly misunderstood the issue. I believe my initial characterization is right: you think this is about purity. It's not.

Please read Russ Cox's short blurb on the "Generic Dilemma." [1] No part of it has anything to do with "we know better than you."

> The official response seems to be "no it isn't, you don't really need them."

No. The official response is "we don't know of an implementation that we're happy with." It's not a philosophical stance. It's a practical stance.

[1] - http://research.swtch.com/generic

[kenko]

Honestly, I don't know what you even mean by purity.

[lmm]

>What's your point? Purity for purity's sake?

If go couldn't even implement its own interpreter in vanilla go, that's a sign that it's going to be a bad language.

[reeses]

Is it that they couldn't or haven't? It's obviously capable of compiling code, but with the state of compilers today (impressive backends, etc.) does it make sense to have a three-stage bootstrap (minimal C → mini-go → full-go → optimized-full-go) at this point?

[jeremyjh]

It would be nice if Go provided for immutable variables.

[Evbn]

for i:= range list { go func() { foo(i) } }

(This is a bug in the spec, but will not be fixed before Go 2 because Go 1.0 is frozen.)

Shared memory by default.

[burntsushi]

You've completely missed my point. I wasn't claiming that Go did anything to stop you from sharing memory. I was claiming that its concurrency model is CSP, not shared memory.

> (This is a bug in the spec, but will not be fixed before Go 2 because Go 1.0 is frozen.)

Could you kindly link me, please?