[pdimitar]

I have to admit: if they didn't go overboard with hand-printed cards and carrier pigeons, I'd believe the article.

As others have mused here and I'll join them: we can use a lot more hand-crafted and "slow" approach. We're chasing our own tails -- ESPECIALLY in programming! -- and progress is nearly non-existent.

I mean, in 2021, people are still debugging multithreaded shared state problems. These should belong to the past -- make it impossible on a hardware level as a start, then the programming languages will adapt in a matter of a few months at the maximum.

[swiley]

Shared state is fundamentally hard. I don't think you can make it bullet-proof at the hardware level without sacrificing performance.

[pdimitar]

Exactly because it's fundamentally hard, it must be avoided -- we the humans simply can't be trusted with it (speaking as a former C/C++ dev here).

It should also be hardware-assisted (if it's impossible to stop it at the hardware level). Stuff like atomic counters were a good first step but the state of the art there hasn't moved in a long time (we don't have atomic 512-bit update operations, do we? if we did, a lot of kernel data structures could be atomically updated; this alone would fix a lot of contention problems).

The hardware can also just work in a CRDT/OT-like manner, namely accumulate update requests for a memory location in small queues (that get flushed after 10 nanoseconds or after the mini queue fills up). This could help with a good chunk of the buggy scenarios as well.

Not saying we can make it perfect tomorrow -- of course we can't. What I am saying is that nobody [who can truly make a difference] is even trying.

It gets a bit disappointing and grim after you have been in the profession for a while, you know?

[lanstin]

Switch to go and channels. You won’t have to worry about locking any more, the design of your program becomes a data flow design issue. (Speaking as a former C programmer). Hardware takes so long to change but more atomicity would be great, but 8n the meantime go runtime is fast, generally lock less to the per request application code flow, and you use all the cores evenly.

[pdimitar]

Golang's channels and goroutines are only an improvement if you are coming from JS / Python or maybe also suffered complex pthreads bugs in C/C++.

They are an improvement, absolutely, but not a big one.

[swiley]

OT isn't done in hardware because it would be a massive waste of transistors. It would optimize many (possibly even most) software and would just increase cost and power consumption.

[pdimitar]

And constantly reinventing broken wheels in every program isn’t a massive waste of transistors AND electricity?

I get where you’re coming from but that line of thinking got us into that mess in the first place IMO. At one point we should draw a line. Which we still don’t.