For discussion...The face of hardware is vastly different than it was in the 1950s and as it was in the early days of computer-ing, when concepts like programming languages and operating systems were invented. I think that this means re-imagining how we use what we've got, instead of just tweaking what we've got. It augments the meaning of "programming". To start things off, here are some thoughts: https://open.substack.com/pub/programmingsimplicity/p/the-future-of-programming?r=1egdky&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

Routing must be performed in an atomic manner to avoid possible interleaving of messages from other places.

Containers must process each message to completion before inhaling another message.

I think this might answer my long-standing question about timing. So if a component has two input ports, there's no automatic way to consume from both in parallel?

I think this might answer my long-standing question about timing. So if a component has two input ports, there's no automatic way to consume from both in parallel?

Correct. I believe that this kind of thing is an Architectural decision and should not be built in under-the-hood into the tools. Components can have multiple input ports. The tool only guarantees that the inputs are queued up in order of arrival. The Architect decides what to do about the inputs. Further... multi-processing is essentially a fiction in FP. ... Further... there is exactly one "race condition" in reality. ... https://programmingsimplicity.substack.com/p/multiple-input-ports-only-one-input?r=1egdky