Back then you could spend 6 months making something twice as fast, or wait six months for computers to become twice as fast. People obviously did the latter.

It also became a cycle: People write single threaded code -> CPUs/OSs optimize performance/ergonomics for single threaded programs -> People write single threaded code ->...

It wasn't until scaling slowed down that interest/investment in concurrency/parallelism took off.

That's because they are very rarely useful. This was true then and it's still true now. There's just not many workloads where it makes sense to need to rapidly launch a thread that doesn't need to do much of anything but does need to exist for a while before terminating.

What is useful is the state machine aspects of things like coroutines or async/await, but those aren't quite fibers and very much aren't M:N threading. A major use of them is in UI where they have strict thread requirements even.

Yet the average software engineer hasn’t heard or Carl Hewitt, Joe Armstrong, has never programmed in an Actor Programming model, and dont even know what it is.

Surveillance, got to track you all across the internet.

In Greece (EU). Can’t play it either. I’m getting:

> This video is not rated

> Join vimeo to watch

> Already have an account? Log in

Compliance with the absurd and draconian OSA

Alt link: https://www.youtube.com/watch?v=54EV4dDdLO0

because otherwise how would the queen know what you're up to all the time? :D

The title must have been edited in the last 40min - it shows (2012) now

> concurrency _is_ parallelism, but for I/O.

Not really. They're just separate but related concepts.

E.g. coroutines are a form of concurrency that doesn't have to involve any sort of I/O, you're just taking two logical processes (e.g generating a sequence and consuming it) and abstracting away how they execute relative to each other.

Describing your tasks using the language of concurrency is a requirement for process-based parallelism (multiple CPUs/cores), but data-level parallelism (SIMD) is a form of parallelism that doesn't involve concurrency either.

No, and that's the point of the article. What you are calling parallel w/r/t IO should be called concurrency (conceptually happening at the same time by virtue of being able to interrupt and resume units of work). The reason IO APIs like you've described is concurrent but not necessqrily parallel is because there is no guarantee in the API that they both happen literally simultaneously; I could build a JS runtime that "works" for all the code written against XMLHTTPRequest (ignoring side-effects) but which under the hood only ever makes one HTTP request at a time. And because I can do that, that means JS code is living in a concurrency-only world, even though as an implementation detail most runtimes support parallel execution of those concurrent operations.