3 ms·

It's a core principle. Don't communicate by sharing memory; share memory by communicating. The overuse of Mutex and Lock are from developers bringing alon

It's a core principle. Don't communicate by sharing memory; share memory by communicating. The overuse of Mutex and Lock are from developers bringing along patterns from other language where they are used to communicating via shared memory. So this aspect of the language just doesn't click as well for many people at first. How long it takes you to get it depends on your experience.

hintymad 1y ago
Thanks! What about data structure shared by multiple goroutines? Say, an in-memory cache object? Or do we always have multiple goroutines talk to a dedicated goroutine for the shared value? Would the performance be okay for all use cases? A reason that people use JCTools is that it can easily support hundreds of millions of concurrent reads/writes to its data structures on a 10-year old laptop.
- eikenberry 1y ago
  For things like cache I generally have 2 goroutines communicating with it. One that directs reads and one that directs writes. Using CSP style you can pass the data (by value) through to the cache (or any other CSP style process) without copying and it performs quite well. I've written several high performance systems in this way with great results.
fidotron 1y ago
My experience is a shocking amount of the golang community believe channels are a performance problem for whatever they're doing, and they use mutexes in some misguided effort at optimization. But then I have also encountered Rust people that will look down on Java but had no idea buffered I/O had higher throughput than unbuffered.
- surajrmal 1y ago
  Depending on the situation, channels can absolutely be higher overhead and not worthwhile. Google internally recommends not using them in many situations. Unbuffered IO is a tradeoff. For certain use cases it does help, because throughput isn't everything. I'm sure Buffered is better in the average use case, but that doesn't mean you would never need unbuffered.
  - fidotron 1y ago
    > Depending on the situation, channels can absolutely be higher overhead and not worthwhile. Like streaming arrays one byte at a time through the channel. Such devs just aren't very good, and hear "Google internally recommends not using them in many situations" but jump to inferring that means all of their situations qualify. > but that doesn't mean you would never need unbuffered. Note that this was never claimed.
    - surajrmal 1y ago
      Channels make the most sense when you need to decouple code. The performance differences rarely are a bit deal. Most of the time it's unnecessary cognitive overhead. People treat both sides as dogma, but the truth is that you need to be think critically when choosing between the two.

hintymad 1y ago

Thanks! What about data structure shared by multiple goroutines? Say, an in-memory cache object? Or do we always have multiple goroutines talk to a dedicated goroutine for the shared value? Would the performance be okay for all use cases? A reason that people use JCTools is that it can easily support hundreds of millions of concurrent reads/writes to its data structures on a 10-year old laptop.

eikenberry 1y ago
For things like cache I generally have 2 goroutines communicating with it. One that directs reads and one that directs writes. Using CSP style you can pass the data (by value) through to the cache (or any other CSP style process) without copying and it performs quite well. I've written several high performance systems in this way with great results.

fidotron 1y ago

My experience is a shocking amount of the golang community believe channels are a performance problem for whatever they're doing, and they use mutexes in some misguided effort at optimization. But then I have also encountered Rust people that will look down on Java but had no idea buffered I/O had higher throughput than unbuffered.

surajrmal 1y ago
Depending on the situation, channels can absolutely be higher overhead and not worthwhile. Google internally recommends not using them in many situations. Unbuffered IO is a tradeoff. For certain use cases it does help, because throughput isn't everything. I'm sure Buffered is better in the average use case, but that doesn't mean you would never need unbuffered.
- fidotron 1y ago
  > Depending on the situation, channels can absolutely be higher overhead and not worthwhile. Like streaming arrays one byte at a time through the channel. Such devs just aren't very good, and hear "Google internally recommends not using them in many situations" but jump to inferring that means all of their situations qualify. > but that doesn't mean you would never need unbuffered. Note that this was never claimed.
  - surajrmal 1y ago
    Channels make the most sense when you need to decouple code. The performance differences rarely are a bit deal. Most of the time it's unnecessary cognitive overhead. People treat both sides as dogma, but the truth is that you need to be think critically when choosing between the two.