Re:Wing: A cloud-oriented programming language
by ashiban on Monday December 19, 2022 @12:20PM
(#34054683)
> Why is this a language, not just a framework for JavaScript or whatever?
I'm one of the founders of Klotho (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
I'm one of the founders of Klotho (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