Why is this a language, not just a framework for JavaScript or whatever?<p>I suppose you could say the same about Terraform using HCL - but that makes extensive use of it being declarative, which is so unusual that they'd be picking an obscure probably-new-to-the-user language anyway. This just looks.. JS-ish, a bit like anything really.<p>I suppose I'm asking what are the <i>language</i> features that make Wing great for 'cloud', any `new Bucket()` etc. aside?<p>If you look at its 'design tenets', the only ones that are about the language not the SDK are just saying 'be good/familiar like other languages'... Ok so why not <i>be</i> another language? <a href="https://docs.winglang.io/reference/spec#02-design-tenets" rel="nofollow">https://docs.winglang.io/reference/spec#02-design-tenets</a>
New languages == zero ecosystem—no third-party libraries, community discussion (e.g. StackOverflow), real-world repositories, etc.<p>A brand new language thus must be extremely compelling at a syntactical level to make it worth leaving behind existing ecosystems. The new language’s syntax must provide capabilities that are impossible to implement in any other commonly used language. Otherwise, just implement the core language functionality using the syntax of another established language.<p>I just don’t see why that couldn’t be done here. Everything in the demo code could easily be implemented as a Python or JavaScript API.
I really dislike advertisements that want you to "request access." I've submitted them on occasion before, but have never heard back. And the information they want to collect is invasive. I suspect they're all vapourware harvesting information about the gullible.
A cloud-oriented language should have a way to output for every function that has financial cost, there should be a cost estimator or inspector that provides estimated cost ranges for execution, or at least some indication of potential cost impact. The language should optimize for cost-reduction instead of performance as the cloud presents a cost / performance tradeoff.
None of the links to the Github repositories for the language resolve. I checked the link for the compiler [1], the SDK [2], and the VSCode extension [3], and all of them 404. Seems like the repositories are all still private, which is odd, given that the page claims<p><pre><code> However, it's definitely ready for those brave of hearts who would like to
be involved at this early stage, influence our roadmap and join us for the
ride.
</code></pre>
Kind of hard to do that when all the source code is closed.<p>[1]: <a href="https://github.com/orgs/winglang/projects/1">https://github.com/orgs/winglang/projects/1</a><p>[2]: <a href="https://github.com/orgs/winglang/projects/3">https://github.com/orgs/winglang/projects/3</a><p>[3]: <a href="https://github.com/winglang/wing">https://github.com/winglang/wing</a>
Seems like a reasonable effort and we probably need more of this kind of stuff. But still I think the industry should focus more on educating developers to prevent them from introducing mostly unnecessary accidental complexity to today's typical apps rather than inventing new layers to manage it.<p>Related:<p><a href="https://twitter.com/garybernhardt/status/1603498230125588480" rel="nofollow">https://twitter.com/garybernhardt/status/1603498230125588480</a><p><a href="https://twitter.com/garybernhardt/status/600783770925420546" rel="nofollow">https://twitter.com/garybernhardt/status/600783770925420546</a><p><a href="https://geekandpoke.typepad.com/geekandpoke/2011/03/architectural-best-practices.html" rel="nofollow">https://geekandpoke.typepad.com/geekandpoke/2011/03/architec...</a>
This is one of the more sophisticated and cool of the "Self Provisioning Runtime" concepts that have emerged in the last few years (<a href="https://swyx.io/self-provisioning-runtime" rel="nofollow">https://swyx.io/self-provisioning-runtime</a>). Some of the others:
- <a href="https://www.pulumi.com/docs/tutorials/cloudfx/" rel="nofollow">https://www.pulumi.com/docs/tutorials/cloudfx/</a>
- <a href="https://www.serverless.com/cloud" rel="nofollow">https://www.serverless.com/cloud</a>
- <a href="https://www.shuttle.rs/">https://www.shuttle.rs/</a>
- <a href="https://encore.dev" rel="nofollow">https://encore.dev</a><p>In general, while it's clear that somehow cloud complexity needs to be abstracted away from developers, I don't think it makes sense that new programming languages or frameworks are necessary to do this well. It makes migration of existing apps and backwards compatibility with the existing software ecosystem too challenging.<p>At Coherence (withcoherence.com - I'm a cofounder), we believe that a new category anchored by tools like replit, AWS CodeCatalyst, and our products is the solution to this problem, because it does not have the same issues. Instead, it offers best-in-class versions of the same workflows and toolchains that teams are using now, while radically reducing the investment required to get there.<p>It's an exciting time in the DevOps world!
This feels like inventing a technology for the sake of it and then trying to fit a problem to it.<p>Abstracting over cloud resources is inherently very leaky. Yeah, S3 compliant buckets work, but that's the simplest example possible. Even then, if you're working at scale, you still need to keep in mind features like (AWS) Intelligent Tiering, GET/POST/PUT costs, cross-region costs. This can be the difference between a 15k and 150k bill, you don't want to abstract over it. What's the point of a cloud language if I have to care about the specifics if I'm doing something at scale with it? I can just keep using Java or Python and the respective SDKs.<p>I don't want to write all of my stack in a cloud programming language. Especially one that is completely new and not cross-compatible with any other language. This isn't just a small thing -- it's a complete dealbreaker. There's no tools, no libraries. It's been a decade since Nim has started development and look at its progress now with so much interest behind it. Creating PLs and compilers follows the 80/20% rule.. it will take mountains of work to even make the compiler truly optimized and usable, and that's a basic prerequisite.<p>The cloud simulator is cool.. but there's already localstack which will simulate AWS services much more faithfully. If you don't have faithful simulation (and you can't do that for every cloud service), you can't use the simulation for anything besides playing around anyway. In which case, why not have a dev/testing environment and kill two birds with one stone? There's no point to unit testing cloud things, that's basically all integration testing anyway. You can unit test the code that interfaces with the cloud using the same language-specific tools that have always been used.
I haven’t looked through everything, but I opened a random TS comparison:<p>Wing<p>let x = 1; // x is a num<p>let v = 23.6; // v is a num<p>let y = "Hello"; // y is a str<p>let z = true; // z is a bool<p>let w: any = 1; // w is an any<p>let q: num? = nil; // q is an optional num<p>TS:<p>const x: number = 1;<p>const v: number = 23.6;<p>const y: string = "Hello";<p>const z: boolean = true;<p>const w: any = 1;<p>const q: number? = undefined;<p>Except you’d never do that in TS unless you were being extra verbose (which you could with Wing too) because the types for x, y, and z are superfluous and don’t change the inferred type. So if you remove those types, the examples become identical (except for using const vs let).<p>Intentionally showing TS in a worse light than reality in a comparison is not a good look in terms of intellectual honesty.
I'm on the fence about this one. When I heard it was announced, and that it was created by none other than the creators of the amazing AWS CDK, I was really excited by what could be possible. Having worked on complex infra automation using CDK (we use it extensively for our open source project for analyzing security logs on AWS: <a href="https://github.com/matanolabs/matano">https://github.com/matanolabs/matano</a>), I was excited because of the room for improvement with an integration that is language-native.<p>But after having looked into the abstraction that Winglang, and other "infrastructure-from-code" providers have come up with, I'm admittedly very skeptical. As other have mentioned, cloud primitives are almost by nature a leaky abstraction with many bells and whistles to be tuned. So I'm not sure it is a good idea, or feasible in a complex production application, to build on these very high level primitives such as cloud.Queue without limiting yourself to the lowest common denominator of features. But perhaps this issue is solvable by creating a nicer SDK.<p>What bothers me the most is having to to write code in a completely new language, that kind of treats runtime code as a second class citizen to be embedded in a configuration oriented language that looks like Typescript with some magic added in. Imo, this is far too much friction and risk vs. the benefit that could come from something like this over using your language of choice along with CDK.<p>I'm still rooting for Wing, and hoping they can figure out these issues, because the problem they are solving is a massive one. I think Winglang has the potential to do for cloud, what Rust did for memory safety by doing smart things at compile time and enforcing policies that could easily be missed by developers. For example, automatically deriving least privilege and minimal permissions for all infrastructure could be a great way to improve security out of the box.
If anyone is interested in Infrastructure as Software, I also recommend giving Pulumi a try. I've been using Terraform for a couple of years, Pulumi for about a year and I think that Pulumi is on a completely different level.<p>It also supports higher level abstractions (Component Resources). For example: check out AWS EKS provider.
The example on the homepage is a good example of why I don't think I'd find this useful. Using Node or Go or whatever to create a file in an S3 bucket based on an incremented value from DynamoDB isn't <i>that</i> hard. The code necessary is maybe a few tens of lines using the official libraries. Actually setting up all the infrastructure to get it to work, with monitored quotas to check things won't fall over, with properly secured IAM profiles, etc is where the all of the pain lies for me.
This seems to fall into a common trap of making hard things easier at the cost of making easy things harder.<p>One thing to rule them all at the cost of an inferior language for actually writing code in.
The include their motivation in their language spec:<p>"What makes wing special? Traditional programming languages are designed around the premise of telling a single machine what to do. The output of the compiler is a program that can be executed on that machine. But cloud applications are distributed systems that consist of code running across multiple machines and which intimately use various cloud resources and services to achieve their business goals.<p>"Wing’s goal is to allow developers to express all pieces of a cloud application using the same programming language. This way, we can leverage the power of the compiler to deeply understand the intent of the developer and implement it with the mechanics of the cloud."
Software stacks keep becoming so unnecessarily complex. I suspect this approach will hide more stack details and therefore promote even more pico-services madness.
DAPR[1] comes at this problem from the other direction. It creates an abstract infra that any language can use<p>[1] <a href="https://dapr.io/" rel="nofollow">https://dapr.io/</a>
Looks like it just use Terraform behind the scene: <a href="https://docs.winglang.io/getting-started/installation" rel="nofollow">https://docs.winglang.io/getting-started/installation</a>
I believe in the advantages of using language based techniques for dealing with distributed systems, but this is buying into the AWS ideology. This ideology can be summarized that your application is composed of infinitely scalable functions which sounds great until you account for the overhead. Then, you wake up and realize you are being nickle'd and dime'd to death.
I may have only looked too quickly, but the cloud-ness of this looks like more of a library thing than something requiring first class language support.<p>On the language side, it would be helpful to have a comparison with other async-first runtimes (js, go) in order to understand how/whether the fundamentals here differ.
Why a new programming language instead of, for example, a cloud oriented Python library.<p>Is there a specific programming paradigm that this language brings to the table?
Reminds me of <a href="https://ballerina.io/" rel="nofollow">https://ballerina.io/</a><p>... which looks actually pretty nice, but I suspect the name of the project is a terrible marketing decision that will hold adoption back ¯\_(ツ)_/¯
I don't get it. Why we need a new language, when an Module for a language would do the job too?<p>NIH-Syndrom?<p>Why not just simply pre compile it to specific language modules?
Interesting. Reminds me of Pulumi that uses Python/Js to define cloud resources.
The differentiator is the simulator, that could be a huge advantage - you could test your terraform and app with a single tool.
No need for terratest and local lambda sim with AWS SAM.<p>However it does look very limited at the moment - we'll need more than just buckets and queues. And the more you add the more complicated things get. Look at Pulumi and what a mess it is to define an env (depends on, apply(), wait for resource etc etc).<p>Perhaps it should be a module/lib rather than a lang on its own.
How will I write complex functions? will I need to import py scripts from other files? odd.
Roadmap leads to a 404 and I can't find any information on what kind of cloud support I could expect from this. I don't really see a reason to care about this over something mature like Serverless or CloudFormation templates if it only supports AWS. I also don't necessarily see how well Cloudflare Workers / KV / D1 translates to AWS Lambda / DynamoDB / RDS so that I can write stuff once and get it working on both backends.
My future perfect "cloud" language has grammar for idioms like queues and counters. Ditto pubsub, logging, metrics.<p>And structured concurrency. Not async/await, promises, and so forth.<p>--<p>Along the lines of "we were promised jetpacks", I'm still stuck on 1990s era future perfect notions like software agents and grid computing. Like the cloudlet (vs applet, servlet) manifestation of Sun Computer's Jini and JXTA.
My main problem with uniform solutions like this (or Shuttle) is that they are losing one of the main strengths of distributed systems: the abiility to mix and match different technologies and platforms (both for development and deployment) in the same system.
I like the idea of creating languages that capture a specific problem really well and making them easier to reason about. At a glance, I couldn't understand why this language makes anything in the cloud easier to do. The front page should focus on what the language does better than others. From what I can tell by going deeper into the docs, the selling points are a unified API for cloud resources across different vendors, inflight functions, and the simulator. Hopefully this language continues to grow and becomes compelling enough to use instead of just TypeScript (which seems to be its closest relative)
its worth noting that the creator of Wing is Elad Ben-Israel - formerly the creator of AWS CDK which has by all accounts been quite popular in the AWS Infra-as-Code world. I kind of view Wing as "CDK++" - if CDK was such a success in flexibily defining and testing infrastructure, what could you do if you further merged in in your language?<p>i have no stake in Wing but it is a good example of the Self Provisioning Runtime thesis (<a href="https://swyx.io/self-provisioning-runtime" rel="nofollow">https://swyx.io/self-provisioning-runtime</a>)
I think there would be a lot of value in having an imperativ, very high level language for cloud workflows that abstracts the underlying implementation or even cloud provider away. Think something like "when authenicated user uploads file of type image: resize to width 800px and store in bucket user-images". Given the lack of specific references to S3, IAM or other concrete services, this could then be executed by different cloud providers.
How does this compare to Unison[0]? Aside from looking JavaScript-like.<p>Doesn't look statically typed at first glance, but the docs seem to imply it is [1]. Pretty interesting overall.<p>[0]: <a href="https://www.unison-lang.org" rel="nofollow">https://www.unison-lang.org</a>
[1]: <a href="https://docs.winglang.io/reference/spec#18-type-inference" rel="nofollow">https://docs.winglang.io/reference/spec#18-type-inference</a>
The example shown in the animation was one of the quickest yikes I've ever had for architecture.<p>SQS with minimal config into lambda. Alright, good luck.
Great works! Seeing the demo in the front page really makes me think of the cloud architecture as a whole may just be an operating system out of itself.<p>Heck, I once even thought of comparing microservices to microkernel in OS design and that might actually some make sense over time and time again.
[Wing team member here]
To get some more insight into why we're building Wing, you are welcome to read Elad's blog post: <a href="https://docs.winglang.io/blog" rel="nofollow">https://docs.winglang.io/blog</a>
The team is top notch (of CDK fame) found a non-trivial bug was assigned and fixed in 30 min. In general joy to interact with. Very strong focus on dev. experience. After a very subpar experience of building a very large enterprise project using AWS serverless stack Wing is the first thing that gives me hope that things can be way better.