Winglang: is it the new language for cloud computing?

Those who build software in the cloud have already understood the good part: ready-made services, on-demand scaling, observability, and data everywhere. The difficult part usually appears in day-to-day operations. The same timespan that writes product code needs to declare infrastructure, adjust permissions, reconcile different tools, and still maintain a quick testing cycle. And this happens in a scenario where multi-cloud has already become a reality for most companies. 

Winglang appears as a technical answer to this kind of friction: treating the cloud as the “target computer” of the software, as if queues, buckets, and functions were parts of the runtime and not just resources declared outside the code. The idea is promising, but it is not neutral. Like any choice of language and delivery model, it involves gains and trade-offs that need to fit the team’s reality and, most importantly, the business strategy. 

In this article, we discuss the concept of Winglang, its benefits, risks, and what its emergence reveals about the future. Happy reading! 

What is Winglang?

Winglang is an open source programming language created specifically for cloud development.

The premise of the language is to unify, in a single programming model, infrastructure code and runtime code. Instead of writing Terraform or CloudFormation separately from the application code, the developer writes everything together in Wing. The compiler translates this into deploy-ready packages with infrastructure definitions for Terraform, CloudFormation, or other engines, along with Node.js code prepared to run on AWS Lambda, Kubernetes, or edge platforms.

The language operates with two execution plans: preflight for infrastructure definitions, and inflight for the code that runs at runtime. This allows the compiler to reason about the entire application in an integrated manner.

Differential

The ability to test locally, without a cloud connection, using a functional simulator. For teams that currently wait minutes between each deploy cycle to test a simple change, this represents a concrete speed gain.

What challenges does Winglang help to solve?

The problem that Winglang addresses is not marginal. According to the State of Developer Experience Report 2024, conducted by Atlassian with more than 2,100 developers and engineering leaders globally, 69% of developers lose eight hours or more per week to inefficiencies, with one of the main causes being the increasing complexity of cloud build and deploy stacks.

The 2024 Stack Overflow survey reinforces the diagnosis: complexity of build and deployment stacks appears among developers’ main frustrations, alongside technical debt.

The central knot is the separation between application code and infrastructure code. They are different languages, with different feedback cycles, and responsibilities that overlap without clear ownership. One of the most common challenges reported by software engineers is exactly this blurred boundary between the application and the infrastructure that supports it.

Benefits of using Winglang

Winglang directly solves a problem: it eliminates the boundary. Infrastructure becomes part of the same codebase. The developer works with cloud services as first-class citizens of the language, storage, functions, queues, databases, without having to switch between different tools, configuration files, and paradigms.

There is also the issue of portability. Today, an application written for AWS depends on specific constructions of the AWS ecosystem. Winglang proposes a common API among providers: write once, deploy on any cloud.

When is it worth adopting Winglang?

Winglang makes more sense when there is a pain in the delivery cycle, stemming from the friction between “defining infrastructure” and “writing code”. The project starts from the diagnosis that developing for cloud involves dealing with various layers (network, IAM, tools) and that long deployment times take the developer out of the flow, making iterations slower than they should be. 

Starting a cloud application or slicing a domain into smaller services

Wing was designed to write, in the same code, the “functional” infrastructure and the logic that runs on top of it. The canonical example in the documentation creates a queue, counter, and bucket as preflight objects and connects a consumer inflight that writes messages to the storage. This is important because the compiler understands the whole and can generate part of the “mechanics” that typically turn into manual work in IaC — including IAM policies and other cloud details. 

This fit tends to be more straightforward when the code is born with this model in mind. You are defining boundaries now (a new service, a specific slice of a larger system) and can let the language “hold” the consistency between infrastructure and runtime from the first commit. 

The team struggles to test and debug locally without “bringing everything up” in the cloud

Here, Wing delivers quick value because it comes with a built-in simulator to test applications locally, without needing to provision resources in a cloud provider. The documentation outlines two main forms of interaction: running inflight tests with the command wing test and interacting with the application simulated by the Wing Console. 

The detail that changes productivity is the shortening of the feedback loop. Instead of waiting for a deploy to validate behavior, the team tests and inspects the application while still in development. This gain directly addresses the pain that the project itself cites: long deploy times that hinder iteration. 

Queues, functions, storage, and event-driven integrations

The Wing model revolves around cloud resources as “primitives” of the program. The documentation shows the queue consumption and persistence in bucket pattern as a base example, with the explicit separation between infrastructure configuration and execution code of the consumer. 

In practice, this tends to appear when your product relies on typical components of event-driven and serverless architectures: events, consumers, storage, endpoints, and asynchronous integrations. It is precisely this type of composition that Wing tries to make natural in the daily life of the developer. 

Portability is a requirement

