[thoughtFrame]

What bothers me is that I don't know how to squeeze all of the juice out of my CPU (or any programmable device for that matter). I see instances of the Jevons effect everywhere (e.g. the use of Electron), and on the other side I see DOS-era programmers whose experience transfer really well to more modern machines, so they know how to get the best throughput on their data, how to isolate slow but necessary parts of their programs (like certain OS APIs). I feel like having started programming on a high level language affected the way I program even in lower level languages, so I don't know how to do better resource utilization, or how to do I/O efficiently.

So I don't have a problem with, say, writing a script in Python even though it's not the most efficient use of my CPU, because I'm just looking to get things done. But when I have a problem that needs horsepower (and I know my 8 core 3.6 GHz can absolutely deliver that), I don't know how to tell it to do it. It doesn't help that many programmers' first thought would be to go for the cloud, when a single computer can be much faster than a bunch of AWS VMs

Another example is the .kkrieger demo, which seems like wizardry when you've only seen similar things done in Unity/Unreal

[itake]

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.

So most tasks remain inefficient...

[thoughtFrame]

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

[itake]

I really liked golang's blog on pipelines:

https://go.dev/blog/pipelines

[vineyardmike]

> 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.

[itake]

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.