4 ms·

>Something like threading race conditions is a real problem, but not easy to fix. It is. It's called channels.

• dilap 10y ago
  Sure, you could only use channels and you'd never get races, but in practice that'd be unwieldy and slow, which is why people write traditional lock-based sync stuff in Go all the time, and depend on old-fashioned debugging (and the race-checker). Rust really fixes this (with its ownership system), but it wasn't easy.
  • dispose13432 10y ago
    >unwieldy and slow So force one to do it consciously (kind of like unsafe).
  • masklinn 10y ago
    > Sure, you could only use channels and you'd never get races Go allows sending pointers to non-locked structures over channels, so it's quite easy to "only use channels" and still get race. You can also hit that issue if you spawn multiple goroutines sharing the same initial lexical environment if they make use of a mutable structure from that environment.
    • dilap 10y ago
      If you're accessing mutable data from multiple goroutines, then you're not only using channels! :)
      • masklinn 10y ago
        Of course you are. Go has essentially no support for immutable data structures, and even if you send large structures by value (which can get expensive) they themselves probably embed pointers to mutable data, and you're back at square one.
        • dilap 10y ago
          I didn't say it was a good idea (in fact, if you read far enough back up the comment chain, you'll see I was saying it's a bad idea), but you could, if you wanted to, restrict yourself to only communicating between goroutines via channels of immutable data and be confident that your code had no data races.