Personally, I find the concurrency support quite lacking. Compared to Java/Javascript/Python/etc, it's great, but nothing compared to languages like Ada or Elixir.
I wish we could use more than channels - for me, I often feel like I'm shoehorning them in because there's no support for protected objects (native queues, conditional variables etc).
Perhaps I'm just using them wrong. Sometimes I have to use locks, and I don't think we should be forced to use locks in 2019. We've had better solutions since the 80s.
> Sometimes I have to use locks, and I don't think we should be forced to use locks in 2019. We've had better solutions since the 80s.
Absolutely not. Locks/spinlocks are found in pretty much every significantly parallel software project. It is pretty arrogant to criticize almost all software architectures on earth.
> It is pretty arrogant to criticize almost all software architectures on earth.
Almost all software is programmed with modern languages, which all (imo) have extremely lackluster support for concurrency. It's not a symptom of the programmers, but the tools they work with. Who uses Ada these days?
Locks should only be used when other protection mechanisms are too slow.
Semantically, the critical region protected by a lock is not connected to the lock in any way. This can make debugging races super difficult, and you have to rely on everyone to lock everything at the right point.
Juggling multiple locks in complex concurrent processes is difficult, and prone to bugs.
I struggle to think of where a lock is required, barring the extremely hyperoptimised hot paths within operating systems, or similar applications.
I wish we could use more than channels - for me, I often feel like I'm shoehorning them in because there's no support for protected objects (native queues, conditional variables etc).
Perhaps I'm just using them wrong. Sometimes I have to use locks, and I don't think we should be forced to use locks in 2019. We've had better solutions since the 80s.