3 ms·

I want to write a program that has no mention of concurrency and runs efficiently on clusters anyway. So no threads, fibres, processes, actors, atomic, mutex, c

I want to write a program that has no mention of concurrency and runs efficiently on clusters anyway. So no threads, fibres, processes, actors, atomic, mutex, channels, queues, coroutines. Not in the language nor in a library. Push the concurrency and distribution machinery into the language runtime. Developer can neither see nor influence it. Program just runs faster when put on more parallel hardware. The price appears to be dropping mutation, severely limiting I/O and coming up with a domain independent scheduler for the runtime. So it's expensive but not impossible.

idontwantthis 4y ago
NodeJS sounds pretty close to that. Just ‘await’ anything in parallel and your code appears synchronous. Parallel code would need to be a new node process, so it’s not quite so amazing, but pretty close.
- JonChesterfield 4y ago
  Lots of things claim to be implicitly parallel where they mean 'annotate the parallel parts yourself'. Parallel for, await, callbacks, futures and so forth. I don't want any of that annotation.
goodpoint 4y ago
> Push the concurrency and distribution machinery into the language runtime. Developer can neither see nor influence it. This is completely unworkable. It's based on the assumption that nodes have zero failure rate and networks have zero latency and packet loss and infinite bandwidth. Distributed system programming is hard because you want to control the failure modes of your system as closely as possible. The opposite of hiding it.
- JonChesterfield 4y ago
  It's based on the assumption that node and network failures can be detected (with a performance cost) and unobservably healed around. It's also assuming that the runtime can make a good enough guess at when the ratio of data size to compute time for a task makes distribution profitable. Distributed systems programming is indeed hard. That's why I want it pushed out of my applications.
  - goodpoint 4y ago
    > It's based on the assumption that node and network failures can be detected (with a performance cost) and unobservably healed around. ...which is false, especially on large scale systems. Unmanaged cascading failures are the kind of thing that caused big downtimes in various FAANGs many times. > Distributed systems programming is indeed hard. That's why I want it pushed out of my applications. Companies hire good software and system engineers to do this stuff.
0atman 4y ago
You comment made me think of Rayon, a rust module for upgrading any iterator into a concurrent iterator https://docs.rs/rayon/latest/rayon/iter/ https://docs.rs/rayon/latest/rayon/iter/
melonrusk 4y ago
Wasn't that the way OOP was supposed to work, back before people who didn't get it got their hands on it ? Isolated objects, messaging only, no notion of where the object resided. Just add idempotency guarantees and implicit parallelism for loops, and off you go. I can't think of any language that's actually like this though, so maybe it's harder than it looks.

idontwantthis 4y ago

NodeJS sounds pretty close to that. Just ‘await’ anything in parallel and your code appears synchronous. Parallel code would need to be a new node process, so it’s not quite so amazing, but pretty close.

JonChesterfield 4y ago
Lots of things claim to be implicitly parallel where they mean 'annotate the parallel parts yourself'. Parallel for, await, callbacks, futures and so forth. I don't want any of that annotation.

goodpoint 4y ago

> Push the concurrency and distribution machinery into the language runtime. Developer can neither see nor influence it. This is completely unworkable. It's based on the assumption that nodes have zero failure rate and networks have zero latency and packet loss and infinite bandwidth. Distributed system programming is hard because you want to control the failure modes of your system as closely as possible. The opposite of hiding it.

JonChesterfield 4y ago
It's based on the assumption that node and network failures can be detected (with a performance cost) and unobservably healed around. It's also assuming that the runtime can make a good enough guess at when the ratio of data size to compute time for a task makes distribution profitable. Distributed systems programming is indeed hard. That's why I want it pushed out of my applications.
- goodpoint 4y ago
  > It's based on the assumption that node and network failures can be detected (with a performance cost) and unobservably healed around. ...which is false, especially on large scale systems. Unmanaged cascading failures are the kind of thing that caused big downtimes in various FAANGs many times. > Distributed systems programming is indeed hard. That's why I want it pushed out of my applications. Companies hire good software and system engineers to do this stuff.

0atman 4y ago

You comment made me think of Rayon, a rust module for upgrading any iterator into a concurrent iterator https://docs.rs/rayon/latest/rayon/iter/ https://docs.rs/rayon/latest/rayon/iter/

melonrusk 4y ago

Wasn't that the way OOP was supposed to work, back before people who didn't get it got their hands on it ? Isolated objects, messaging only, no notion of where the object resided. Just add idempotency guarantees and implicit parallelism for loops, and off you go. I can't think of any language that's actually like this though, so maybe it's harder than it looks.