research VS jsii

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 rantElad 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 ProjectElad reveals that he's in the process of developing such an open-source, “cloud-oriented” language, dubbed Winglang. 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 WinglangI, 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.Check out https://github.com/winglang/wing for more details.

## 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).

We have been working on Wing for almost a year now, and I am excited to invite you to check it out and let me know what you think. While still in Alpha and not yet ready for production use, it's already possible to build some real applications with it.

What about jsii? The technology behind AWS sdks: https://aws.github.io/jsii/

Is Stainless similar, different?

The libraries for other supported languages of CDK are built as wrappers for underlying JS or maybe TS code via https://github.com/aws/jsii

So all the core CDK code is written first in JS/TS and then stubs for the other languages are added

Unfortunately this is often done without consideration for how the other supported langs actually work, and artefacts of e.g. JS lack of support for kwargs leak through

This is why e.g. the typing in CDK Python is completely broken - pretty much uniformly the concrete types like "Resource" don't implement their corresponding interface like "IResource" (to a type checker)

(There are many other typing niggles like this but that's the most egregious and pervasive one)

At the end of the day, having to explicitly cast concrete types as their interface to satisfy type checker is a minor annoyance, albeit a stupid one that could have been avoided with more care in the core library.

I could live with that, but I encountered so many bugs and issues trying to use CDK on current project that it's now much clearer to me why every company I worked at previously was using Terraform.

Pretty sure some of those issues are ultimately CloudFormation ones. The cumbersome CF > CDK JS > CDK Python stack is great for obfuscating errors and making debugging hard or impossible though.

Pulumi do something similar, albeit with Go as the core language and Terraform underneath. From what I've seen with a little use they have a much more successful result though, Pulumi Python was not a complete mess, and deploys faster and more reliable with better error feedback. I guess they just took more care to get it right.

Every version of the CDK uses an interop layer and runs on top of the Typescript version

https://github.com/aws/jsii

And as far as TF supports services before CFT. Guess which is easier for an AWS employee to do - getting the CF service team to support a new service or just contribute to Terraform’s open source project?

I know of at least one service where the service team introduced the needed APIs and then an employee of AWS wrote the TF provider and contributed to the project before AWS’s own internal team added it to CFT.

Source: former AWS ProServe employee

To "meet developers where they are" is a beautiful tenet of AWS, and of the CDK, and inspired us to create awesome technology such as JSII and constructs.

Yeah both CDKTF and Pulumi piggyback on JSII, a class translator that supports the languages you've mentioned, which was used as a building base for CDK.

The reason we chose to start with compilation to JavaScript and not some other popular cloud language is because JavaScript is currently one of the most used ones, and in addition, we are using JSII to write our SDK in Typescript and then export it for consumption in other languages, such as Go, Python, Java and others.

The CDKTF CLI is implemented in TypeScript. Providers and resources are implemented in TypeScript as well. jsii is used to compile the providers and resources to the supported languages.