Comment by josephg

> Once you write enough code, you'll realize you need synchronization primitives for async code as well. In pretty much the same cases as threaded code.

I've been programming for 30 years, including over a decade in JS. You need sync primitives in JS sometimes, but they're trivial to write in javascript because the code is run single threaded and there's no preemption.

> What you're trying to do may require IO

Its usually possible to factor your code in a way that separates business logic and IO. Then you can make your business logic all completely synchronous.

Interleaving IO and logic is a code smell.

> The Promise static methods (any, all, race, etc) are particularly useful. But, you could implement that for threads. I believe that this convenience difference is more due to modernity, of the threading model being, what 40, 50, 60 years old, and given a clean-ish slate to build a new model, modern language designers did better.

Then why don't see any better designs amongst modern languages?

New languages have an opportunity to add newer, better threading primitives. Yet, its almost always the same stuff: Atomics, mutexes and semaphores. Even Rust uses the same primitives, just with a borrow checker this time. Arguably message passing (erlang, go) is better. But Go still has shared mutable memory and mutexes in its sync library.

> But it raises the idea: if we rethought OS-level preemptible concurrency today (don't call it threads!), could we modernize it and do better even than async?

I'd love to see some thought put into this. Threading doesn't seem like a winner to me.