13 ms·

Wing: A cloud-oriented programming language – request alpha access

261 points by xiaodai 4y ago

zdragnar 4y ago
This seems to fall into a common trap of making hard things easier at the cost of making easy things harder. One thing to rule them all at the cost of an inferior language for actually writing code in.
ITB 4y ago
Software stacks keep becoming so unnecessarily complex. I suspect this approach will hide more stack details and therefore promote even more pico-services madness.
- kovac 4y ago
  Isn't that what we've been doing for a while now. Invent problems that don't exist, give it a cool name and propose a new "solution" :p
OJFord 4y ago
Why is this a language, not just a framework for JavaScript or whatever? 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. I suppose I'm asking what are the language features that make Wing great for 'cloud', any `new Bucket()` etc. aside? 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 be another language? https://docs.winglang.io/reference/spec#02-design-tenets https://docs.winglang.io/reference/spec#02-design-tenets
- jakewins 4y ago
  It seems because of the compiler tool chain? Eg this language can be “compiled” to terraform manifests. To do that with JavaScript or python you’d need some really strong static analysis to work out what to do if the user, say, writes a function that returns a list of new buckets to create, or whatever. Eg the argument seems to be the ability to statically deduce the required underlying cloud resources the code is talking about
  - angio 4y ago
    On the other hand the example on the landing page looks very close to what I can do with Pulumi (in Typescript) already.
    - paulgb 4y ago
      I’m a fan/user of Pulumi, but this doesn’t feel similar to me. In Pulumi you write code that describes infrastructure, separate from the application layer code you’re deploying. This appears to be using application code to derive infrastructure config automatically. It’s a but like the https://www.shuttle.rs/ https://www.shuttle.rs/ approach. Edit: after taking a deeper look, a more accurate description might be that it allows you to embed application code within IAC.
      - zachrip 4y ago
        Pulumi has both, they have something very similar to what is being offered here: https://www.pulumi.com/docs/tutorials/cloudfx/ https://www.pulumi.com/docs/tutorials/cloudfx/
        paulgb 4y ago
        I did not know that, I stand corrected!
  - OJFord 4y ago
    But you can generate e.g. terraform manifests from any language without actually compiling (or transpiling) to it? That seems barely more than an implementation detail: I get .tf or whatever I want at the end of it, that's all I care about isn't it?
  - rmbyrro 4y ago
    If a library is provided for developers to express the cloud stuff (including custom types), then I believe zero or close to zero static analysis will be needed.
- dohman 4y ago
  re: Why is this a language, not just a framework for JavaScript or whatever? One product that's taking this approach is shuttle -> https://www.shuttle.rs/ https://www.shuttle.rs/ (disclaimer: I work there). It's built around Rust and not TS but we have some updates coming soon which is going to expand on this. We've been thinking about this DSL question for a while and it's pretty much a trade-off. By having your own language and parser you can build language primitives which get your close to your domain, as for example in the example you gave with HCL. It will be interesting to see where Wing goes with this concept, it could offer a great developer experience. For us, we've chosen to stick with a robust and performant programming language which is increasing in popularity and has enough meta-programming capabilities to make this 'infrastructure from code' paradigm feel natural - the framework blends in well with the language. The advantages of this for us is that users of the language experience a very small learning curve and they can also use incredible Rust libraries off-the-shelf. We can also piggy-back off the Rust compiler and ecosystem to provide an A-class developer experience (those compiler errors are amazing). We're excited to see more companies in this space - optimising for a beautiful developer experience.
  - mikercampbell 4y ago
    I hecking love the concept of shuttle. The only thing keeping me from using it is unfamiliarity with rust, but it's enough to make me rethink things. I think the future isn't as much Lo-code as much as it will be (and goshdarn should be) Lo-DevOps. There are so many advances in programming, like WASM for example, that will continue to cause this Lo-DevOps movement, but honestly, digging into the language, using the stuff that already is baked in for other existing business purposes. But things like encore.dev and shuttle.rs (I'm associated with neither) are just mind-blowingly straightforward with no language, infrastructure, or other cognitively burdening information.
    - zozbot234 4y ago
      > I hecking love the concept of shuttle. I'm not sure about it. If you're going to have Rust-specific deployment workflows, you should reuse the solutions that have been developed for the embedded ecosystem. There's no reason why "cargo flash" could not be extended to upload your binaries to the cloud, and support the same "probe run" workflow for remote logging and debugging.
- jchook 4y ago
  HCL in particular has so many annoying edge-case issues and limitations due to its immaturity that it becomes intractable beyond simple use cases. Thankfully Pulumi[0] allows me to write Terraform configuration in a language I know without reinventing the wheel. It feels like Pulumi's approach is better in every single way I can imagine. I simply do not see the reason for HCL whatsoever. [0] https://github.com/pulumi/pulumi https://github.com/pulumi/pulumi
  - substation13 4y ago
    What about the non-determinism, lack of sand-boxing and Turing-completeness of a real programming language?
    - jchook 4y ago
      What about the lack of a mature language server for code completion and at-your-fingertips documentation? What about the lack of mature tooling for static analysis, linting, code formatting, etc? What about the poor support for defaults and partial overrides on object-type (read: namespaced without redundant_underscore_thing_*) configuration directives? What about the very limited module capabilities? What about the limited set of deterministic functions available (e.g. you get base64, yaml, csv, and otherwise GLHF)?
    - duped 4y ago
      There's no reason the code can't be sandboxed, Turing-completeness is a feature not a bug (nor is undecidability a real problem), and non-deterministic behavior where it's undesirable is just a potential hazard in the real world. No system can avoid it unless that system never interacts with the outside world.
    - newaccount2021 4y ago
      Because those aren't real-world concerns??? HCL is its own language so Hashicorp can "own" the experience, tie you into an Enterprise toolchain, and scratch their "I've always wanted to build a language!" itch But it works and ops people love it because most ops people in industry today cannot even write a simple Python script. So...tools like Pulumi are actually out of their reach.
- no_wizard 4y ago
  Isn't that pulumi's angle? Its pure JS (well, written in TS and compiled to JS) that lets you leverage JS / TS for provisioning your infrastructure https://www.pulumi.com/ https://www.pulumi.com/
  - nirga 4y ago
    Not exactly, Pulumi is more like CDK. So code and infra provisioning is still separate
    - fishnchips 4y ago
      Not necessarily, at least in their JS SDK they have a clever way of actually compiling your Pulumi code directly into things like APIGW and handler Lambdas.
      - deleted 4y ago
        [deleted]
- Garlef 4y ago
  If I give you a function that I want you to deploy to a lambda. Can you do this with a pure JS library? No. Pulumi can do it but they have a compiler in the background. And you still need a lot of boilerplate devops stuff around it. So if you already need a compiler to do the packaging, etc. why stop there. A lot of other tooling problems go away. But yes, you'll be reinventing the wheel to some portion.
  - OJFord 4y ago
    > If I give you a function that I want you to deploy to a lambda. Can you do this with a pure JS library? No. I'm not sure if you're making some distinction I'm not following, but yes? One of them is called 'AWS SDK for JavaScript'?
    - nirga 4y ago
      Not exactly, cause you need to manage state or something (you don’t want to reprovision every time you run the code probably). So you’ll need to do some sort of “compilation”
      - OJFord 4y ago
        How does compilation remove the need to manage state? I'm not at all precious about JS, let's do it with the AWS SDK for C++ library instead?
    - Garlef 4y ago
      Sry. I should have been more explicit: Let's say you are writing JS and you have `const handler = ...` You can not do something like `const lambda = deployLambda(handler)` on the next line. Instead you need a deployment package. And to build this, you need to leave JS and involve some CI code and some IaC tool. But wing enables you to just do that. (seemingly, I've not tried it yet)
