Re:Conc: Better Structured Concurrency for Go
by philosopher1234 on Thursday January 12, 2023 @04:15AM
(#34351024)
> That nothing about it’s good
You have a very myopic view of what makes concurrency designs good.
I suggest you broaden your perspective, and consider the practical effects of language design on humans, as opposed to just mathematically provable safety.
Re:Conc: Better Structured Concurrency for Go
by masklinn on Thursday January 12, 2023 @05:19AM
(#34351534)
Ah, you’re a fanboy. You could have just put that upfront I would not have wasted my time taking you seriously.
Re:Conc: Better Structured Concurrency for Go
by philosopher1234 on Thursday January 12, 2023 @05:35AM
(#34351635)
You wrote "That nothing about it’s good". That's stupid. I agree we are wasting our time.
Re:Conc: Better Structured Concurrency for Go
by Smurfix on Thursday January 12, 2023 @08:16AM
(#34353003)
Well, Ok, so the main thing that's good about it is that it's dead easy to start a goroutine. But that's actually bad, just like randomly jumping to any piece of code whatsoever is bad in in a procedural language.
Read the Structured Concurrency notes (https://vorpus.org/blog/notes-on-structured-concurrency-or-g...) for the reasons why.
Re:Conc: Better Structured Concurrency for Go
by philosopher1234 on Thursday January 12, 2023 @08:51AM
(#34353442)
I don’t know. I think the culture around go encourages effective/safe strategies for using go routines + channels. I think when channels are used as intended they can be quite effective. They’re not technically more safe than anything else, but I think the fact that they make concurrency more manageable is good.
That nothing about it’s good? It’s the same shared-memory concurrency everybody else has, that it had to built-in a thread-safe queue doesn’t fix that.
In some ways it makes it worse, because it’s easy for the unwary to assume channel = safe, whereas nothing could be further from the truth: a channel only protects itself, sending a slice through a channel is not safe, sending a map through a channel is not safe, sending a pointer to a channel is not safe, etc… and this is transitive, sending by value a struct which contains any of those isn’t safe either.
Not to mention the easy and common issue of implicit concurrent sharing via `go` closures.
Here’s a bunch of examples: https://www.uber.com/blog/data-race-patterns-in-go
And these are data races, not merely concurrency issues.