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.
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.
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:
My question about how to integrate with existing code is more of a curiosity rather than a specific use case. It seems like adoption will be an uphill battle because you're asking devs to learn a new language AND port all existing infrastructure code to Wing.
One other thought: It would be cool to see Wing shine by demoing a full-blown distributed system. Perhaps with a couple of microservices and some supporting infrastructure.
In my experience, CDK is far better than Pulumi, especially if you're mostly going to be using AWS.
"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...
I agree that the ergonomics of a languaged planned for that is better. But the argument that it's *only* possible with a purposeful language doesn't hold, in my opinion.
Afaik, the AWS CDK allows to express both preflight and inflight in JS, Python, and others, and it works well. Again, the CDK gives an arguably worse experience, but not "impossible"...
[1] https://www.pulumi.com/docs/using-pulumi/automation-api/
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).
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?
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.
I'm sure I'm getting the wrong end of the stick but isn't this possible to ensure using typing? Very simple dependent typing/phantom types/bog standard normal types?
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.
I will read the article you mentioned, sounds interesting
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.
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.
Awesome! I agree that your intended experience is likely to be more curated, but supporting other languages might really help. This is really cool to hear.
Also, I realize I might have phrased it poorly, but I meant exactly that about the language server. Language server once, but each editor needs its own extension. Even the extension wrappers around the language server could quickly eat up a lot of maintenance time because there is no true standard. Open VSX is pretty nice for cross editor extensions, but not too many editors use it, yet.
queue.setConsumer(inflight (body: str): str => { let next = counter.inc(); let key = "myfile-{next}.txt"; bucket.put(key, body); });
My category theory is pretty rudimentary, but isn’t this a good use case for a monad?
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...
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.
The full version is here: https://www.winglang.io/docs/faq/why-a-language
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.
Nice!
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.
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.
But can’t you already do this today with GCP and AWS and more generally a wealth of Docker images and Kub/Knative?
Furthermore, I wonder how you guys plan to encourage users to jump ship from (node/go/Java/.NET) to winglang, all of which have a rich package ecosystem?
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)
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
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?
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 think using a subjective term is meaningless, at least in the context of an introduction. "New" is far too relative, and means something entirely different for one person to the next.
I personally think it makes more sense to provide an objective fact, such as "started in 2022" and let readers determine whether that qualifies as "new" or not.
I wouldn't have mentioned it, and may not have even noticed if it weren't literally the first piece of information presented to me in the repo.
In any case best of luck with the project. It looks very promising and I am excited to see where it goes!
How do you compete with -- if at all -- with Ballerina lang? https://ballerina.io/
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.
Also, thanks for taking the time to give us feedback
let bucket = new cloud.Bucket();
let api = new cloud.Api();
// api.get is a preflight method - it generates cloud infrastructure
api.post("/hello", inflight (req) => {
// bucket.put is an inflight method - it performs data plane operations, at "runtime"
bucket.put("data.txt", req.body ?? "empty");
});
Could this style of API be achieved in an existing language? I think it's an open ended question - I'm not sure. But I reckon it gets into complex framework territory (or may require injecting modifications into existing compilers, which presents other challenges). But I'd love to see more exploration into this direction.
Yes, it can be done by either building the contents of the lambda in some truly horrid way (you'd effectively be building an AST at runtime). The alternative is to get hold of the AST/parse tree at runtime (which I believe.NET can do if you ask it nicely, but that is very specifically .NET) which you can then analyse.
The first way is utterly vile though workable and language agnostic, the second way is definitely tied to one platform. If there's third way I can't think of it ATM.
I personally don't think it's intuitive that function calls using the same syntax either emit terraform code or JS. It's like mixing compile time macros and code into one.
I can try and put something together in C# but not right now I'm afraid (it would be a good exercise for me as I've only read up on these, not actually use them personally, although I plan to start very soon for my own personal work). There was some examples going round here https://old.reddit.com/r/programming/comments/zm7f9/phantom_... which may help.
Again, I may be misunderstanding your domain completely, so bear it in mind please.
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.
https://github.com/localstack/awscli-local
https://github.com/fsouza/fake-gcs-server
https://cloud.google.com/sdk/docs/downloads-docker
I’ve used all of these locally to great success.
Glad to hear you guys want to interop with npm.