What an epic premise. Blow up the app server processes! I agree so much.

Just creating a promise in JavaScript reminds me so much of creating a process. It's something off out there that will run for a while, and come back with a return code.

In WHATWG Fetch, the notion of the promise as process is enhanced & extended by having signalling attached to the promise, that can be used to signal presently an abort of status. There's been longstanding desire to have fetch also have observability, of upload progress and http2/3 push streams.

I really really like the idea of decomposing the app. Making a lot of smaller processes. If processes are small, and have known state, it also feels like the other key ideas here of having processes be mobile ambients, being able to be run wherever, is also within grasp.

The team here seems to have made their own basically distributed OS for running their proclets. Proclets feel a lot like actor, each with their own heap & threads. They also get access to some read-only bulk data, shared among proclets. Everyone uses message passing. Yup sounds like an actor based system like Erlang or Orleans or whatever so far! One cool trick is they allow proclets to send each other functions; here's my addMoney function or whatever, that the other proclets can call; rpc of a sort, but these can pass smart pointers around too (kind of like capnproto's promise pipelining).

I do wonder how much of this is achievable with regular processes, and what that would look like. Checkpoint-restore is a good way to save regular program state, but Nu has special abstractions for io of course. Mungling with sockets and file handles when restoring from criu is beyond my pay grade ATM. A key insight right here, this work is I think approximately 9 million times easier with stateless protocols like quic & http3, near to a no-op (the autonomic layer/coordinator/operator would need to aim the ipv6 address on the network first). Ideally we'd want other criu tweaks: don't serialize the read only memory when checkpointing but re-map it in from a common pool while restoring. But like, this seems imminently doable directly on the OS, as processes, with a smart workflow-cooridnator