- ashiban 4y ago
  > Why is this a language, not just a framework for JavaScript or whatever? I'm one of the founders of Klotho (https://klo.dev https://klo.dev), and we're in the camp of expanding existing programming languages with cloud native building blocks. We’re building Klotho in that spirit. There's a few reasons to opt for using a compiler rather than SDKs: - Being able to catch errors as early in the development process as possible, rather than in runtime or production. - Being able to use existing language features and popular libraries. For example, we’re able to turn a standard Node.js EventEmitter into an asynchronous invocation on a different compute engine (basically, spinning off an AWS Lambda invocation or adding a message to an SQS queue). Not only does this reduce the barrier for entry, but it also often enables fast iteration time by supporting a local development workflow (no more waiting for deployments between changes). - Being able to trim the runtime to a minimal set that is necessary for that execution unit alone. In SDK land, you include the entire library, which means more lines of code to reason about in a live-site incident, alternatively going fully granular means developers now need to reason about what to include and what not to. Compilers, and specifically static analytics can reason about that automatically. - Being able to use all of that logic across languages: rather than having to write a separate SDK per language, we can write a single tool that works the same across multiple languages. In addition to aesthetic niceness, that could in the future let us handle polyglot code bases in a more cohesive way. We support JavaScript/TypeScript/Python, and are developing Golang/C# support
- awinter-py 4y ago
  also terraform has a lot of ergonomic warts from being a language not an sdk -- for example: the minimum unit of reuse is a folder with a file in it, and loops and conditionals were impossible for a while pulumi is the 'terraform as a library' option, haven't tried but it makes sense
  - mountainriver 4y ago
    Yeah Pulumi makes a lot more sense than terraform and I find myself wildly more productive in it
  - jacurtis 4y ago
    These are some weak arguments against Terraform. > loops and conditionals were impossible for a while Yeah they were, in what version was it? 0.11 and 0.12 I think when those were added? But those have been there for a while. It was admittedly beta during the time and under active development. Regardless, its a moot point now, so not worth discussing. Still, conditional statements are limited to ternary style operators as opposed to complex multi-line if-statements. That would be a stronger argument to make that I could agree with. However, this was a design decision made by the team not a technical limitation. The goal is not to make complex logic decisions inside the declarative nature of Terraform since it takes you away from the declarative (documentation-style) markup that it stands for. Between using locals and modules and data sources you can still accomplish almost anything despite not having multi-line conditionals. The end result is cleaner, which is a design decision that was made. > the minimum unit of reuse is a folder with a file in it I don't really understand the problem with this. This is essentially how Go(lang) is too and other full blown languages. Its another design decision and not really a limitation. There are significant advantages to this, for example modules are folders and everything inside of them gets compressed into a single unit for replication purposes. Within that folder you can break your code up however you wish to improve readability and maintainability. This gives utmost flexibility to the author, and standardizes the consumption for the consumer. You can import a module and use it as a "packaged" unit without needing to understand how the author created it. These just sound like opinions you have more than "ergonomic warts". If anything I could argue that both of these design decisions of the language actually make it more ergonomic to use (and consume) not less. Its also worth noting that I mentioned multiple times authors/creators and consumers. Terraform is very much designed around being consumed and read, almost like documentation. If you talk to Hashicorp this is a huge motivation behind the DSL that is HCL. It was designed that someone who has minimal Terraform knowledge could use modules to create powerful infrastructure within a company. This is how we use it in our company. The SRE/Platform Engineers (where I work) build very advanced, complex, and powerful modules that are easy to consume with a handful of variables. We have developers that can spend a few hours learning Terraform and know enough to build production infrastructure within the company that is built to our design standards and security compliance requirements. They often don't even have to know what that is, they just declare a network, a database, and a cluster of compute with a handful of parameters that are auto-documented and they end up with some incredible infrastructure as a result. This is what Hashicorp is designing Terraform around. If you meet with them or go to their conferences, this is the direction and purpose of Terraform and how they designed it. A handful of Terraform experts at a company can create modules that are consumed by developers that have minimal knowledge of Infrastructure or Terraform. Its a powerful system.
maxmcd 4y ago
Love a powerful abstraction. This creates equal feelings of "wow how easy" and "oh no the $$$".
RcouF1uZ4gsC 4y ago
Why a new programming language instead of, for example, a cloud oriented Python library. Is there a specific programming paradigm that this language brings to the table?
mikepurvis 4y ago
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. 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.
- deleted 4y ago
  [deleted]
- eladbenisrael 4y ago
  [Wing team member here] Wing has a concept of `inflight` which you can think of as a "remote async function". It's an `async` function that can be executed on a remote system, such as inside a container fleet or on a FaaS. Inflight functions can interact naturally with cloud resources around them (by simply calling inflight methods on the resources e.g. `bucket.put()`). The compiler analyses these interactions and inverts the control over to the resources to take care of the mechanics like wiring deployment information, synthesizing security policies and anything else that can be deduced from this high level intent. Defining the cloud architecture of the app and being able to naturally crossing these distributed boundaries is the essence of what we call "cloud-oriented programming", and where we think a lot of the friction and pain of the cloud comes from today: every time I need to interact with "The Cloud", I leave the safety and comfort of my compiler, and I am out in the wild having to understand all the mechanics and layers involved. Almost all existing languages/compilers take a fundamental assumption that the entire program runs inside a single machine. This is, in our view, the impedance mismatch of cloud development today. This is where we believe language innovation can dramatically reduce the cognitive load and barrier to entry for building and delivering cloud applications that fully take advantage of the cloud. Inflight functions and resources are only the first step. Think first-class support for things like defining and consuming API endpoints, writing distributed workflows, emitting metrics, raising alarms and other things you would expect from your friendly neighborhood cloud programming language.
Thaxll 4y ago
Looks like it just use Terraform behind the scene: https://docs.winglang.io/getting-started/installation https://docs.winglang.io/getting-started/installation
salmo 4y ago
What I’m the world is a cloud-oriented language? Looks at page. Oooh. This is JS with a schmancy library. That’s cool, I guess… for someone.
goodpoint 4y ago
I'd rather have grassroots language that does not run on any cloud service.
webstrand 4y ago
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.
- danuker 4y ago
  > Hi Nunya Biznis! What's your email address?This question is required. * nunya.biznis@mailinator.com Check out what they sent: https://www.mailinator.com/v4/public/inboxes.jsp?to=nunya.biznis https://www.mailinator.com/v4/public/inboxes.jsp?to=nunya.bi...
  - smcl 4y ago
    "Muahahaha"? Hm ok
    - danuker 4y ago
      Ugh. People deleted the original message. I guess we can't have nice things. But you can register with a different Mailinator address.
      - deleted 4y ago
        [deleted]
      - smcl 4y ago
        AHhh I see :D No worries, I just clicked it out of curiosity and was a little confused that someone would use this in their marketing copy :D
  - dmarlow 4y ago
    This link hijacked my back navigation and I couldn't get back to hn. Sigh.
- bfeynman 4y ago
  That is some next level tin foil hat wearing
MontyCarloHall 4y ago
New languages == zero ecosystem—no third-party libraries, community discussion (e.g. StackOverflow), real-world repositories, etc. 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. 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.
- hackerman123469 4y ago
  Yeah, the example looks like an API demonstration rather than a language demonstration. I would have assumed the API functions were keyword oriented IF it was a programming language.
