Wing: The Startup Failed, but the Language Has Potential

Winglang was designed as a "programming language for the cloud." Here's a look at how it works, and what its legacy might be as the company behind it closes.

Apr 21st, 2025 7:23am by David Eastman

If “Dev Ops had a baby” wrote Elad Ben-Israel, CEO of Wing Cloud, it would be a combination of infrastructure and runtime code in one language. Wing was a “programming language for the cloud.” I used the past tense here, because Wing shutdown a week ago. As it was an open source project, the ideas will hopefully live on, just not as a business concern. I talked a bit about developer experience last week and how it is viewed through the corporate Panopticon. Making developers happy may not always be something you can afford to pay for, so tooling sometimes has an uphill struggle to be taken on board. The same group of people who develop an idea may also successfully work out the right business case, but a close look at startups over the decades will reveal that the forerunner to success is often many rounds of failure. In this post, I’ll look at Wing as a language and product, reflecting on what the shutdown might mean.

Between Kubernetes and Serverless

So where was Wing positioned? I normally look at languages as they appear, not as they retreat, but we should be able to learn something as we use it. Working in the cloud is either a case of container manipulation with Kubernetes, or the very exposed world of serverless functions. I can understand that neither of these two extremes may feel like the best place to work, or express business concerns. To express both infrastructure and application logic in a type-safe model, Wing has two execution phases: “preflight” for infrastructure definitions and “inflight” for runtime code. We’ll see these in action shortly. I think modeling the platform is an interesting direction, and can be contrasted with System Initiative, which also encompasses the architecture of the cloud, but visually. In fact, the comparison with System Initiative is unavoidable when looking at the Wing Console.

Taking Off

I’m going to try starting a project in what I hope will be more than just archaeology. (There was a playground option, but that does appear to be down at the moment), I installed the npm and confirmed the version:

Then I started a new empty project:

This gives us a nice bit of how-to with further links. We have only three files to consider in the project:

And we start by placing the example code into the main.w file:

bring cloud; 

// define a queue, a bucket and a counter 
let bucket = new cloud.Bucket(); 
let counter = new cloud.Counter(initial: 1); 
let queue = new cloud.Queue(); 

// When a message is received in the queue it should be consumed 
// by the following closure 
queue.setConsumer(inflight (message: str) => { 
  // Increment the distributed counter, the index variable will 
  // store the value prior to the increment 
  let index = counter.inc(); 

  // Once two messages are pushed to the queue, e.g. "Wing" and "Queue". 
  // Two files will be created: 
  // - wing-1.txt with "Hello Wing" 
  // - wing-2.txt with "Hello Queue" 
  bucket.put("wing-{index}.txt", "Hello, {message}"); 
  log("file wing-{index}.txt created"); 
});

So we are introduced more directly with the “preflight” code, which creates a bucket, a queue and a counter in whichever cloud fabric we are in; then “inflight” code is used to increment the counter and fill the bucket. At this point, some developers will hear alarm bells ringing. When writing code that will be run at different times, we know we will have the issue of objects that are not alive simultaneously attempting to interact with each other in code. Then again, there have been various parallel paradigms in software for some considerable time now. Now, Wing doesn’t ignore this; it refers to “lifted” when an inflight object attempts to communicate with preflight. In this example, the compiler is clearly happy about the continuing use of the string preflight_str:

let preflight_str = "hello from preflight"; 
inflight () => {
  log(preflight_str); // `preflight_str` is "lifted" into inflight.
};

In fact in main.w, bucket has been lifted via that put method. Well, I’m already ready to run that Wing Console. It starts up at port 3001:

Before starting, we do need to log in with Google or, inevitably, GitHub. Then the console is loaded:

This is actually a bit nicer than the diagram of the console in the docs. This is nice live and hot-loading page. We can operate the functions using the diagram. First, we can push a message. By hitting the queue, we get some UI to enter text and push:

We can now click the bucket, and check the message file was created, with the greetings content, which it was:

And yes, the counter is incremented too:

The idea is that you can then deploy this to the cloud. Just like with System Initiative, this means AWS at the moment. A message tells us that Azure and Google were to follow:

But I guess this will fall by the wayside unless the community picks up the work. I looked on the Discord, but the news of the business having closed down is still fresh, and no evidence of any recovery was visible.

Conclusion

“Choosing between Kubernetes and serverless isn’t the future,” as Ben-Israel wrote in The New Stack a year ago, but it clearly will be for a bit longer. The current cloud native concepts remain hard to grasp and tame, even though Wing had a good try. The Final words go to Adam Jacob, the CEO of System Initiative: “Wing had many promising aspects and was a truly original take. They should be proud of what they built. I’m proud of them for being in the game, for being original, and being really lovely people at every step. Wing was filled with good ideas. Cool technology. Sometimes this is just how it goes.”

David has been a London-based professional software developer with Oracle Corp. and British Telecom, and a consultant helping teams work in a more agile fashion. He wrote a book on UI design and has been writing technical articles ever since....