4 ms·

> It was famous for good concurrency That’s because people confuse “easy” and “good”. Go has easy concurrency, but it’s not good. The opposite really. It’s at

> It was famous for good concurrency That’s because people confuse “easy” and “good”. Go has easy concurrency, but it’s not good. The opposite really. It’s at best the similar problematic model you get in other, older, procedural / oo langages. At worst it’s a lot worse given how difficult it is (and even more so was before generics) to build abstractions and concurrent data structures.

philosopher1234 4y ago
What is bad about it? An example would help me understand you better.
- masklinn 4y ago
  > What is bad about it? 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 https://www.uber.com/blog/data-race-patterns-in-go And these are data races, not merely concurrency issues.
  - philosopher1234 4y ago
    > 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.
    - masklinn 4y ago
      Ah, you’re a fanboy. You could have just put that upfront I would not have wasted my time taking you seriously.
      - philosopher1234 4y ago
        You wrote "That nothing about it’s good". That's stupid. I agree we are wasting our time.
        Smurfix 4y ago
        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-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...) for the reasons why.
        philosopher1234 4y ago
        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.
pkolaczk 4y ago
It is easy to learn the concepts, but not actually to use them. It is like with assembly, learning mnemonics is easy, but writing useful programs is a whole lot different story.

philosopher1234 4y ago

What is bad about it? An example would help me understand you better.

masklinn 4y ago
> What is bad about it? 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 https://www.uber.com/blog/data-race-patterns-in-go And these are data races, not merely concurrency issues.
- philosopher1234 4y ago
  > 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.
  - masklinn 4y ago
    Ah, you’re a fanboy. You could have just put that upfront I would not have wasted my time taking you seriously.
    - philosopher1234 4y ago
      You wrote "That nothing about it’s good". That's stupid. I agree we are wasting our time.
      - Smurfix 4y ago
        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-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...) for the reasons why.
        philosopher1234 4y ago
        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.

pkolaczk 4y ago

It is easy to learn the concepts, but not actually to use them. It is like with assembly, learning mnemonics is easy, but writing useful programs is a whole lot different story.