eladbenisrael

> can’t you already do this today with GCP and AWS and more generally a wealth of Docker images and Kub/Knative?

not really.. as soon as you need cloud resources that are not in your k8s cluster, you end up with the cloud in your development loop.

> what about the package ecosystem?

wing has interoperability with the npm ecosystem, so basically any node package can be used quite easily from winglang code.

on the infra side, there’s interoperability with the CDK for terraform ecosystem.

Yap, all inflight code is async by default.

(elad, winglang maintainer here)

i like this observation - it's not uncommon for patterns to turn into language primitives when they end up becoming a very common thing in your language.

this is reflected both in wing as a language but also in the fact that wing's preflight phase in a sense is a programming model for turning infrastructure patterns into composable components.

Actually I really love C++ :-) Just spent some time at Core C++ in Tel-Aviv and was so inspired by the community and depth and incredible innovation that's still happening around this language.

But there's actually a specific technical reason why we realized we need a new language: it's because cloud systems are distributed. They are a composition of both infrastructure and application code. Not just one of them.

Existing languages (including my beloved C++) have a fundamental assumption that a program is executed on a single machine. This means that whenever you exit the machine boundary (e.g. call a service), the compiler basically says adios and leaves the room. Now the onus is on the developer to stitch the components together.

And that happens A LOT in the cloud. More and more as you transfer responsibilities from your application code to managed services. Isn't that what the cloud is all about?

The power of compilation is the safety you get from linking decoupled components together. This is exactly what it's doing for "traditional computers" today. Two functions in memory are effectively decoupled (they are just two sequences of opcodes in memory). And so compilers and linkers were invented to check that when I call function A from function B I give it the right number and type of arguments at a very very early stage.

Elad here (the author). That's a very good point. If a developer decides to use `bucket.list().filter(x => x == myFile)` instead of `bucket.get(myFile)` the result will be fundamentally different both from a security perspective (e.g. `ListObjects` instead of `GetObject` on AWS), but also from a performance perspective (`list` is O(n) but `get` is O(1)).

If you think about this is primarily an issue of software engineering quality. The fact that today we are forcing the developer to go their devops team to request these permissions creates an organizational workflow that increases quality. That's why most of the teams I worked at requires code reviews.

I believe the right approach is to enable devops teams to put up boundaries and rules that will get enforced downstream (build => deployment => production). This will allow both developers and devops teams to be be more independent but still be in control.

Curious what people think about winglang's compiler plugin system as a way to help streamline these boundaries (https://www.winglang.io/docs/tools/compiler-plugins).

Elad here (I am the author). Happy to answer any questions and dive deeper. Feel free to ask me anything.

We also have a bunch of weird videos on YouTube with tons of geeking out and sharing our progress on YouTube https://youtube.com/@winglangio

(I am from the Wing team)

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.

[Wing team member here]

Wing has a concept of `inflight` which you can think of as a "remote async function". It's an `async` function 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 e.g. `bucket.put()`). The compiler 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.