3 ms·

[flagged]

speedgoose 11mo ago
I assume you are aware of "the billion dollar mistake" from Tony Hoare?
landr0id 11mo ago
First sentence: >I have been writing production applications in Go for a few years now. I like some aspects of Go. One aspect I do not like is how easy it is to create data races in Go. Their examples don't seem terribly convoluted to me. In fact, Uber's blog post is quite similar: https://www.uber.com/blog/data-race-patterns-in-go/ https://www.uber.com/blog/data-race-patterns-in-go/
kryptiskt 11mo ago
To me it looks like simple, clear examples of potential issues. It's unfortunate to frame that as "crapping on Go", how are new Go programmers going to learn about the pitfalls if all discussion of them are seen as hostility? Like, rightly or wrongly, Go chose pervasive mutability and shared memory, it inevitably comes with drawbacks. Pretending they don't exist doesn't make them go away.
- bayindirh 10mo ago
  > Pretending they don't exist doesn't make them go away. It's generally assumed that people who defend their favorite programming language are oblivious to the problems the language has or choose to ignore these problems to cope with the language. There's another possibility: Knowing the footguns and how to avoid them well. This is generally prevalent in (Go/C/C++) vs. Rust discussions. I for one know the footguns, I know how bad it can be, and I know how to avoid them. Liking a programming language as is, operating within its safe-envelope and pushing this envelope with intent and care is not a bad thing. It's akin to saying that using a katana is bad because you can cut yourself. We know, we accept, we like the operating envelope of the languages we use. These are tools, and no tool is perfect. Using a tool knowing its modus operandi is not "pretending the problems don't exist".
  - bloppe 10mo ago
    While I agree with you in principle, there is a small but important caveat about large codebases with hundreds of contributors or more. It only takes 1 bad apple to ruin the bunch. I'll always love a greenfield C project, though!
  - kryptiskt 10mo ago
    > Using a tool knowing its modus operandi is not "pretending the problems don't exist". I said that in response to the hostility ("crap on Go") towards the article. If such articles aren't written, how will newbies learn about the pitfalls in the first place?
- bloppe 10mo ago
  Go famously summed up their preferred approach to shared state: > Don't communicate by sharing memory; share memory by communicating.
  - dontlaugh 10mo ago
    Which they then failed to follow, especially since goroutines share memory with each other.
    - bayindirh 10mo ago
      Threads share the same memory by definition, though. When you isolate these threads from a memory PoV, they become processes. Moreover, threads are arguably useless without shared memory anyway. A thread is invoked to work on the same data structure with multiple "affectors". Coordination of these affectors is up to you. Atomics, locks, queues... The tools are many. In fact, processes are just threads which are isolated from each other, and this isolation is enforced by the processor.
      - dontlaugh 10mo ago
        Goroutines aren't posix threads. They could've lacked shared memory by default, which could be enforced by a combination of the compiler and runtime like with Erlang.
    - bloppe 10mo ago
      Who is "they"? This isn't Rust. It's still up to the developer to follow the advice. Anyway, I would stop short of saying "Go chose shared memory". They've always been clear that that's plan B.
      - dontlaugh 10mo ago
        Go's creators said "Don't communicate by sharing memory", but then designed goroutines to do exactly that. It's quite hard to not share memory by accident, actually. It's not like it's a disaster, but it's certainly inconsistent.
- marhee 10mo ago
  Concurrent programming is hard and has many pitfalls; people are warned about this from the very, very start. If you then go about it without studying proper usage/common pitfalls and do not use (very) defensive coding practices (violated by all examples) then the main issue is just naivity. No programming language can really defend against that.
  - gf000 10mo ago
    You are completely dismissing language design. Also, these are minimal reproducers, the exact same mistakes can trivially happen in larger codebases across multiple files, where you wouldn't notice them immediately.
  - LtWorf 10mo ago
    The whole point of not using C is that such pitfalls shouldn't compile in other languages.
littlestymaar 10mo ago
During the short time I was working on a Go project I spent a significant amount of time debugging an issue like the one described in his first example in a library we depended on, so it's definitely not a problem of “super convoluted example”.

