Hacker News Reader

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

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

[Wing team member here] We also believe that creating good, non-leaky abstractions is hard, but 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.

It is true that you would get more benefits from Wing as you write more of your code in it and give the compiler more visibility into your code. But you are not required to write everything in Wing, and there is interop to other languages. Since the language compiles to TF and JS at the moment, you can import JS libraries to use in your code and take advantage of the huge JS ecosystem.

The cloud simulator is not meant to simulate the cloud, including its non-functional concerns - you have local stack for that indeed. The idea of the simulator is to give you the most light weight and fastest way to test the functional aspects of your code while you develop it. You definitely need to further test it with local stack and/or the cloud.

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

I think this is especially important in this space. If I use Terraform, in addition to tons of tools and experience in the community, there are a variety of mature tools for things like compliance and cost checks. If I use AWS CloudFormation, the same is true. That doesn't mean I wouldn't consider a new tool but it would have to be especially valuable to make up for the cost of losing that baseline.

[Wing team member here] Wing compiles to JS + Terraform, so all your downstream tools function as they did before

Ah, that’s an important detail since it makes it a lot easier to fit into an existing pipeline then.

How’s the escape hatch if you need Terraform features which Wing doesn’t already support?

We're still working on it. You are welcome to join our GitHub and help influence what shape it will take. Additionally, you can create your own resource, or a target for a resource if you find the one that comes with the standard library lacking.

I am of a similar mind... I will say the work that Cloudflare, Deno and a handful of others have done has been really interesting/compelling. I mean, if you don't like TS/JS, there's still WASM as an option. Similarly I think WASM target frameworks will become very interesting in terms of cloud scaling apps in the longer term.

IMO, I think considerations for general search is probably one of the biggest shortcomings of most cloud first solutions.