Reviewed https://winglang.io this week. I did NOT get a chance to play with it, but did read the docs.

There is a lot to say, but here’s the gist. It’s like the AWS CDK, but a whole other language designed specifically for building cloud applications in multiple clouds. You write in Wing, like you would with TypeScript in the AWS CDK, and it compiles to a cloud target; like “S3 buckets in CloudFormation” or “Lambda functions in Terraform”. It also includes code that can run _on_ the cloud called inflight code (preflight code is what builds your infra), and most importantly, tests that can run locally AND _in_ + _on_ the cloud.

First, it comes from the creator of the AWS CDK. If you’re familiar with that, then you’ll see a lot of the same philosophy here: Using a typed language, defining infra using classes, and lots of Object Oriented Programming thinking around “grouping these infra things as Classes with configurations inside”.

The language, Wing with a .w file suffix, however, is more like a JavaScript/ReScript hybrid. If you’re a JavaScript/TypeScript dev, you’ll see a lot you recognize, but a LOT less typing required, I reckon from the type inference. The developers are clearly from a Java/C# background and consider those mainstream cloud languages which I find super odd; C# and Java, at least in the serverless world, were NEVER preferred over JavaScript/Python, heck even Go. I guess they mean cloud as in “EC2/ECS/K8”. At any rate, if you’re familiar with OOP and types, you’ll feel super comfortable.

The compilation is one of the main value add’s to developers here. Instead of writing Terraform or CloudFormation, you write Wing, and Wing compiles to to Terraform, CloudFormation, … or both. If you’re one of those developers whose taken on more Ops work as opposed to an IT/SysAdmin who’s traditionally done Ops, you probably would prefer to write code vs. YAML. THIS is the target demographic: coders. Those who think in types. Those who want tests for their “Infrastructure as Code” because… it’s code. We test code.

However, it’s ambitious in that while it follows the JSII compatibility goals, it wants to be cloud agnostic. If you’re not familiar, JSII is the JavaScript standard so you can write an AWS service, then have _all_ languages support it. It’s why the Python AWS SDK called Boto3 and the JavaScript all have about the same class and method naming structure. It’s also why a lot of us non-OOP fans hated the AWS SDK v2 and v3 because it went from modules and functions to classes.

Still, while it may seem like super ambitious, the compilation targets _actually_ do a lot of the work. Specifically, compiling Terraform… it already is cloud agnostic by design as opposed to CloudFormation which is specifically for AWS.

The type system is very similiar to any non-sound TypeScript/C#/Java one, so if you know any of those, you’ll get up to speed immediately. The JSON handling, however, has been abstracted really simply to provide built in Schema parsing to your types without having to write a Zod Novels® or Avro Epics™. They even have built in tryCatch methods.

What I’m disappointed about is they still support null values and exceptions. I get why; anyone who’s from a Java/C#/TypeScript background will understand what those are, think they’re normal, and expect those to happen. Despite being solved problems with better solutions such as Clojure’s Spec or ML languages Maybe, and errors as values like Go’s tuple returns or any ML language’s Result type, they stuck with what most are familiar with. Disappointing in 2023 we’re building new languages with these 1960’s problems.

Still, things like JSON’s tryFromJson method will hopefully influence developers to realize the world doesn’t have to revolve around copious try/catch.

The tests and simulations are amazing. You can do a dry run locally, like running your infra build code, but ensuring it doesn’t actually build anything, you’re just ensuring it all looks like its building things correctly and the RIGHT things.

Secondly, your unit tests can both test your code, AND test it in the cloud. So many of us doing Acceptance Tests in Serverless are doing a lot of that just to ensure the code works as expected “in the cloud”. However, a lot of that motivation isn’t really about the code; it’s to ensure the infra itself works. Just because I have a Lambda function setup doesn’t mean it’s allowed to send to SQS, or the that the SNS triggers are firing the Lambda functions correctly. Basic infra setup tests are usually baked into our Acceptance Tests, which is fine. However, having these infra tests as part of your infra as code… wow, amazing. Will help focus the tests more, for sure, AND add more resilience to CICD pipelines.

Like Roc, you can include your tests IN the same file as your code. This greatly simplifies the amount of files and test setup. That’s not all, though; you can ALSO include your inflight code as well such as Lambda functions or API’s. Meaning you wouldn’t have to have separate JavaScript/TypeScript for your API’s… it’d be right next to the infra. Unsure how I feel about this, but if you’re going to be cloud agnostic, this is pretty powerful. On the flip side, seems odd seeing an OOP language trying to prevent so many files from being created, but “part of the solution, not part of the problem” I guess.

Finally, they have a UI that works with their simulator to both view your infra, and even play with it to ensure it’s working locally. That’s… crazy cool.

All in all, Wing has done a herculean amount of effort. When people asked “Why are Ops tools _so bad_?” they answered, “because people like us haven’t built Wing yet”.

One thing I don’t see, and wish I did on their road map is something that Gregor Hohpe brought up recently, specifically about using Domain Driven Design concepts, what we Functional Programmers call Types; using those to design your Domain, and the infrastructure and code is just details. Wing, I’d say more so than the AWS CDK, is perfect for that. I think that’s one of the later values from these Infrastructure as Code cloud agnostic platforms.