- indymike 4y ago
  > A brand new language thus must be extremely compelling at a syntactical level to make it worth leaving behind existing ecosystems. For many niche languages the runtime or standard library is the main show and syntax is built around making the standard library more accessible. In this case it looks like they've built a standard library that abstracts away a lot of cloud components (i.e. SNS, S3) and made them very easy to call. This one actually looks like they may be on to something because of the level of inconsistency between cloud apis. > Everything in the demo code could easily be implemented as a Python or JavaScript API. There are very few domains where this is not true.
  - MontyCarloHall 4y ago
    >This one actually looks like they may be on to something because of the level of inconsistency between cloud apis. I still don't see why this requires a totally new language. You could easily write a high-level API in a commonly used language that under the hood generates cloud provider-specific API calls. Indeed, this is exactly what Pulumi does, with API bindings to many commonly used languages. There is no need for a custom runtime, much less a new language specifically designed for that runtime.
mihau 4y ago
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. It also supports higher level abstractions (Component Resources). For example: check out AWS EKS provider.
- Bombthecat 4y ago
  Is there enterprise support for pulumi?
  - jaxxstorm 4y ago
    I work on the solutions engineer team for Pulumi. We absolutely offer enterprise support, I'm one of the engineers that is part of that team. If you'd like to discuss further, you can contact me on lbriggs[at]pulumi.com
- mountainriver 4y ago
  Yeah Pulumi is a much better idea than this, it’s already production ready and you can use industry standard languages
- agtorre 4y ago
  Pulumi is great, but winglang is a level of abstraction higher than it or Terraform. I think all 3 projects have benefits for different use-cases
onion2k 4y ago
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 that 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.
- bfeynman 4y ago
  The latter part is exactly what this is going to be doing. Same way that in AWS CDK you can get higher level constructs that can vend more secure resources. The goal is to make that even more fluent, across different infra deployment architectures
hestefisk 4y ago
What’s the point of “bring cloud”?
- hackerman123469 4y ago
  Going to assume "cloud" is the package/module and "bring" is similar to something like "import" etc. so it's probably because "cloud" in this case is a module/package that you need to import to use, so the language itself isn't actually cloud-oriented, but rather the standard framework (if you can call it that) is cloud-oriented.
  - hestefisk 4y ago
    It seems as useful as “using System;” in c#
pelorat 4y ago
Looks like typescript.
gwn7 4y ago
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. Related: https://twitter.com/garybernhardt/status/1603498230125588480 https://twitter.com/garybernhardt/status/1603498230125588480 https://twitter.com/garybernhardt/status/600783770925420546 https://twitter.com/garybernhardt/status/600783770925420546 https://geekandpoke.typepad.com/geekandpoke/2011/03/architectural-best-practices.html https://geekandpoke.typepad.com/geekandpoke/2011/03/architec...
- specialist 4y ago
  #2 - I once spent 18 months convincing my teammates to move our hottest data set from DynamoDB to RAM. Next time, I won't bother. #3 - Heh. The "N+1" architecture. However many layers your architectural design methodology has, ours has one more. (h/t Spinal Tap). Is that Twitter you? Good stuff. Like the unique URL for posting CSVs.
  - gwn7 4y ago
    > #2 - I once spent 18 months convincing my teammates to move our hottest data set from DynamoDB to RAM. Next time, I won't bother. Yeah, don't bother. People don't want simplicity. The majority of our tribe are masochists haha > #3 - Heh. The "N+1" architecture. However many layers your architectural design methodology has, ours has one more. (h/t Spinal Tap). Exactly > Is that Twitter you? Good stuff. Like the unique URL for posting CSVs. Oh no I'm not Gary, sorry =)
