zlacker

I don't think anyone is suggesting that Go's concurrency model is perfect. However, the OP said "trying to remove the red/blue split will not work". This is a pretty strong claim, and Go seems like a reasonable counterexample to it.

Similarly, if someone said "trying to marry async to a language with lifetime analysis and no GC will not work", it would be reasonable to point to Rust as a counterexample, even though Rust async has various problems.

>>foldr+(OP)
The rest of the quote was:

> ...you'll only be pretending it doesn't exist

Which is what I was providing evidence of that Go does.

It removes coloring to the user by handling it under the hood. The linked article calls this "colorblind instead of colorless".

>>jamesm+n3
Sure. My point is that 'pretending that the distinction doesn't exist' (aka 'abstracting away from it', in less loaded language) does in fact work. Go's concurrency model is perfectly usable and successfully reaps many of the advantages of M:N scheduling.

Let's look at a less loaded example:

"Trying to remove the distinction between stack and heap allocation will not work, and you'll only be pretending that it doesn't exist."

It's true that on some level there's going to be a distinction between stack and heap allocation. But it totally does work to abstract away from this distinction ('pretend that it doesn't exist'). Go, for example, will usually allocate non-escaping values on the stack, but unless you are tweaking your code for performance, you'll never have to worry about this.