This is awesome! I’ll need to spend more time digging in later. So you persist funding state, can send state over the wire to be continued elsewhere, and can run processes in parallel. So this can be a distributed runtime? Decentralized HPC could work well with this design…

Thinking more in this: since functions treat memory and storage interchangeably and can be restarted at arbitrary points then does state have timestamps as a first class citizen? Meaning: if my function is sensitive to data freshness then can I easily discern fresh from stale?

Yes! Well, more or less, but mostly yes!

From a persisted function’s perspective, there are two sources of data: its own and that which gets submitted from the outside. the function is entirely responsible for the shape of its own data. it can add timestamps to it if it wants but they’re not there by default since there is no default. all of the data coming in from the outside is the result of a “system call” which the persisted function had previously made, but beyond being associated with that system call, there is no metadata associated with it. one such system call you can make is to ask for the current time. we try to do as little as possible in the runtime. anything which can be offered using software inside the system, should be. what you’re describing could be a library. though i suspect that i don’t exactly get what you’re saying with fresh vs stale. my first thought is that if you’re concerned with this, you should ask your data sources to tag their data with time or sequence numbers, or do so yourself at insertion. but the data that we insert might not come from the outside, we could for example discard the input and update our state by simply incrementing it by one, or something. should the new state have the same timestamp as the input, or as the previous state?