31–40 of 72 posts
My category theory is pretty rudimentary, but isn’t this a good use case for a monad?
> infrastructure and runtime code in one language 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…
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…
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:
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. 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.
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…
In my experience, CDK is far better than Pulumi, especially if you're mostly going to be using AWS.
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. Do you just compile it and see where it fails?
(engineer on the Winglang team here) 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…
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?
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.
More on platforms here: https://www.winglang.io/docs/concepts/platforms
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" ?