It doesn’t support global state. Instead you’d write a “process” that’d respond to requests with the state at time of request. Another request could mutate the state, but each request is processed one at a time. So a “bucket” type data store (object store etc) would likely be implemented as “server” that returns the state. If the objects were large you could pass a URL/handle to the file which you’d retrieve later.
These processes/servers/whatever are running inside the language VM and are SUPER lightweight. Multiple language VMs can be tied together so the actual processes can be distributed across a fleet of physical hosts in a data center - this would be transparent to how you write the code.
If you wanted to implement that in native AWS primitives you’d probably run a lambda function to transform an http request into a S3 bucket address, then you’d go and make an s3 request to download/modify the file. Or the lambda would make some modifications to the file.
So, that’s the prior art on a hypothetical distributed language handling global state, which fwiw is basically how “cloud” systems work today.
This is how we think about this too. Applications that use the cloud use a new kind of "computer" which have different characteristics than the model of a computer exposed by existing programming languages. There are some unique invariants and language constructs that cannot be implemented libraries.
The first of these unique primitives is what we call "inflight functions". You can think of `inflight` as "remote `async`". They are async functions that can be executed on a remote system (such as inside a container fleet or on a FaaS). Inflight functions can interact naturally with cloud resources around them (by simply calling `inflight` methods on the resources such as `bucket.put()`).
Interaction of inflight functions with the outside world poses a unique set of invariants. Currently inflight code can reference immutable serializable data and call `inflight` methods of resources defined outside that closure.
The compiler then analyses these interactions and inverts the control over to the resources to take care of the mechanics like wiring deployment information, synthesizing security policies and anything else that can be deduced from this high level intent.
Defining the cloud architecture of the app and being able to naturally crossing these distributed boundaries is the essence of what we call "cloud-oriented programming", and where we think a lot of the friction and pain of the cloud comes from today: every time I need to interact with "The Cloud", I leave the safety and comfort of my compiler, and I am out in the wild having to understand all the mechanics and layers involved.
Almost all existing languages/compilers take a fundamental assumption that the entire program runs inside a single machine. This is, in our view, the impedance mismatch of cloud development today. This is where we believe language innovation can dramatically reduce the cognitive load and barrier to entry for building and delivering cloud applications that fully take advantage of the cloud. Inflight functions and resources are only the first step. Think first-class support for things like defining and consuming API endpoints, writing distributed workflows, emitting metrics, raising alarms and other things you would expect from your friendly neighborhood cloud programming language.
1. You need to enforce a relatively unique set of invariants, which in turn come with new constructs to interact with them. For example, if you want a system for managing a distributed system, enforcing the lack of global state can be a lot more natural by using a language that cannot express it.
2. You want to provide some sort of novel language construct that cannot be expressed well in existing languages (function argument pattern matching, for example, cannot be retrofitted onto an existing language by a library, maybe by pre-proccessor or sufficiently advanced macro system).