8 ms·

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

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.
acdha 4y ago
> 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.
- shaiber 4y ago
  [Wing team member here] Wing compiles to JS + Terraform, so all your downstream tools function as they did before
  - acdha 4y ago
    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?
    - shaiber 4y ago
      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.
shaiber 4y ago
[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.
tracker1 4y ago
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.

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.

acdha 4y ago

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

shaiber 4y ago
[Wing team member here] Wing compiles to JS + Terraform, so all your downstream tools function as they did before
- acdha 4y ago
  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?
  - shaiber 4y ago
    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.

shaiber 4y ago

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

tracker1 4y ago

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.