4 ms·

> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), Java's tools are really top notch. Using IntelliJ for Java feels a whole new diffe

> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages. Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on writing concurrency code is to use Java's amazing containers. Sometimes, I do miss the java.util.concurrent and JCTools.

zwnow 1y ago
Just implement concurrency with actors and u save up on some locks and mutexes... The patterns are available, its up to the community to apply proper concurrency patterns.
- paulddraper 1y ago
  The x86 instruction set is available as well.
- PaulDavisThe1st 1y ago
  The only replacement for locks/mutexes is a lock free data structure. Locks are not what make concurrency possible, they are what makes it data-safe. You can use platform threads, user-space threads, language-provided "green" threads, goroutines, continuations or whatever you wish for concurrency management, but that's almost orthogonal to data safety.
  - MaxBarraclough 1y ago
    I'm not sure what you mean here, as far as I'm aware data safety isn't standard terminology.
    - lazide 1y ago
      I think they’re using it in the context of what you’ll get without some degree of locking, which is data corruption and/or other issues. It’s not that you need locking to use threads. You need locking to stop threads from ruining any shared resource/data they are both trying to touch at the same time.
- saagarjha 1y ago
  Actors are implemented using locks.
  - pimeys 1y ago
    Is it really so? I haven't checked all the implementations, but my take here would be to use a channel with atomics instead of a lock...
    - saagarjha 1y ago
      It's probably possible to do if you think about it carefully but generally enqueuing a message is going to take a lock, especially if you can send an arbitrary number of messages (which may require the queue to be reallocated).
      - pimeys 1y ago
        One very common queue implementation you can use to implement actors is the crossbeam-deque. It's work-stealing in nature, works in multi-threaded environments and has no locks. The implementation is quite simple to follow: https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-deque/src/deque.rs https://github.com/crossbeam-rs/crossbeam/blob/master/crossb...
        surajrmal 1y ago
        Note that the mpsc queue in the rust stdlib is also a clone of crossbeam and therefore also lockless.
        saagarjha 1y ago
        Oh, interesting. Ok I take back my claim then.
        yubblegum 1y ago
        > One very common queue implementation you can use to implement actors is the crossbeam-deque I can't find any references to a "crossbeam dequeue" outside of Rust sources. Is this a neologism for a "very common" pattern, or just very common in Rust?
eikenberry 1y ago
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.
shanemhansen 1y ago
I'll offer a counterpoint to the responses. Until go got generics, concurrent data structures were awkward. The stdlib now does include things like sync.Map. In fact my experience has been that overuse of channels is a code smell that alot of new go developers fall into and later regret. There's a reason the log package uses a mutex for synchronization. In general I think channels are great for connecting a few large chunks of your program together. Concurrency is great but also not every function call benefits from being turned into a distributed system. I think that it would be a great idea to develop more concurrent go data structures with generics and I suspect inertia is what's keeping the community from doing it. My credentials such as the are: been writing go since 1.0. worked at Google and taught go classes as well as owned some of the original go services (the downloads server aka payload server).
- hintymad 1y ago
  Yeah, even with channels and goroutines, I’d imagine we can encapsulate them as primitives in containers like concurrency literatures often advocate. Case in point, it was fun to go through Pike’s talk Go Concurrency Patterns, yet I’m not sure all the patterns he discussed in the talk would be that simple to implement compared to just declaratively using well-packed containers
- int_19h 1y ago
  Not just generics, but also a way to generalize iteration (i.e. the equivalent of Java iterators). Which Go has only got even more recently than generics.
deleted 1y ago
[deleted]

zwnow 1y ago

Just implement concurrency with actors and u save up on some locks and mutexes... The patterns are available, its up to the community to apply proper concurrency patterns.

paulddraper 1y ago
The x86 instruction set is available as well.
PaulDavisThe1st 1y ago
The only replacement for locks/mutexes is a lock free data structure. Locks are not what make concurrency possible, they are what makes it data-safe. You can use platform threads, user-space threads, language-provided "green" threads, goroutines, continuations or whatever you wish for concurrency management, but that's almost orthogonal to data safety.
- MaxBarraclough 1y ago
  I'm not sure what you mean here, as far as I'm aware data safety isn't standard terminology.
  - lazide 1y ago
    I think they’re using it in the context of what you’ll get without some degree of locking, which is data corruption and/or other issues. It’s not that you need locking to use threads. You need locking to stop threads from ruining any shared resource/data they are both trying to touch at the same time.
saagarjha 1y ago
Actors are implemented using locks.
- pimeys 1y ago
  Is it really so? I haven't checked all the implementations, but my take here would be to use a channel with atomics instead of a lock...
  - saagarjha 1y ago
    It's probably possible to do if you think about it carefully but generally enqueuing a message is going to take a lock, especially if you can send an arbitrary number of messages (which may require the queue to be reallocated).
    - pimeys 1y ago
      One very common queue implementation you can use to implement actors is the crossbeam-deque. It's work-stealing in nature, works in multi-threaded environments and has no locks. The implementation is quite simple to follow: https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-deque/src/deque.rs https://github.com/crossbeam-rs/crossbeam/blob/master/crossb...
      - surajrmal 1y ago
        Note that the mpsc queue in the rust stdlib is also a clone of crossbeam and therefore also lockless.
      - saagarjha 1y ago
        Oh, interesting. Ok I take back my claim then.
      - yubblegum 1y ago
        > One very common queue implementation you can use to implement actors is the crossbeam-deque I can't find any references to a "crossbeam dequeue" outside of Rust sources. Is this a neologism for a "very common" pattern, or just very common in Rust?

eikenberry 1y ago

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.

shanemhansen 1y ago

I'll offer a counterpoint to the responses. Until go got generics, concurrent data structures were awkward. The stdlib now does include things like sync.Map. In fact my experience has been that overuse of channels is a code smell that alot of new go developers fall into and later regret. There's a reason the log package uses a mutex for synchronization. In general I think channels are great for connecting a few large chunks of your program together. Concurrency is great but also not every function call benefits from being turned into a distributed system. I think that it would be a great idea to develop more concurrent go data structures with generics and I suspect inertia is what's keeping the community from doing it. My credentials such as the are: been writing go since 1.0. worked at Google and taught go classes as well as owned some of the original go services (the downloads server aka payload server).

hintymad 1y ago
Yeah, even with channels and goroutines, I’d imagine we can encapsulate them as primitives in containers like concurrency literatures often advocate. Case in point, it was fun to go through Pike’s talk Go Concurrency Patterns, yet I’m not sure all the patterns he discussed in the talk would be that simple to implement compared to just declaratively using well-packed containers
int_19h 1y ago
Not just generics, but also a way to generalize iteration (i.e. the equivalent of Java iterators). Which Go has only got even more recently than generics.

deleted 1y ago

[deleted]