Well there exists a language today meant for distributed systems (erlang, elixir).

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.

I am aware of prior art in distributed systems. My point was that being able to enforce certain guarantees is likely impossible, i.e. your use case of global state prevention. Working with global state and making it easier is a different goal with different tradeoffs

Erlang and Elixir both do not have any way to express a global variable, or even a variable that can be accessed by two different processes (green threads, lighter than OS processes). All inter-process communication happens through messages. It's not checked by the language, there is simply no way to express the concept in the language itself.