Winglang looks really cool. I'm really curious how Winglang will evolve their language syntax and semantics to make cloud development more expressive (I assumed `bring` and `inflight` keywords are just the beginning?).
At Shuttle[0] we've built something similar but instead of building a language from scratch we've built on Rust using metaprogramming and the type system to achieve the same effect. For now we haven't hit any limitations that would warrant a new compiler as metaprogramming allows us to express cloud development quite naturally inside the language.
It's a coincidence I just went through the getting started guide yesterday. It would be nice to have a two-way sync between the simulator diagram and the generated code. I'm also curious how Winglang handles existing infrastructure and what it looks like to introduce Winglang to a project that already uses CF or TF.
I've used CF, and TF and was an early adopter of CDK. I'm curious how this compares with Pulumi (never tried it). I liked the idea behind CDK but was shy about going all in because it was AWS-specific. Looks like this is the natural progression.
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:
Why a whole language rather than a library that could just as well abstract the cloudy infrastructure and expose its data structures as "first class citizens" ?
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
> Why a whole language rather than a library that could just as well abstract the cloudy infrastructure and expose its data structures as "first class citizens" ?
"Very cool, but what here cannot be done by a library or compiler extension?
In existing languages, where there is no way to distinguish between multiple execution phases, it is impossible to naturally represent this idea that an object has methods that can only be executed from within a specific execution phase (or within certain scopes of the program). You are welcome to read more about it here (including code samples that show the same app built in Wing vs. other solutions)."
I've been following the Unison lang [1] for quite some. Wing seem to set similar goals? From the first glance Wing looks more polished, but there's "The Big Idea" behind Unison - is there something similar?
Unison is a pure functional language. That's important because it allows the whole "big idea" to work: you can change code, commit it to your Unison database and synchronize with your cloud without it ever breaking due to things like "different versions of a type" for example.
This language OTOH looks like TypeScript with seamless access to cloud resources, which while neat, is not comparable to what Unison brings to the table (it may, however, be what people actually want... time will tell).
Given that it's built as a whole language, I'm curious about the choice to make no obvious distinction between 'preflight' and 'inflight' functions.
It's not obvious at a glance that you can only call inflight functions in an inflight scope, because the syntax for calling them is identical to calling a preflight function on the same object.
Your observation is partially correct. The language does make a distinction when you're defining new functions: you must use the "inflight" keyword annotation to define an inflight function, and most un-annotated functions are assumed to be "preflight". (The top-level scope of every Wing program has a preflight phase).
But at _call sites_ no distinction is made. We don't have have a different calling convention between calling preflight/inflight functions because the compiler uses type checking to enforce that inflight functions can only be called in inflight scopes, and preflight functions can only be called in preflight scopes. Scopes are lexical, meaning you can automatically assume when you see `inflight () => { ... }` or `inflight foo() { ... }` that all code inside that block is executed inflight, i.e. at runtime.
The neat thing here is if you're writing code to access a method on a class (typing `obj.`), your IDE's auto-completion will only show you the methods available to you based on the scope you're in. There's a short 10 second clip showing this here: https://twitter.com/rybickic/status/1720168675641102803
We've prioritized LSP support while designing the compiler to help out with this.
This is fertile ground for new languages, apparently they call this the "Construct Programming Model" but there appears to be no meat to the theory. If programming language theory was leveraged properly I think they'd really be on to something. See the success of Rust for example.
I just did some cursory research and came across a paper on "ABS: A high-level modeling language for cloud-aware programming" which would give a much stronger foundation for such an effort than JavaScript.
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
I think it's an interesting idea, but I feel like creating a whole new language has too much overhead for adoption. You would need to create a language server and extensions for every editor you want to support.
A language-specific DSL (Pulumi, CDK, etc) just works in any editor that already supports your language.
This is a similar reason to why I dislike most docblock-based infra tools as well. If wing is confident in their ability to maintain editor tooling, more power to them, but it isn't maintenance I would want to manage.
[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.
>In existing languages, where there is no way to distinguish between multiple execution phases, it is impossible to naturally represent this idea that an object has methods that can only be executed from within a specific execution phase
My category theory is pretty rudimentary, but isn’t this a good use case for a monad?
Look interesting but my first thought is I don't see any error case code.
Given this language is really about abstracting network calls to external services as objects/methods wouldn't it make sense to have return values be maybes and then be able to pattern match on that given that these are not local calls and networks/services do fail?
My guess is an actor pattern where you are sending messages to these services and waiting for responses instead of faking a local call would surface the error conditions in a much cleaner way, ala Erlang or Elixir.
This seems to be in roughly the same space as the radius project[1] out of Microsoft. They are a data structure rather than a language, but the idea of merging the application and infrastructure seems similar. Is there a place for one application/infrastructure model that includes integration details in the manner of Apache Camel[2] that we can all get behind?
[1] https://radapp.io
[2] https://camel.apache.org
I need an elevator pitch on this (which is currently in my "yet another terraformy thing" mental bucket right now, rightly or wrongly!).
I am interested, but when I look at the comparison with Pulumi - https://www.winglang.io/docs/faq/why-a-language, they have 4 lines of code in Wing, but the long Pulumi example sets up permissions. So how did the permissions get set up in Wing? The great thing about Pulumi is if you are trying to comply with company security policies which in turn are for SOC2 etc. then this explicit setup as code is great. I think Pulumi also has a policy system but I haven't explored it yet.
So what I am saying is more code != bad (think of the raison d'etre of the Go programming langauge) but I am not saying Wing is bad ... I am saying I would like to know more.
I find it hard to believe that there is a semantic deficiency in JS/Go/C# etc. that means you need a new languages. And if you use Typescript, OCaml or Haskell (most likely Typescript for popularity) you can probably make the Type system do as much static heavy lifting as possible. Of course some checks need the current state so need runtime. But happy to be persuaded we need a new language.
[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.
> […] they have 4 lines of code in Wing, but the long Pulumi example sets up permissions. So how did the permissions get set up in Wing?
As it says on the page: "Wing allows developers to write very few lines of code and let the compiler take care of IAM policies and other cloud mechanics."
Basically it auto-generates least-privilege IAM policies.
[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 could see this useful for prototyping, but I worry about losing finer control. for instance when I make a lambda, I like to have the lambda execute a container rather than write the function in place
Hi there! Being able to break through the abstraction to apply these non-functional requirements is a MUST in our opinion.
That is why we introduced Wing Custom Platforms that allow you to customize how resources are provisioned (as well as some other things). Giving you as much or as little control as you need.
> In existing languages, where there is no way to distinguish between multiple execution phases, it is impossible to naturally represent this idea that an object has methods that can only be executed from within a specific execution phase (or within certain scopes of the program).
What about algebraic effect based languages like koka? Would it make sense to make "inflight" methods and effect and have appropriate effect handlers in scopes like queues or functions?
The way I read it is that Winglang combines your IaC and your runtime logic/code. In theory it's pretty neat, I haven't given it a serious try though. I'm not totally convinced that I want my infrastructure definition intermingled with my business logic though.
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.
This is pretty cool! I've had my eye on Wing for a while, as a avid fan of Pulumi. I was fortunate enough to have the freedom to use Pulumi in a past role, and it revolutionized the way I thought about infrastructure.
My current org has been slow to adopt IaC, and Bicep has been all for which I've managed to drum up appetite. I was surprised somewhat to enjoy the simplicity, but eventually I think we'll outgrow it. My hope is by the time we're ready to graduate, things like Wing, or radius will be more mature and easier to weave in.
On a side note, it feels disingenuous or at least inaccurate for a project to brand itself "new". I feel like I've seen this posted to hn a few times, how long will it be "new"? There's at least one 8-month old post.
The word "new" scares away certain types, who happen to be in leadership or decision-making roles.
[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
openquery|2 years ago
At Shuttle[0] we've built something similar but instead of building a language from scratch we've built on Rust using metaprogramming and the type system to achieve the same effect. For now we haven't hit any limitations that would warrant a new compiler as metaprogramming allows us to express cloud development quite naturally inside the language.
[0] https://www.shuttle.rs/
thesurlydev|2 years ago
I've used CF, and TF and was an early adopter of CDK. I'm curious how this compares with Pulumi (never tried it). I liked the idea behind CDK but was shy about going all in because it was AWS-specific. Looks like this is the natural progression.
shaiber|2 years ago
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:
shepherdjerred|2 years ago
In my experience, CDK is far better than Pulumi, especially if you're mostly going to be using AWS.
whoomp12341|2 years ago
liotier|2 years ago
shaiber|2 years ago
ramesh31|2 years ago
"Very cool, but what here cannot be done by a library or compiler extension?
In existing languages, where there is no way to distinguish between multiple execution phases, it is impossible to naturally represent this idea that an object has methods that can only be executed from within a specific execution phase (or within certain scopes of the program). You are welcome to read more about it here (including code samples that show the same app built in Wing vs. other solutions)."
https://github.com/winglang/wing#very-cool-but-what-here-can...
totallywrong|2 years ago
[1] https://www.pulumi.com/docs/using-pulumi/automation-api/
bez00m|2 years ago
[1]: https://github.com/unisonweb/unison
brabel|2 years ago
This language OTOH looks like TypeScript with seamless access to cloud resources, which while neat, is not comparable to what Unison brings to the table (it may, however, be what people actually want... time will tell).
ljm|2 years ago
It's not obvious at a glance that you can only call inflight functions in an inflight scope, because the syntax for calling them is identical to calling a preflight function on the same object.
Do you just compile it and see where it fails?
chriscbr|2 years ago
Your observation is partially correct. The language does make a distinction when you're defining new functions: you must use the "inflight" keyword annotation to define an inflight function, and most un-annotated functions are assumed to be "preflight". (The top-level scope of every Wing program has a preflight phase).
But at _call sites_ no distinction is made. We don't have have a different calling convention between calling preflight/inflight functions because the compiler uses type checking to enforce that inflight functions can only be called in inflight scopes, and preflight functions can only be called in preflight scopes. Scopes are lexical, meaning you can automatically assume when you see `inflight () => { ... }` or `inflight foo() { ... }` that all code inside that block is executed inflight, i.e. at runtime.
The neat thing here is if you're writing code to access a method on a class (typing `obj.`), your IDE's auto-completion will only show you the methods available to you based on the scope you're in. There's a short 10 second clip showing this here: https://twitter.com/rybickic/status/1720168675641102803
We've prioritized LSP support while designing the compiler to help out with this.
haskellandchill|2 years ago
This is fertile ground for new languages, apparently they call this the "Construct Programming Model" but there appears to be no meat to the theory. If programming language theory was leveraged properly I think they'd really be on to something. See the success of Rust for example.
I just did some cursory research and came across a paper on "ABS: A high-level modeling language for cloud-aware programming" which would give a much stronger foundation for such an effort than JavaScript.
shaiber|2 years ago
I will read the article you mentioned, sounds interesting
intelVISA|2 years ago
cmgriffing|2 years ago
A language-specific DSL (Pulumi, CDK, etc) just works in any editor that already supports your language.
This is a similar reason to why I dislike most docblock-based infra tools as well. If wing is confident in their ability to maintain editor tooling, more power to them, but it isn't maintenance I would want to manage.
shaiber|2 years ago
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.
nathan_tarbert|2 years ago
queue.setConsumer(inflight (body: str): str => { let next = counter.inc(); let key = "myfile-{next}.txt"; bucket.put(key, body); });
eladbenisrael|2 years ago
RcouF1uZ4gsC|2 years ago
My category theory is pretty rudimentary, but isn’t this a good use case for a monad?
dugmartin|2 years ago
Given this language is really about abstracting network calls to external services as objects/methods wouldn't it make sense to have return values be maybes and then be able to pattern match on that given that these are not local calls and networks/services do fail?
My guess is an actor pattern where you are sending messages to these services and waiting for responses instead of faking a local call would surface the error conditions in a much cleaner way, ala Erlang or Elixir.
This may be helpful: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
dadadad100|2 years ago
quickthrower2|2 years ago
I am interested, but when I look at the comparison with Pulumi - https://www.winglang.io/docs/faq/why-a-language, they have 4 lines of code in Wing, but the long Pulumi example sets up permissions. So how did the permissions get set up in Wing? The great thing about Pulumi is if you are trying to comply with company security policies which in turn are for SOC2 etc. then this explicit setup as code is great. I think Pulumi also has a policy system but I haven't explored it yet.
So what I am saying is more code != bad (think of the raison d'etre of the Go programming langauge) but I am not saying Wing is bad ... I am saying I would like to know more.
I find it hard to believe that there is a semantic deficiency in JS/Go/C# etc. that means you need a new languages. And if you use Typescript, OCaml or Haskell (most likely Typescript for popularity) you can probably make the Type system do as much static heavy lifting as possible. Of course some checks need the current state so need runtime. But happy to be persuaded we need a new language.
shaiber|2 years ago
The full version is here: https://www.winglang.io/docs/faq/why-a-language
Qerub|2 years ago
As it says on the page: "Wing allows developers to write very few lines of code and let the compiler take care of IAM policies and other cloud mechanics."
Basically it auto-generates least-privilege IAM policies.
gnarlouse|2 years ago
Show me making it more complex and what that costs.
Show me the performance benchmarks.
Syntax is cool but the older I get the more I care about productivity and speed.
shaiber|2 years ago
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.
dang|2 years ago
Wing Cloud Raises a $20M Seed to Build a Programming Language for the Cloud - https://news.ycombinator.com/item?id=36864816 - July 2023 (6 comments)
Wing: A cloud-oriented programming language – request alpha access - https://news.ycombinator.com/item?id=34051325 - Dec 2022 (148 comments)
Wing programming language: A cloud-oriented programming language - https://news.ycombinator.com/item?id=33762969 - Nov 2022 (1 comment)
srbhr|2 years ago
haolez|2 years ago
whoomp12341|2 years ago
screwl00se92|2 years ago
Hi there! Being able to break through the abstraction to apply these non-functional requirements is a MUST in our opinion.
That is why we introduced Wing Custom Platforms that allow you to customize how resources are provisioned (as well as some other things). Giving you as much or as little control as you need.
More on platforms here: https://www.winglang.io/docs/concepts/platforms
eddd-ddde|2 years ago
What about algebraic effect based languages like koka? Would it make sense to make "inflight" methods and effect and have appropriate effect handlers in scopes like queues or functions?
shauniel|2 years ago
nevodavid10|2 years ago
bath_|2 years ago
shaiber|2 years ago
haolez|2 years ago
jahsome|2 years ago
My current org has been slow to adopt IaC, and Bicep has been all for which I've managed to drum up appetite. I was surprised somewhat to enjoy the simplicity, but eventually I think we'll outgrow it. My hope is by the time we're ready to graduate, things like Wing, or radius will be more mature and easier to weave in.
On a side note, it feels disingenuous or at least inaccurate for a project to brand itself "new". I feel like I've seen this posted to hn a few times, how long will it be "new"? There's at least one 8-month old post.
The word "new" scares away certain types, who happen to be in leadership or decision-making roles.
shaiber|2 years ago
bluber84|2 years ago
shaiber|2 years ago
gigatexal|2 years ago
shaiber|2 years ago