shaiber

Yes lots and lots of work, but we enjoy doing it :)

About ballerina, there are similarities to wing, but at a high level it is focused on simplifying networking whereas Winglang is about simplifying the use of cloud services.

Yea, no good way around IDE extensions. Hopefully if Wing gets popular enough the community will create extensions where there is demand for them.

Also, thanks for taking the time to give us feedback

Thanks, and I agree with your reasoning, makes sense to provide objective data

[I'm on the Wing team] Yes, but it's still in early days, you can see our support matrix here: https://www.winglang.io/docs/standard-library/compatibility-...

[I'm on the Wing team] I get what you mean about adoption and maintenance overheads.

On the adoption front, we are aware it takes time for languages to get adopted. We also plan to release the Wing SDK to other languages soon, but the best DX is still provided by using Winglang itself simply because we are not constrained by what other languages support.

The language server is actually the same one for different editors, but we do need to create and maintain different editor extensions. The best supported one at the moment is VSC.

[I'm on the Wing team] Wing is still in early days so we can't show very complex use cases yet, but as time passes developer use to build more and more complex things with it.

Our aim is to improve productivity and speed by enabling developers to develop against a local simulator and visualization console, giving them instant feedback and much shorter iteration cycles. By allowing them to work at a higher abstraction level we aim to reduce complexity, which should also lead to greater productivity.

I hope that in the future, as more developers use Wing, we can show case studies and benchmarks that prove our hypothesis are correct.

:)

[I'm on the Wing team] The elevator pitch is that there are things we cannot do with existing languages, such as our inflights and their connection to preflights. This is because that if we used an existing language we'd have to support its legacy code and could not impose new limitations that are needed to execute the inflight system well. It doesn't mean that you cannot come close with existing languages, and there are nice projects that do that, it just means that you cannot go all the way.

The full version is here: https://www.winglang.io/docs/faq/why-a-language

[I'm on the Wing team] Thanks for the feedback. We call it new because it is only a year old, and for programming languages its pretty young. It is just now getting mature enough to be able to build real world applications with. Hope it makes sense

[I'm on the Wing team] We currently support AWS, Azure and GCP with varying degrees of maturity. Since it's an open platform one can add any other cloud. More info here: https://www.winglang.io/docs/faq/supported-clouds-services-a...

The short answer is that there are things we cannot do with existing languages, such as our inflights and their connection to preflights. The full version is here: https://www.winglang.io/docs/faq/why-a-language

[I'm on the Wing team]

Nice coincidence :)

There is no plan currently to add a two-way sync between the simulator diagram and the code, and there could be technical difficulties to do it since the code is not generated but written by developers (only the JS + TF compilation artifacts are generated). But you are welcome to open an issue about it and it and it will be prioritized if it gets enough votes.

Since Winglang generates CF/TF for the parts of the app that are defined in the language, it should be possible to add these parts to the ones that already exist in the app, but it depends on the app's architecture. One can also convert the existing codebase, or at least the infra part to Wing pretty easily in some cases. If you have a particular use case in mind we'd be happy to talk and see how we can help.

Yes, this is a cloud agnostic language, which is one of the differentiating factors from Pulumi where the code you write is cloud specific. Also, unlike Pulumi, Winglang is not an infrastructure language but can be used for both the infra and application code. Its compiler takes care of the cloud mechanics (IAM policies, networking) that IaC tools like Pulumi and the CDK require you to configure manually. More info here:

Hey, I'm part of the Wing team, funny you mention the construct programming model as it comes from the CDK, which is Elad's (Wing's creator) previous project. Wing is also built around this concept.

I will read the article you mentioned, sounds interesting

Hey, I'm part of the Wing team, Winglang is a general purpose programming language, not a framework, so there are less limitations on how far it can take the development experience. It let's developers work at a higher level of abstraction, is fully extensible and is cloud and provisioning engine agnostic. It comes with a local cloud simulator, allowing you to get instant feedback and enjoy very short iteration cycles. It also comes with a visualisation console to interact with the local app and debug and test it.

Hey, I'm part of the Wing team, I see where you're coming from regarding intermingling business logic with infra definitions. If it makes sense, these infra definitions are the functional part of the infrastructure (declaring that you want a bucket and pre-populating it with objects during deployment for instance). The non-functional parts (encryption, redundancy, others) can be taken care of separately on the platform side

Hey, I'm on the Wing team, yes you are correct, cloud services, like object storage, are indeed first class citizens and you can use them as naturally in Wing as you would use basic data structures or OS services in traditional languages. The idea behind Wing is that the cloud is the computer that it targets. By having a compiler that sees the entire application, including infra and runtime code, we are able to delegate cloud mechanics (IAM policies, network topologies, etc.) to it instead of leaving these details for developers to take care of and reduce their velocity.

Hey, one of Wing's creators here. Happy to answer any question or discuss any feedback :)

Thanks for the feedback.

I get where you're coming from about a new language for inflight. We will have support for existing languages in the future, through an SDK, although you will not get all the benefits of the Wing compiler this way.

About #2, we've identified the issue to be the lottie animations. Working on a fix

Good questions. 1. You can read about it in this blogpost: https://www.winglang.io/blog/2023/07/18/wing-cloud-launch Specifically this section: https://www.winglang.io/blog/2023/07/18/wing-cloud-launch#wh...

2. It shouldn't do that.. which page did you visit?

Hi, I'm one of the founders of Wing Cloud. I'd love to get feedback on what we're building and answer any question.

The console is "source available". All the rest is fully open-source with MIT license.

Thanks, we'll rephrase to say that it is impossible in most languages, not all. BTW, the company that is behind the project is called Monada (https://monada.co), so we've heard of monads :) Would be happy to hear what else you think about the language

I wrote about comparison to Terraform here: https://docs.winglang.io/faq/differences-from-other-solution...

About the simulator, it is a functional simulator to be able to test and interact with the business logic of the application. There are other solutions, like LocalStack to simulate the non functional parts too.

Hey, I understand where you're coming from, but I still think there is room abstraction when done right. I wrote about it here: https://docs.winglang.io/faq/why-cloud-abstraction

Sorry about that, please use this link: https://docs.winglang.io/blog/2022/11/23/manifesto

Hey, try this version: https://docs.winglang.io/blog/2022/11/23/manifesto

In this insightful article, Elad Ben-Israel, the mind behind the CDK, shares his love for the cloud, but also his frustrations with the complexity of building cloud applications. The challenges he identifies include: 1. Focus on non-functional mechanics: The need to understand and manage cloud platform mechanics instead of focusing on building valuable features for users. 2. Lack of independence: Developers often need to rely on others to handle parts of the deployment process or to resolve issues, interrupting their work flow. 3. Delayed feedback: The current iteration cycle in cloud development can take minutes or even longer, significantly slowing down the development process and making it harder for developers to stay in their flow state.

## It's not just a rant

Elad is not just ranting about cloud development. He proposes a solution in the form of a programming language for the cloud. This language would treat the entire cloud as its computer. The language compiler will be able to see the complete cloud application, unbound by the limits of individual machines. Such a compiler would be able to handle a significant portion of the application's non-functional aspects, enabling developers to operate at a more abstract level, thus reducing complexity and promoting autonomy. Moreover, it could expedite iteration cycles by allowing to compile applications to quick local simulators during the development process.

## The Winglang Project

Elad reveals that he's in the process of developing such an open-source, “cloud-oriented” language, dubbed Winglang (https://github.com/winglang/wing). Wing aims to improve the developer experience of cloud applications by enabling developers to build distributed systems that leverage cloud services as first-class citizens. This is achieved by integrating infrastructure and application code in a secure, unified programming model. Wing programs can be executed locally via a fully-functional simulator or deployed to any cloud provider.

## My Interest in Winglang

I, together with a group of dedicated contributors, joined forces with Elad to develop Winglang. While still in Alpha and not yet ready for production use, it's already possible to build some real applications (https://github.com/winglang/research/tree/main/dogfooding).

Check out https://github.com/winglang/wing for more details.

This insightful article by Gregor Hohpe covers:

* Evolution of programming abstractions. * Challenges of cloud abstractions. * Importance of tools like stack traces for debugging, especially in distributed systems.

Gregor emphasizes that effective cloud abstractions are crucial but tricky to get right. He points out that debugging at the abstraction level can be complex and underscores the value of good error messages and observability.

The part about the "unhappy path" particularly resonated with me:

"The unhappy path is where many abstractions struggle. Software that makes building small systems easy but struggles with real-world development scenarios like debugging or automated testing is an unwelcome version of “demoware” - it demos well, but doesn’t actually work in the real world. And there’s no unlock code. ... I propose the following test for vendors demoing higher-level development systems:

1. Ask them to enter a typo into one of the fields where the developer is expected to enter some logic.

2. Ask them to leave the room for two minutes while we change a few random elements of their demo configuration. Upon return, they would have to debug and figure out what was changed.

Needless to say, no vendor ever picked the challenge."

Why it interests me?

I'm one of the creators of Winglang (https://github.com/winglang/wing), an open-source programming language for the cloud that allows developers to work at a higher level of abstraction.

We set a goal for ourselves to provide good debugging experience that will allow developers to debug cloud applications in the context of the logical structure of the apps.

After reading this article I think we can rephrase the goal as being able to easily pass Gregor's vendor test from above :)

This insightful article by Adam Ruka covers: - What's IaC. - First gen. tools: Declarative, Host Provisioning (Chef, Puppet, Ansible). - Second gen. tools: Declarative, Cloud (CloudFormation, Terraform, Azure Resource Manager). - Third gen. tools: Imperative, Cloud (AWS CDK, Pulumi, SST). - The future: Infrastructure from Code (Wing, Eventual, Ampt, Klotho).

Why it interests me? I'm one of the creators of Winglang (https://github.com/winglang/wing) that is featured there as one of the future 4th gen. tool, along with Eventual (https://github.com/functionless/eventual), Ampt (https://github.com/getampt) and Klotho (https://github.com/klothoplatform/klotho).

Thanks for the explanation!