[flagged]

I assume you are aware of "the billion dollar mistake" from Tony Hoare?

First sentence: >I have been writing production applications in Go for a few years now. I like some aspects of Go. One aspect I do not like is how easy it is to create data races in Go. Their examples don't seem terribly convoluted to me. In fact, Uber's blog post is quite similar: https://www.uber.com/blog/data-race-patterns-in-go/ https://www.uber.com/blog/data-race-patterns-in-go/

kryptiskt 11mo ago

To me it looks like simple, clear examples of potential issues. It's unfortunate to frame that as "crapping on Go", how are new Go programmers going to learn about the pitfalls if all discussion of them are seen as hostility? Like, rightly or wrongly, Go chose pervasive mutability and shared memory, it inevitably comes with drawbacks. Pretending they don't exist doesn't make them go away.

bayindirh 10mo ago
> Pretending they don't exist doesn't make them go away. It's generally assumed that people who defend their favorite programming language are oblivious to the problems the language has or choose to ignore these problems to cope with the language. There's another possibility: Knowing the footguns and how to avoid them well. This is generally prevalent in (Go/C/C++) vs. Rust discussions. I for one know the footguns, I know how bad it can be, and I know how to avoid them. Liking a programming language as is, operating within its safe-envelope and pushing this envelope with intent and care is not a bad thing. It's akin to saying that using a katana is bad because you can cut yourself. We know, we accept, we like the operating envelope of the languages we use. These are tools, and no tool is perfect. Using a tool knowing its modus operandi is not "pretending the problems don't exist".
- bloppe 10mo ago
  While I agree with you in principle, there is a small but important caveat about large codebases with hundreds of contributors or more. It only takes 1 bad apple to ruin the bunch. I'll always love a greenfield C project, though!
- kryptiskt 10mo ago
  > Using a tool knowing its modus operandi is not "pretending the problems don't exist". I said that in response to the hostility ("crap on Go") towards the article. If such articles aren't written, how will newbies learn about the pitfalls in the first place?
bloppe 10mo ago
Go famously summed up their preferred approach to shared state: > Don't communicate by sharing memory; share memory by communicating.
- dontlaugh 10mo ago
  Which they then failed to follow, especially since goroutines share memory with each other.
  - bayindirh 10mo ago
    Threads share the same memory by definition, though. When you isolate these threads from a memory PoV, they become processes. Moreover, threads are arguably useless without shared memory anyway. A thread is invoked to work on the same data structure with multiple "affectors". Coordination of these affectors is up to you. Atomics, locks, queues... The tools are many. In fact, processes are just threads which are isolated from each other, and this isolation is enforced by the processor.
    - dontlaugh 10mo ago
      Goroutines aren't posix threads. They could've lacked shared memory by default, which could be enforced by a combination of the compiler and runtime like with Erlang.
  - bloppe 10mo ago
    Who is "they"? This isn't Rust. It's still up to the developer to follow the advice. Anyway, I would stop short of saying "Go chose shared memory". They've always been clear that that's plan B.
    - dontlaugh 10mo ago
      Go's creators said "Don't communicate by sharing memory", but then designed goroutines to do exactly that. It's quite hard to not share memory by accident, actually. It's not like it's a disaster, but it's certainly inconsistent.
marhee 10mo ago
Concurrent programming is hard and has many pitfalls; people are warned about this from the very, very start. If you then go about it without studying proper usage/common pitfalls and do not use (very) defensive coding practices (violated by all examples) then the main issue is just naivity. No programming language can really defend against that.
- gf000 10mo ago
  You are completely dismissing language design. Also, these are minimal reproducers, the exact same mistakes can trivially happen in larger codebases across multiple files, where you wouldn't notice them immediately.
- LtWorf 10mo ago
  The whole point of not using C is that such pitfalls shouldn't compile in other languages.

littlestymaar 10mo ago

During the short time I was working on a Go project I spent a significant amount of time debugging an issue like the one described in his first example in a library we depended on, so it's definitely not a problem of “super convoluted example”.