My issue is concurrency is so hard. One time tasks don't make sense to make concurrent, b/c migrating from sync to async takes 2-5x longer + higher bug risks and more complexity.
And a lot of concurrency resources just dump a list of tools on you. Just saying "here's a spinlock, here's a monitor, here's a condition variable, here's the definition of Dining Philosophers" is like teaching woodworking by just showing you a bunch of powertools without any explanation of how you make furniture out of them
> b/c migrating from sync to async takes 2-5x longer
I very firmly believe that the future of concurrency is with language features that let you basically “write blocking code and run it in parallel” like fibers/CSP/etc. It’s how I’ve started pushing everyone to write where I work and it’s made everyone so much more comfortable (and error free) at writing things in parallel.
It’s way easier to reason about than async+await/callbacks/etc. It fits with how people thing about sequential programs, and it’s how the operating systems most people use expose concurrency today.
I write a lot of golang now. Golang has the easiest to use concurrency model of any language I've used (js, java, c#, ruby, python), but to perform any task properly, still requires fine-tuning (e.g. how many threads/go-routines do you use per stage in the pipeline?). Implementing a pipeline still adds ~15 additional lines per stage when compared to the sync version.
I push ppl at my job to write concurrent code, but we also work on high traffic systems at slow moving company and its better to do it fast the first time.