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.
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.