Wing was designed to run on “any cloud,” with an SDK that offers common resources among providers. However, the project itself makes an objective distinction of maturity: if you compile for the simulator, the expectation is to be able to compile for Amazon Web Services with the Terraform engine; while Google Cloud Platform and Microsoft Azure appear as partial support, and not all code that compiles on the simulator compiles for those targets. 

In other words: portability is indeed part of the conversation, but with a very clear design rule. If your roadmap demands multi-cloud “without exception,” you need to validate what is portable today and what is still out of reach. 

When is it worth adopting Winglang in digital transformation strategies?

For João Paulo Miranda, CEO of Objective, the adoption of cloud should not be treated as an exclusively technical decision. According to him, the choice between cloud models: “is much more a strategic definition, with a direct impact on the company’s capacity to grow, innovate, and manage risks.”

This logic applies fully to Winglang. A language that promises to simplify cloud development only makes sense within a larger strategy that defines the adopted cloud model, the technological maturity level of the team, and the business objectives that guide the transformation.

When this strategy is already clear, Winglang can be useful in specific contexts of digital transformation: teams migrating legacy systems to cloud-native architectures, next-generation projects where the team wants to start from a more integrated base, or innovation labs that need iteration speed without the burden of complex IaC stacks.

Digital transformation

In any case, in a digital transformation process, the best test is flow metrics, not discourse. João Paulo recalls a success case where Objective elevated the agile maturity of 90 squads at RaiaDrogasil, reducing lead time from 160 to 74 days and increasing throughput from 115 to 278 features per month. It is this type of result that a team seeks when they talk about “going digital”: delivering faster, with predictability, and putting products in motion. In this logic, Winglang tends to be more valuable as an experiment guided by hypothesis, within a larger strategy.

Points of attention when adopting Winglang

Wing describes itself as “pre-release” in the repository. This, by itself, requires caution with production and structural dependency in critical projects. 

Today, the officially supported provisioning engine is Terraform. The project also mentions community support for AWS CDK (CloudFormation), but not as official support. If your organization depends on another engine, you need to validate its adherence before incorporating Wing as a central piece. 

The Wing Console does not follow the same licensing model as the rest of the repository. The documentation states that it is “source-available”: you can view the code and contribute, but you cannot use it commercially. This changes the conversation for companies that intend to embed, redistribute, or build commercial offerings based on the console. 

Finally, the simulator does not equate to production. The documentation makes a point of stating that the simulation “does not provide the same guarantees” as running on a cloud provider. For regulated teams or with strong reliability requirements, the healthy path is to treat the simulator as feedback acceleration, not as a substitute for validation in staging/production. 

What the emergence of Winglang reveals about the future of cloud development, AI, and data?

Winglang is not just “another language.” It is a symptom of a larger change: cloud has ceased to be an infrastructure destination and has become a product environment, with multiple services composing the software. As the number of services grows, so does the cost of integrating, testing, and maintaining everything consistently.

Higher abstractions

The Wing documentation itself argues that layers of abstraction are added over time to increase speed and focus on business needs, projecting a scenario where manually configuring specific storage solutions and IAM policies becomes unnecessary because policies can be deduced from code. As a counterbalance of control, the project cites compiler plugins to customize Terraform output and apply policies (for example, requiring encryption on exposed buckets).

The inference here is based on these points: “cloud-oriented” languages tend to push infrastructure into the role of generated artifacts, while the intention remains in the code.

Developer experience

The Gartner reports that 58% of organizations consider developer experience (DevEx) essential for improving productivity and software quality. It highlights objective correlations: teams with high-quality DevEx are 33% more likely to achieve business results, 31% more likely to improve delivery flow, and 20% more likely to “intend to stay” at the company.

When Wing says it wants to reduce slow cycles, tool overload, and lack of local solutions to keep the developer “in the flow,” it is addressing exactly this type of variable.

Convergence between cloud, data, and AI

In practice, Artificial Intelligence (AI) and data increase the number of “moving parts” in the system: storage, pipelines, data warehouses, managed services, asynchronous integrations, and often serverless. The more this type of composition becomes common, the more valuable it is to have tools that shorten the path between “code” and “validated environment,” even locally, without real provisioning. Wing’s simulator and its focus on iterating and testing quickly move in this direction.

There is, finally, an uncomfortable reminder: cloud adoption does not guarantee value. This connects Winglang to strategy, not trends: if the language helps the team focus on what delivers value and reduces infrastructure friction, it stands a chance. If it merely becomes another layer, it falls into the same bucket that the State of Agile identifies as a problem: “mixed systems” and silos that slow down delivery.

In the end, the decision to adopt Winglang is not about hype, but about real adherence to the problem. It is in this balance between technical boldness and engineering responsibility that good decisions occur, and it is precisely here that Objective operates: helping companies test, learn quickly, and scale only what really impacts the business. Contact our specialists to find out how we can help you.