I think it really depends on the project/application. More often than not you should probably have a framework for handling concurrency (whether you've written it yourself or someone else), sure. But sometimes you find yourself writing/maintaining the framework, too.
I've experienced times where, when writing concurrent code, I thought what I should be doing was okay because I would have done the same thing in C but Rust stepped in and said "actually I can't allow you to do that, Dave". I don't know if you've ever experienced something similar but it's pretty awesome when it happens.
I don't disagree, TBH I find stuff like memory models kind of mind bending. Concurrency is easy to get wrong, that's why it might be best to avoid (centralize) it. That's what Golang did I think.
I'm not up to date with a lot of the high-tech SMP stuff that is found in e.g. Linux - I'm sure they have a lot of direct memory sharing, I found sth in their Red-black tree for example, and for sure there a lot of spinlocks, schedule calls, and what not. I wonder if there has been a trend of turning back the explicit-synchronization dial a little, even there? It would make sense to me, memory has been becoming slower and slower (in terms of latency not performance, and relative to increasing CPU throughput), and there seems to be a trend for more asynchronous (non-blocking, message passing) stuff like io_uring.
Could you explain a bit more about how you see Golang improving this?
For me, Go is trickier to use concurrently than Rust, and requires keeping track of more details you need to manage yourself without compiler assistance or checking.
For example, the default data structures like Map are not thread-safe, but you'll only discover that you've used a Map from multiple threads without synchronization when you actually have a concurrent modification at runtime, which might not show up at low load during testing.
You're also responsible for explicitly locking (and unlocking) any synchronization primitives before accessing a synchronized resource, and ensuring you don't hold any references to synchronized data past the unlock.
With Rust, this is all encoded in the APIs, and verified by either the type checker or the borrow checker.
Since I need to deal with Golang at work, I've been trying to get less frustrated with it, so I'm really interested in hearing perspectives about what people appreciate about Golang, or what it does right or does well.
In practice, in my experience at least, pure channel implementations are rare. It's rather hard to do (although I'll admit that was one of the most fun things for me about Go: "how can I solve this problem purely using channels?"). Sadly much Go code is far from the mantra. I've even heard seasoned Go programmers pass along the "wisdom" if you're using channels you're doing it wrong" (implying you haven't built the correct abstraction). Most Go I've encountered sadly uses shared memory and waitgroups and run_once. I think there are performance reasons for this too or something "channels are slow".
I've experienced times where, when writing concurrent code, I thought what I should be doing was okay because I would have done the same thing in C but Rust stepped in and said "actually I can't allow you to do that, Dave". I don't know if you've ever experienced something similar but it's pretty awesome when it happens.