Hamuko 4y ago
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.
davidjfelix 4y ago
The example shown in the animation was one of the quickest yikes I've ever had for architecture. SQS with minimal config into lambda. Alright, good luck.
- swyx 4y ago
  what is wrong/what can go wrong with hooking up SQS to Lambda? (real question, not trolling)
  - davidjfelix 4y ago
    Nothing really goes "wrong" but it has a lot of historic footguns and was designed around finite worker polling not ultra-wide scaling lambdas. IMO, when most people think they want SQS, they actually want SNS. Rarely, Kinesis Streams is what they wanted. SQS + Lambda is an "almost never" when you're building something greenfield. It's a complexity you shouldn't take as a default, but have as an option, IMO. So a quick aside: SQS is one of the oldest async "serverless" services in AWS. Historically, web applications ran into issues with large processing jobs so they would offload this work from the web server, which would synchronously handle requests, and instead do the work in an async manner that aligned with capacity. Job Queues or were designed to have workers pull messages in a FIFO manner and then capacity for those jobs could be planned separate from web capacity. Major contender in this space was RabbitMQ and something like Rails' ActiveJob, which is an ideal user of SQS. So SQS is valuable but why isn't it here? Well, the short answer is: it is valuable, but in the conditions laid out (use with lambda) there are significantly better options. So lets look at the pattern they're using and talk about it. They're calling SQS a queue here, which is an easy mistake to make since it's in the name. I'm going to just toss an asterisk on it for a few reasons; first, because lambda will consume more quickly than most producers so it won't really sit idly for the retenetion window; second, because SQS (low scale) and single instance MQs like Rabbit will handle messages in a FIFO manner, but SQS is a service and abstracts scale away. At some point, the FIFO aspect of it becomes "best effort" unless you configure it to be FIFO (really avoid doing this). To me, this is a *major* design consideration and arbitrarily calling things a queue when really it's more of a pubsub is a bit more than just pedantry. At scale you *will* see out of order, potentially duplicated messages with SQS without FIFO on. Handling duplicates should be at the front of your mind. So... we're using a pubsub pattern which is still maybe pedantically different from a queue, you're still asking why is that so bad? It works with lambda right? Yeah it does. Here's a list of services that work with lambda in a pubsub manner and would allow a user to publish a message and invoke an async lambda with that message: * Kinesis Streams * SQS * SNS * Event bridge * Lambda (use Invoke and set "async" to true) * DynamoDB / S3 (this one is abnormal but still possible -- there are more that I'd categorize here but these are common) A lot of people look at this list and quickly eliminate options. DynamoDB table entries and s3 object drops are clearly misuses or special case jobs (good call). We want a DLQ via config not writing it ourselves so async invoke lambdas are out (bad call - normally DLQs are /dev/null but more expensive). Kinesis streams has an idle cost (true but lower than most think) and SNS and Eventhub aren't reliable or don't hold messages ** (this is false). The assumption is that SQS is the only remaining option that has: * Reliable delivery * Dead letter queue * Roughly ordered delivery * Isn't a "write it ourselves" or "misuse" of service (sorry dynamo/s3). But... that's not the only service that does that. SNS and EventBridge both meet those qualifications. That surprises a lot of people. Both of these services have at-least-once semi-ordered delivery (same as SQS) with lambda and feature retry and DLQs. They also have a really really really huge feature for any operator who runs big serverless pipelines: * They're emitter/publisher focused, not subscriber focused. You create a queue for every notified party, you create an SNS topic for every notifying item. This means you can add a secondary consumer (like... a network tap?) and see messages flowing through the system without changing the system. This is huge for debugging. At this point you might say but what if I want disparate services to be able to consume from the SQS queue but steal each others work? Well... don't use lambda -- the lambda is going to steal all the work -- it can scale up to your account limit without adding more settings that aren't set here. Mostly SQS and worker queues aren't what you want if you want lambda. The real limit for burst-ability is set at a fairly large account limit level. There are *some* instances where queuing might be right, but at those scales you'd actually be asking if maybe Kinesis Streams is a better choice (usually it is). TLDR: SQS is usually not the tool you want with lambda as a consumer. It works, but SNS or Kinesis are much more common. SQS comes with a lot of knobs and whistles that can dramatically run up your bill when using lambda with naive settings (I've seen this a lot, where the DLQ is setup for redrive and it just fail loops). Hope this helps a bit. Note: I have about 5 years experience working with serverless/event driven application architecture.
dadadad100 4y ago
DAPR[1] comes at this problem from the other direction. It creates an abstract infra that any language can use [1] https://dapr.io/ https://dapr.io/
mcluck 4y ago
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)
wiremine 4y ago
The include their motivation in their language spec: "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. "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."
tuananh 4y ago
what makes it a cloud language? what is cloud language even?
specialist 4y ago
My future perfect "cloud" language has grammar for idioms like queues and counters. Ditto pubsub, logging, metrics. And structured concurrency. Not async/await, promises, and so forth. -- 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.
- ekeren 4y ago
  Disclaimer, I work at Monada, the company behind wing I completely agree with you, a language that considers cloud development as a first class citizen must embrace something like open-telemetry for distributed logging (spans, traces, metrics, logs). When you log something or measure something in your code it should always be part of some distributed trace. We want to embrace this thinking for localhost development and allow our customer to choose their APM provider when they deploy. In a sense we don't see a difference between a cloud resource that is called logger (can be implemented by DataDog, New Relic, Coralogix, etc) and a cloud resource that is called a Queue (can be implemented by SQS, Redis, RabbitMq, etc...) Also, as you mentioned, because in practice all the `inflight` (https://docs.winglang.io/concepts/inflights https://docs.winglang.io/concepts/inflights) code is async by nature, the language should wait for any API call to be resolved (e.g. "await") by default, deferring an API call is the exception
rexreed 4y ago
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.
- 323 4y ago
  Interesting. Maybe also add a "reliability" cost, so something like S3 would be more reliable than a more complex system like RedShift.
  - rexreed 4y ago
    Exactly. The cloud orientation that differentiates from a non-cloud orientation is not simply a matter of execution abstraction -- that is already handled through libraries and scripts, etc. What would be cloud-oriented are the economic aspects of the cloud. I usually tell people that the cloud is really two separate ideas: the abstraction of infrastructure and computing on the one hand (what used to be called "grid computing") and the economic model of pay-per-consumption, pay-per-use, pay-per-service that shifts capital expenses (the stuff you own and have already paid for that depreciates over time) to operating expenses (stuff you have to keep paying to use). The CIOs like the technology on-demand, easy scale-up/scale-down aspects of the cloud while the CFOs like the idea of shifting CapEx to OpEx and pay as you go aspects of the cloud.
- CathalMullan 4y ago
  Since Wing compiles to Terraform, you should be able to manually run Infracost (https://www.infracost.io https://www.infracost.io) to get an idea of costs. Having that capability baked into the language/compiler would be a great addition.
  - dj_mc_merlin 4y ago
    Infracost is OK. It's not great, it's OK. To not be meaningless, it's not always accurate, still has some bugs, doesn't cover everything. But it's still the best tool in its class and I use it. If the value proposition of a cloud language included "infracost but better", I might be more inclined to listen.
quanticle 4y ago
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 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. Kind of hard to do that when all the source code is closed. [1]: https://github.com/orgs/winglang/projects/1 https://github.com/orgs/winglang/projects/1 [2]: https://github.com/orgs/winglang/projects/3 https://github.com/orgs/winglang/projects/3 [3]: https://github.com/winglang/wing https://github.com/winglang/wing
- swyx 4y ago
  i think this might have been posted without their involvement, its possible they werent ready to launch yet
  - linhns 4y ago
    If they are not ready then the website should say that. Here it seems like they are really ready
- shaiber 4y ago
  [Wing team member here] Sorry about the 404s. They are displayed to anyone who has not been given access to the repo yet. You are welcome to request access, and I promise to let you in very quickly. The reason the repo is not yet completely open is that we want a way to engage more with our first community members and get some data about their needs.
TruthWillHurt 4y ago
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. 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). 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.
CRidge 4y ago
Is this "cloud oriented" or "AWS oriented"?
dj_mc_merlin 4y ago
This feels like inventing a technology for the sake of it and then trying to fit a problem to it. 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. 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. 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.
- cmckn 4y ago
  > Yeah, S3 compliant buckets work, but that's the simplest example possible. Agree; you can’t just say “give me a queue”. You need to tune in-flight messages, processing times, FIFO or not, dead letters — the list goes on. These details are not 1:1 for different clouds, and they can’t be ignored for anything beyond a PoC. If I need to mess with all that in Wing…I could just use the AWS SDK. I can also trust that the SDK has the complete, latest feature set.
  - shaiber 4y ago
    [Wing team member here] We feel that the cloud has matured to a point where the basic services have enough in common with each other to allow us to successfully abstract their _functional_ parts. We do not abstract away the non-functional ones. You are welcome to check out the implementation of the standard library on GitHub and let us know what you feel is missing in the different abstractions.
swyx 4y ago
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? i have no stake in Wing but it is a good example of the Self Provisioning Runtime thesis (https://swyx.io/self-provisioning-runtime https://swyx.io/self-provisioning-runtime)
rco8786 4y ago
The example appears to be valid Javascript. I’m not saying it doesn’t look interesting or useful. But, “Why not Javascript?”
progx 4y ago
I don't get it. Why we need a new language, when an Module for a language would do the job too? NIH-Syndrom? Why not just simply pre compile it to specific language modules?
vlovich123 4y ago
I haven’t looked through everything, but I opened a random TS comparison: Wing let x = 1; // x is a num let v = 23.6; // v is a num let y = "Hello"; // y is a str let z = true; // z is a bool let w: any = 1; // w is an any let q: num? = nil; // q is an optional num TS: const x: number = 1; const v: number = 23.6; const y: string = "Hello"; const z: boolean = true; const w: any = 1; const q: number? = undefined; 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). Intentionally showing TS in a worse light than reality in a comparison is not a good look in terms of intellectual honesty.
- pixel_tracing 4y ago
  Wing looks more like swift to me
mathgladiator 4y ago
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.
- mikepurvis 4y ago
  May also wake up and discover the realities of vendor lock-in, and having little or no story for offline development.
  - intelVISA 4y ago
    Unfortunately, there is no awakening: you look over at your AWS bill and triple-redundant HA K8s cluster that serves your 3kb SPA blog to 3 users a month. This is the future.
zoomzoom 4y ago
This is one of the more sophisticated and cool of the "Self Provisioning Runtime" concepts that have emerged in the last few years (https://swyx.io/self-provisioning-runtime https://swyx.io/self-provisioning-runtime). Some of the others: - https://www.pulumi.com/docs/tutorials/cloudfx/ https://www.pulumi.com/docs/tutorials/cloudfx/ - https://www.serverless.com/cloud https://www.serverless.com/cloud - https://www.shuttle.rs/ https://www.shuttle.rs/ - https://encore.dev https://encore.dev 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. 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. It's an exciting time in the DevOps world!
BerislavLopac 4y ago
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.
qaq 4y ago
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.
shaeqahmed 4y ago
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: https://github.com/matanolabs/matano https://github.com/matanolabs/matano), I was excited because of the room for improvement with an integration that is language-native. 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. 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. 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.
simplify 4y ago
How does this compare to Unison[0]? Aside from looking JavaScript-like. Doesn't look statically typed at first glance, but the docs seem to imply it is [1]. Pretty interesting overall. [0]: https://www.unison-lang.org https://www.unison-lang.org [1]: https://docs.winglang.io/reference/spec#18-type-inference https://docs.winglang.io/reference/spec#18-type-inference
stevefan1999 4y ago
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. 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.
Aaronstotle 4y ago
This seems like a great way to give cloud providers a lot of your money
z3t4 4y ago
Are the cloud functions guarnteed to succeed?
wolframhempel 4y ago
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.
shaiber 4y ago
[Wing team member here] To get some more insight into why we're building Wing, you are welcome to read Elad's blog post: https://docs.winglang.io/blog https://docs.winglang.io/blog
tomcam 4y ago
That animation on the home page is sick af
emmanueloga_ 4y ago
Reminds me of https://ballerina.io/ https://ballerina.io/ ... which looks actually pretty nice, but I suspect the name of the project is a terrible marketing decision that will hold adoption back ¯\_(ツ)_/¯

261 points by xiaodai 4y ago

This seems to fall into a common trap of making hard things easier at the cost of making easy things harder. One thing to rule them all at the cost of an inferior language for actually writing code in.

ITB 4y ago

Software stacks keep becoming so unnecessarily complex. I suspect this approach will hide more stack details and therefore promote even more pico-services madness.

kovac 4y ago
Isn't that what we've been doing for a while now. Invent problems that don't exist, give it a cool name and propose a new "solution" :p

OJFord 4y ago

Why is this a language, not just a framework for JavaScript or whatever? 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. I suppose I'm asking what are the language features that make Wing great for 'cloud', any `new Bucket()` etc. aside? 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 be another language? https://docs.winglang.io/reference/spec#02-design-tenets https://docs.winglang.io/reference/spec#02-design-tenets

jakewins 4y ago
It seems because of the compiler tool chain? Eg this language can be “compiled” to terraform manifests. To do that with JavaScript or python you’d need some really strong static analysis to work out what to do if the user, say, writes a function that returns a list of new buckets to create, or whatever. Eg the argument seems to be the ability to statically deduce the required underlying cloud resources the code is talking about
- angio 4y ago
  On the other hand the example on the landing page looks very close to what I can do with Pulumi (in Typescript) already.
  - paulgb 4y ago
    I’m a fan/user of Pulumi, but this doesn’t feel similar to me. In Pulumi you write code that describes infrastructure, separate from the application layer code you’re deploying. This appears to be using application code to derive infrastructure config automatically. It’s a but like the https://www.shuttle.rs/ https://www.shuttle.rs/ approach. Edit: after taking a deeper look, a more accurate description might be that it allows you to embed application code within IAC.
    - zachrip 4y ago
      Pulumi has both, they have something very similar to what is being offered here: https://www.pulumi.com/docs/tutorials/cloudfx/ https://www.pulumi.com/docs/tutorials/cloudfx/
      - paulgb 4y ago
        I did not know that, I stand corrected!
- OJFord 4y ago
  But you can generate e.g. terraform manifests from any language without actually compiling (or transpiling) to it? That seems barely more than an implementation detail: I get .tf or whatever I want at the end of it, that's all I care about isn't it?
- rmbyrro 4y ago
  If a library is provided for developers to express the cloud stuff (including custom types), then I believe zero or close to zero static analysis will be needed.
dohman 4y ago
re: Why is this a language, not just a framework for JavaScript or whatever? One product that's taking this approach is shuttle -> https://www.shuttle.rs/ https://www.shuttle.rs/ (disclaimer: I work there). It's built around Rust and not TS but we have some updates coming soon which is going to expand on this. We've been thinking about this DSL question for a while and it's pretty much a trade-off. By having your own language and parser you can build language primitives which get your close to your domain, as for example in the example you gave with HCL. It will be interesting to see where Wing goes with this concept, it could offer a great developer experience. For us, we've chosen to stick with a robust and performant programming language which is increasing in popularity and has enough meta-programming capabilities to make this 'infrastructure from code' paradigm feel natural - the framework blends in well with the language. The advantages of this for us is that users of the language experience a very small learning curve and they can also use incredible Rust libraries off-the-shelf. We can also piggy-back off the Rust compiler and ecosystem to provide an A-class developer experience (those compiler errors are amazing). We're excited to see more companies in this space - optimising for a beautiful developer experience.
- mikercampbell 4y ago
  I hecking love the concept of shuttle. The only thing keeping me from using it is unfamiliarity with rust, but it's enough to make me rethink things. I think the future isn't as much Lo-code as much as it will be (and goshdarn should be) Lo-DevOps. There are so many advances in programming, like WASM for example, that will continue to cause this Lo-DevOps movement, but honestly, digging into the language, using the stuff that already is baked in for other existing business purposes. But things like encore.dev and shuttle.rs (I'm associated with neither) are just mind-blowingly straightforward with no language, infrastructure, or other cognitively burdening information.
  - zozbot234 4y ago
    > I hecking love the concept of shuttle. I'm not sure about it. If you're going to have Rust-specific deployment workflows, you should reuse the solutions that have been developed for the embedded ecosystem. There's no reason why "cargo flash" could not be extended to upload your binaries to the cloud, and support the same "probe run" workflow for remote logging and debugging.
jchook 4y ago
HCL in particular has so many annoying edge-case issues and limitations due to its immaturity that it becomes intractable beyond simple use cases. Thankfully Pulumi[0] allows me to write Terraform configuration in a language I know without reinventing the wheel. It feels like Pulumi's approach is better in every single way I can imagine. I simply do not see the reason for HCL whatsoever. [0] https://github.com/pulumi/pulumi https://github.com/pulumi/pulumi
- substation13 4y ago
  What about the non-determinism, lack of sand-boxing and Turing-completeness of a real programming language?
  - jchook 4y ago
    What about the lack of a mature language server for code completion and at-your-fingertips documentation? What about the lack of mature tooling for static analysis, linting, code formatting, etc? What about the poor support for defaults and partial overrides on object-type (read: namespaced without redundant_underscore_thing_*) configuration directives? What about the very limited module capabilities? What about the limited set of deterministic functions available (e.g. you get base64, yaml, csv, and otherwise GLHF)?
  - duped 4y ago
    There's no reason the code can't be sandboxed, Turing-completeness is a feature not a bug (nor is undecidability a real problem), and non-deterministic behavior where it's undesirable is just a potential hazard in the real world. No system can avoid it unless that system never interacts with the outside world.
  - newaccount2021 4y ago
    Because those aren't real-world concerns??? HCL is its own language so Hashicorp can "own" the experience, tie you into an Enterprise toolchain, and scratch their "I've always wanted to build a language!" itch But it works and ops people love it because most ops people in industry today cannot even write a simple Python script. So...tools like Pulumi are actually out of their reach.
no_wizard 4y ago
Isn't that pulumi's angle? Its pure JS (well, written in TS and compiled to JS) that lets you leverage JS / TS for provisioning your infrastructure https://www.pulumi.com/ https://www.pulumi.com/
- nirga 4y ago
  Not exactly, Pulumi is more like CDK. So code and infra provisioning is still separate
  - fishnchips 4y ago
    Not necessarily, at least in their JS SDK they have a clever way of actually compiling your Pulumi code directly into things like APIGW and handler Lambdas.
    - deleted 4y ago
      [deleted]
Garlef 4y ago
If I give you a function that I want you to deploy to a lambda. Can you do this with a pure JS library? No. Pulumi can do it but they have a compiler in the background. And you still need a lot of boilerplate devops stuff around it. So if you already need a compiler to do the packaging, etc. why stop there. A lot of other tooling problems go away. But yes, you'll be reinventing the wheel to some portion.
- OJFord 4y ago
  > If I give you a function that I want you to deploy to a lambda. Can you do this with a pure JS library? No. I'm not sure if you're making some distinction I'm not following, but yes? One of them is called 'AWS SDK for JavaScript'?
  - nirga 4y ago
    Not exactly, cause you need to manage state or something (you don’t want to reprovision every time you run the code probably). So you’ll need to do some sort of “compilation”
    - OJFord 4y ago
      How does compilation remove the need to manage state? I'm not at all precious about JS, let's do it with the AWS SDK for C++ library instead?
  - Garlef 4y ago
    Sry. I should have been more explicit: Let's say you are writing JS and you have `const handler = ...` You can not do something like `const lambda = deployLambda(handler)` on the next line. Instead you need a deployment package. And to build this, you need to leave JS and involve some CI code and some IaC tool. But wing enables you to just do that. (seemingly, I've not tried it yet)
ashiban 4y ago
> Why is this a language, not just a framework for JavaScript or whatever? I'm one of the founders of Klotho (https://klo.dev https://klo.dev), and we're in the camp of expanding existing programming languages with cloud native building blocks. We’re building Klotho in that spirit. There's a few reasons to opt for using a compiler rather than SDKs: - Being able to catch errors as early in the development process as possible, rather than in runtime or production. - Being able to use existing language features and popular libraries. For example, we’re able to turn a standard Node.js EventEmitter into an asynchronous invocation on a different compute engine (basically, spinning off an AWS Lambda invocation or adding a message to an SQS queue). Not only does this reduce the barrier for entry, but it also often enables fast iteration time by supporting a local development workflow (no more waiting for deployments between changes). - Being able to trim the runtime to a minimal set that is necessary for that execution unit alone. In SDK land, you include the entire library, which means more lines of code to reason about in a live-site incident, alternatively going fully granular means developers now need to reason about what to include and what not to. Compilers, and specifically static analytics can reason about that automatically. - Being able to use all of that logic across languages: rather than having to write a separate SDK per language, we can write a single tool that works the same across multiple languages. In addition to aesthetic niceness, that could in the future let us handle polyglot code bases in a more cohesive way. We support JavaScript/TypeScript/Python, and are developing Golang/C# support
awinter-py 4y ago
also terraform has a lot of ergonomic warts from being a language not an sdk -- for example: the minimum unit of reuse is a folder with a file in it, and loops and conditionals were impossible for a while pulumi is the 'terraform as a library' option, haven't tried but it makes sense
- mountainriver 4y ago
  Yeah Pulumi makes a lot more sense than terraform and I find myself wildly more productive in it
- jacurtis 4y ago
  These are some weak arguments against Terraform. > loops and conditionals were impossible for a while Yeah they were, in what version was it? 0.11 and 0.12 I think when those were added? But those have been there for a while. It was admittedly beta during the time and under active development. Regardless, its a moot point now, so not worth discussing. Still, conditional statements are limited to ternary style operators as opposed to complex multi-line if-statements. That would be a stronger argument to make that I could agree with. However, this was a design decision made by the team not a technical limitation. The goal is not to make complex logic decisions inside the declarative nature of Terraform since it takes you away from the declarative (documentation-style) markup that it stands for. Between using locals and modules and data sources you can still accomplish almost anything despite not having multi-line conditionals. The end result is cleaner, which is a design decision that was made. > the minimum unit of reuse is a folder with a file in it I don't really understand the problem with this. This is essentially how Go(lang) is too and other full blown languages. Its another design decision and not really a limitation. There are significant advantages to this, for example modules are folders and everything inside of them gets compressed into a single unit for replication purposes. Within that folder you can break your code up however you wish to improve readability and maintainability. This gives utmost flexibility to the author, and standardizes the consumption for the consumer. You can import a module and use it as a "packaged" unit without needing to understand how the author created it. These just sound like opinions you have more than "ergonomic warts". If anything I could argue that both of these design decisions of the language actually make it more ergonomic to use (and consume) not less. Its also worth noting that I mentioned multiple times authors/creators and consumers. Terraform is very much designed around being consumed and read, almost like documentation. If you talk to Hashicorp this is a huge motivation behind the DSL that is HCL. It was designed that someone who has minimal Terraform knowledge could use modules to create powerful infrastructure within a company. This is how we use it in our company. The SRE/Platform Engineers (where I work) build very advanced, complex, and powerful modules that are easy to consume with a handful of variables. We have developers that can spend a few hours learning Terraform and know enough to build production infrastructure within the company that is built to our design standards and security compliance requirements. They often don't even have to know what that is, they just declare a network, a database, and a cluster of compute with a handful of parameters that are auto-documented and they end up with some incredible infrastructure as a result. This is what Hashicorp is designing Terraform around. If you meet with them or go to their conferences, this is the direction and purpose of Terraform and how they designed it. A handful of Terraform experts at a company can create modules that are consumed by developers that have minimal knowledge of Infrastructure or Terraform. Its a powerful system.

maxmcd 4y ago

Love a powerful abstraction. This creates equal feelings of "wow how easy" and "oh no the $$$".

RcouF1uZ4gsC 4y ago

Why a new programming language instead of, for example, a cloud oriented Python library. Is there a specific programming paradigm that this language brings to the table?

mikepurvis 4y ago

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

deleted 4y ago
[deleted]
eladbenisrael 4y ago
[Wing team member here] Wing has a concept of `inflight` which you can think of as a "remote async function". It's an `async` function that can be executed on a remote system, such as inside a container fleet or on a FaaS. Inflight functions can interact naturally with cloud resources around them (by simply calling inflight methods on the resources e.g. `bucket.put()`). The compiler analyses these interactions and inverts the control over to the resources to take care of the mechanics like wiring deployment information, synthesizing security policies and anything else that can be deduced from this high level intent. Defining the cloud architecture of the app and being able to naturally crossing these distributed boundaries is the essence of what we call "cloud-oriented programming", and where we think a lot of the friction and pain of the cloud comes from today: every time I need to interact with "The Cloud", I leave the safety and comfort of my compiler, and I am out in the wild having to understand all the mechanics and layers involved. Almost all existing languages/compilers take a fundamental assumption that the entire program runs inside a single machine. This is, in our view, the impedance mismatch of cloud development today. This is where we believe language innovation can dramatically reduce the cognitive load and barrier to entry for building and delivering cloud applications that fully take advantage of the cloud. Inflight functions and resources are only the first step. Think first-class support for things like defining and consuming API endpoints, writing distributed workflows, emitting metrics, raising alarms and other things you would expect from your friendly neighborhood cloud programming language.

Thaxll 4y ago

Looks like it just use Terraform behind the scene: https://docs.winglang.io/getting-started/installation https://docs.winglang.io/getting-started/installation

salmo 4y ago

What I’m the world is a cloud-oriented language? Looks at page. Oooh. This is JS with a schmancy library. That’s cool, I guess… for someone.

goodpoint 4y ago

I'd rather have grassroots language that does not run on any cloud service.

webstrand 4y ago

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.

danuker 4y ago
> Hi Nunya Biznis! What's your email address?This question is required. * nunya.biznis@mailinator.com Check out what they sent: https://www.mailinator.com/v4/public/inboxes.jsp?to=nunya.biznis https://www.mailinator.com/v4/public/inboxes.jsp?to=nunya.bi...
- smcl 4y ago
  "Muahahaha"? Hm ok
  - danuker 4y ago
    Ugh. People deleted the original message. I guess we can't have nice things. But you can register with a different Mailinator address.
    - deleted 4y ago
      [deleted]
    - smcl 4y ago
      AHhh I see :D No worries, I just clicked it out of curiosity and was a little confused that someone would use this in their marketing copy :D
- dmarlow 4y ago
  This link hijacked my back navigation and I couldn't get back to hn. Sigh.
bfeynman 4y ago
That is some next level tin foil hat wearing

MontyCarloHall 4y ago

New languages == zero ecosystem—no third-party libraries, community discussion (e.g. StackOverflow), real-world repositories, etc. 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. 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.

hackerman123469 4y ago
Yeah, the example looks like an API demonstration rather than a language demonstration. I would have assumed the API functions were keyword oriented IF it was a programming language.
indymike 4y ago
> A brand new language thus must be extremely compelling at a syntactical level to make it worth leaving behind existing ecosystems. For many niche languages the runtime or standard library is the main show and syntax is built around making the standard library more accessible. In this case it looks like they've built a standard library that abstracts away a lot of cloud components (i.e. SNS, S3) and made them very easy to call. This one actually looks like they may be on to something because of the level of inconsistency between cloud apis. > Everything in the demo code could easily be implemented as a Python or JavaScript API. There are very few domains where this is not true.
- MontyCarloHall 4y ago
  >This one actually looks like they may be on to something because of the level of inconsistency between cloud apis. I still don't see why this requires a totally new language. You could easily write a high-level API in a commonly used language that under the hood generates cloud provider-specific API calls. Indeed, this is exactly what Pulumi does, with API bindings to many commonly used languages. There is no need for a custom runtime, much less a new language specifically designed for that runtime.

mihau 4y ago

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. It also supports higher level abstractions (Component Resources). For example: check out AWS EKS provider.

Bombthecat 4y ago
Is there enterprise support for pulumi?
- jaxxstorm 4y ago
  I work on the solutions engineer team for Pulumi. We absolutely offer enterprise support, I'm one of the engineers that is part of that team. If you'd like to discuss further, you can contact me on lbriggs[at]pulumi.com
mountainriver 4y ago
Yeah Pulumi is a much better idea than this, it’s already production ready and you can use industry standard languages
agtorre 4y ago
Pulumi is great, but winglang is a level of abstraction higher than it or Terraform. I think all 3 projects have benefits for different use-cases

onion2k 4y ago

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 that 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.

bfeynman 4y ago
The latter part is exactly what this is going to be doing. Same way that in AWS CDK you can get higher level constructs that can vend more secure resources. The goal is to make that even more fluent, across different infra deployment architectures

hestefisk 4y ago

What’s the point of “bring cloud”?

hackerman123469 4y ago
Going to assume "cloud" is the package/module and "bring" is similar to something like "import" etc. so it's probably because "cloud" in this case is a module/package that you need to import to use, so the language itself isn't actually cloud-oriented, but rather the standard framework (if you can call it that) is cloud-oriented.
- hestefisk 4y ago
  It seems as useful as “using System;” in c#

pelorat 4y ago

Looks like typescript.

gwn7 4y ago

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. Related: https://twitter.com/garybernhardt/status/1603498230125588480 https://twitter.com/garybernhardt/status/1603498230125588480 https://twitter.com/garybernhardt/status/600783770925420546 https://twitter.com/garybernhardt/status/600783770925420546 https://geekandpoke.typepad.com/geekandpoke/2011/03/architectural-best-practices.html https://geekandpoke.typepad.com/geekandpoke/2011/03/architec...

specialist 4y ago
#2 - I once spent 18 months convincing my teammates to move our hottest data set from DynamoDB to RAM. Next time, I won't bother. #3 - Heh. The "N+1" architecture. However many layers your architectural design methodology has, ours has one more. (h/t Spinal Tap). Is that Twitter you? Good stuff. Like the unique URL for posting CSVs.
- gwn7 4y ago
  > #2 - I once spent 18 months convincing my teammates to move our hottest data set from DynamoDB to RAM. Next time, I won't bother. Yeah, don't bother. People don't want simplicity. The majority of our tribe are masochists haha > #3 - Heh. The "N+1" architecture. However many layers your architectural design methodology has, ours has one more. (h/t Spinal Tap). Exactly > Is that Twitter you? Good stuff. Like the unique URL for posting CSVs. Oh no I'm not Gary, sorry =)

Hamuko 4y ago

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.

davidjfelix 4y ago

The example shown in the animation was one of the quickest yikes I've ever had for architecture. SQS with minimal config into lambda. Alright, good luck.

swyx 4y ago
what is wrong/what can go wrong with hooking up SQS to Lambda? (real question, not trolling)
- davidjfelix 4y ago
  Nothing really goes "wrong" but it has a lot of historic footguns and was designed around finite worker polling not ultra-wide scaling lambdas. IMO, when most people think they want SQS, they actually want SNS. Rarely, Kinesis Streams is what they wanted. SQS + Lambda is an "almost never" when you're building something greenfield. It's a complexity you shouldn't take as a default, but have as an option, IMO. So a quick aside: SQS is one of the oldest async "serverless" services in AWS. Historically, web applications ran into issues with large processing jobs so they would offload this work from the web server, which would synchronously handle requests, and instead do the work in an async manner that aligned with capacity. Job Queues or were designed to have workers pull messages in a FIFO manner and then capacity for those jobs could be planned separate from web capacity. Major contender in this space was RabbitMQ and something like Rails' ActiveJob, which is an ideal user of SQS. So SQS is valuable but why isn't it here? Well, the short answer is: it is valuable, but in the conditions laid out (use with lambda) there are significantly better options. So lets look at the pattern they're using and talk about it. They're calling SQS a queue here, which is an easy mistake to make since it's in the name. I'm going to just toss an asterisk on it for a few reasons; first, because lambda will consume more quickly than most producers so it won't really sit idly for the retenetion window; second, because SQS (low scale) and single instance MQs like Rabbit will handle messages in a FIFO manner, but SQS is a service and abstracts scale away. At some point, the FIFO aspect of it becomes "best effort" unless you configure it to be FIFO (really avoid doing this). To me, this is a *major* design consideration and arbitrarily calling things a queue when really it's more of a pubsub is a bit more than just pedantry. At scale you *will* see out of order, potentially duplicated messages with SQS without FIFO on. Handling duplicates should be at the front of your mind. So... we're using a pubsub pattern which is still maybe pedantically different from a queue, you're still asking why is that so bad? It works with lambda right? Yeah it does. Here's a list of services that work with lambda in a pubsub manner and would allow a user to publish a message and invoke an async lambda with that message: * Kinesis Streams * SQS * SNS * Event bridge * Lambda (use Invoke and set "async" to true) * DynamoDB / S3 (this one is abnormal but still possible -- there are more that I'd categorize here but these are common) A lot of people look at this list and quickly eliminate options. DynamoDB table entries and s3 object drops are clearly misuses or special case jobs (good call). We want a DLQ via config not writing it ourselves so async invoke lambdas are out (bad call - normally DLQs are /dev/null but more expensive). Kinesis streams has an idle cost (true but lower than most think) and SNS and Eventhub aren't reliable or don't hold messages ** (this is false). The assumption is that SQS is the only remaining option that has: * Reliable delivery * Dead letter queue * Roughly ordered delivery * Isn't a "write it ourselves" or "misuse" of service (sorry dynamo/s3). But... that's not the only service that does that. SNS and EventBridge both meet those qualifications. That surprises a lot of people. Both of these services have at-least-once semi-ordered delivery (same as SQS) with lambda and feature retry and DLQs. They also have a really really really huge feature for any operator who runs big serverless pipelines: * They're emitter/publisher focused, not subscriber focused. You create a queue for every notified party, you create an SNS topic for every notifying item. This means you can add a secondary consumer (like... a network tap?) and see messages flowing through the system without changing the system. This is huge for debugging. At this point you might say but what if I want disparate services to be able to consume from the SQS queue but steal each others work? Well... don't use lambda -- the lambda is going to steal all the work -- it can scale up to your account limit without adding more settings that aren't set here. Mostly SQS and worker queues aren't what you want if you want lambda. The real limit for burst-ability is set at a fairly large account limit level. There are *some* instances where queuing might be right, but at those scales you'd actually be asking if maybe Kinesis Streams is a better choice (usually it is). TLDR: SQS is usually not the tool you want with lambda as a consumer. It works, but SNS or Kinesis are much more common. SQS comes with a lot of knobs and whistles that can dramatically run up your bill when using lambda with naive settings (I've seen this a lot, where the DLQ is setup for redrive and it just fail loops). Hope this helps a bit. Note: I have about 5 years experience working with serverless/event driven application architecture.

dadadad100 4y ago

DAPR[1] comes at this problem from the other direction. It creates an abstract infra that any language can use [1] https://dapr.io/ https://dapr.io/

mcluck 4y ago

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)

wiremine 4y ago

The include their motivation in their language spec: "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. "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."

tuananh 4y ago

what makes it a cloud language? what is cloud language even?

specialist 4y ago

My future perfect "cloud" language has grammar for idioms like queues and counters. Ditto pubsub, logging, metrics. And structured concurrency. Not async/await, promises, and so forth. -- 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.

ekeren 4y ago
Disclaimer, I work at Monada, the company behind wing I completely agree with you, a language that considers cloud development as a first class citizen must embrace something like open-telemetry for distributed logging (spans, traces, metrics, logs). When you log something or measure something in your code it should always be part of some distributed trace. We want to embrace this thinking for localhost development and allow our customer to choose their APM provider when they deploy. In a sense we don't see a difference between a cloud resource that is called logger (can be implemented by DataDog, New Relic, Coralogix, etc) and a cloud resource that is called a Queue (can be implemented by SQS, Redis, RabbitMq, etc...) Also, as you mentioned, because in practice all the `inflight` (https://docs.winglang.io/concepts/inflights https://docs.winglang.io/concepts/inflights) code is async by nature, the language should wait for any API call to be resolved (e.g. "await") by default, deferring an API call is the exception

rexreed 4y ago

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.

323 4y ago
Interesting. Maybe also add a "reliability" cost, so something like S3 would be more reliable than a more complex system like RedShift.
- rexreed 4y ago
  Exactly. The cloud orientation that differentiates from a non-cloud orientation is not simply a matter of execution abstraction -- that is already handled through libraries and scripts, etc. What would be cloud-oriented are the economic aspects of the cloud. I usually tell people that the cloud is really two separate ideas: the abstraction of infrastructure and computing on the one hand (what used to be called "grid computing") and the economic model of pay-per-consumption, pay-per-use, pay-per-service that shifts capital expenses (the stuff you own and have already paid for that depreciates over time) to operating expenses (stuff you have to keep paying to use). The CIOs like the technology on-demand, easy scale-up/scale-down aspects of the cloud while the CFOs like the idea of shifting CapEx to OpEx and pay as you go aspects of the cloud.
CathalMullan 4y ago
Since Wing compiles to Terraform, you should be able to manually run Infracost (https://www.infracost.io https://www.infracost.io) to get an idea of costs. Having that capability baked into the language/compiler would be a great addition.
- dj_mc_merlin 4y ago
  Infracost is OK. It's not great, it's OK. To not be meaningless, it's not always accurate, still has some bugs, doesn't cover everything. But it's still the best tool in its class and I use it. If the value proposition of a cloud language included "infracost but better", I might be more inclined to listen.

quanticle 4y ago

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 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. Kind of hard to do that when all the source code is closed. [1]: https://github.com/orgs/winglang/projects/1 https://github.com/orgs/winglang/projects/1 [2]: https://github.com/orgs/winglang/projects/3 https://github.com/orgs/winglang/projects/3 [3]: https://github.com/winglang/wing https://github.com/winglang/wing

swyx 4y ago
i think this might have been posted without their involvement, its possible they werent ready to launch yet
- linhns 4y ago
  If they are not ready then the website should say that. Here it seems like they are really ready
shaiber 4y ago
[Wing team member here] Sorry about the 404s. They are displayed to anyone who has not been given access to the repo yet. You are welcome to request access, and I promise to let you in very quickly. The reason the repo is not yet completely open is that we want a way to engage more with our first community members and get some data about their needs.

TruthWillHurt 4y ago

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

CRidge 4y ago

Is this "cloud oriented" or "AWS oriented"?

dj_mc_merlin 4y ago

This feels like inventing a technology for the sake of it and then trying to fit a problem to it. 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. 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. 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.

cmckn 4y ago
> Yeah, S3 compliant buckets work, but that's the simplest example possible. Agree; you can’t just say “give me a queue”. You need to tune in-flight messages, processing times, FIFO or not, dead letters — the list goes on. These details are not 1:1 for different clouds, and they can’t be ignored for anything beyond a PoC. If I need to mess with all that in Wing…I could just use the AWS SDK. I can also trust that the SDK has the complete, latest feature set.
- shaiber 4y ago
  [Wing team member here] We feel that the cloud has matured to a point where the basic services have enough in common with each other to allow us to successfully abstract their _functional_ parts. We do not abstract away the non-functional ones. You are welcome to check out the implementation of the standard library on GitHub and let us know what you feel is missing in the different abstractions.

swyx 4y ago

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? i have no stake in Wing but it is a good example of the Self Provisioning Runtime thesis (https://swyx.io/self-provisioning-runtime https://swyx.io/self-provisioning-runtime)

rco8786 4y ago

The example appears to be valid Javascript. I’m not saying it doesn’t look interesting or useful. But, “Why not Javascript?”

progx 4y ago

I don't get it. Why we need a new language, when an Module for a language would do the job too? NIH-Syndrom? Why not just simply pre compile it to specific language modules?

vlovich123 4y ago

I haven’t looked through everything, but I opened a random TS comparison: Wing let x = 1; // x is a num let v = 23.6; // v is a num let y = "Hello"; // y is a str let z = true; // z is a bool let w: any = 1; // w is an any let q: num? = nil; // q is an optional num TS: const x: number = 1; const v: number = 23.6; const y: string = "Hello"; const z: boolean = true; const w: any = 1; const q: number? = undefined; 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). Intentionally showing TS in a worse light than reality in a comparison is not a good look in terms of intellectual honesty.

pixel_tracing 4y ago
Wing looks more like swift to me

mathgladiator 4y ago

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.

mikepurvis 4y ago
May also wake up and discover the realities of vendor lock-in, and having little or no story for offline development.
- intelVISA 4y ago
  Unfortunately, there is no awakening: you look over at your AWS bill and triple-redundant HA K8s cluster that serves your 3kb SPA blog to 3 users a month. This is the future.

zoomzoom 4y ago

This is one of the more sophisticated and cool of the "Self Provisioning Runtime" concepts that have emerged in the last few years (https://swyx.io/self-provisioning-runtime https://swyx.io/self-provisioning-runtime). Some of the others: - https://www.pulumi.com/docs/tutorials/cloudfx/ https://www.pulumi.com/docs/tutorials/cloudfx/ - https://www.serverless.com/cloud https://www.serverless.com/cloud - https://www.shuttle.rs/ https://www.shuttle.rs/ - https://encore.dev https://encore.dev 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. 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. It's an exciting time in the DevOps world!

BerislavLopac 4y ago

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.

qaq 4y ago

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.

shaeqahmed 4y ago

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: https://github.com/matanolabs/matano https://github.com/matanolabs/matano), I was excited because of the room for improvement with an integration that is language-native. 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. 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. 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.

simplify 4y ago

How does this compare to Unison[0]? Aside from looking JavaScript-like. Doesn't look statically typed at first glance, but the docs seem to imply it is [1]. Pretty interesting overall. [0]: https://www.unison-lang.org https://www.unison-lang.org [1]: https://docs.winglang.io/reference/spec#18-type-inference https://docs.winglang.io/reference/spec#18-type-inference

stevefan1999 4y ago

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

Aaronstotle 4y ago

This seems like a great way to give cloud providers a lot of your money

z3t4 4y ago

Are the cloud functions guarnteed to succeed?

wolframhempel 4y ago

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.

shaiber 4y ago

[Wing team member here] To get some more insight into why we're building Wing, you are welcome to read Elad's blog post: https://docs.winglang.io/blog https://docs.winglang.io/blog

tomcam 4y ago

That animation on the home page is sick af

emmanueloga_ 4y ago

Reminds me of https://ballerina.io/ https://ballerina.io/ ... which looks actually pretty nice, but I suspect the name of the project is a terrible marketing decision that will hold adoption back ¯\_(ツ)_/¯