One of the reasons I find this so interesting is its core intent to be used as a stepping stone to distributed systems work. I really love the way it feels, in general. I am curious about projects like Fermyon Spin and Deis Hippo for approaching aspects of this problem space from a WebAssembly angle.
A couple of years ago I sat down and spent a work-provided hack week prototyping a distributed service platform using Nomad, Deno, and Firecracker that has some pretty profound design overlap with this, so I’m definitely interested.
As @yonkeltron noted as well, there’s an alternative/complementary option starting to emerge around WASM for packaging and sandboxing smaller workloads than VMs (or even cgroups) make sense for. Anything using Deno (like Aurae has) is in a good position to leverage WASM as both a workload and extension/plugin format.
I can’t wait for this stuff to mature so we[^1] as an industry can put this ugly chapter of “run my blog in Kubernetes” behind us.
[^1]: the presumptive “we” here refers to “folks who build complex applications and the infrastructure that runs them on other people’s computers.”
This is an interesting project, but I’m curious why yet another DSL? I’m unsure if you are related to the project OP, but I find DSLs to be frustrating. It guarantees that almost nobody knows the language.
I see there’s a gRPC layer which you could possibly use instead of AuraeScript (AS)? The question remains, why even bother with AuraeScript instead of a native Rust API which is what Aurae is built with. AS seems like a whole extra layer of potential bugs. What’s the benefit there?
From my quick look: AuraeScript is built on top of Deno. Building on top of a javascript-like language immediately makes it very easy to start and is a huge improvement over shell scripting.
Native Rust APIs are good, but Rust is not fast nor easy to compile. Shipping binaries to remote systems is possible, but kills the feedback loop when trying something quickly. A solid scripting layer is always a good thing to have.
One of the reasons I find this so interesting is its core intent to be used as a stepping stone to distributed systems work. I really love the way it feels, in general. I am curious about projects like Fermyon Spin and Deis Hippo for approaching aspects of this problem space from a WebAssembly angle.
A couple of years ago I sat down and spent a work-provided hack week prototyping a distributed service platform using Nomad, Deno, and Firecracker that has some pretty profound design overlap with this, so I’m definitely interested.
As @yonkeltron noted as well, there’s an alternative/complementary option starting to emerge around WASM for packaging and sandboxing smaller workloads than VMs (or even cgroups) make sense for. Anything using Deno (like Aurae has) is in a good position to leverage WASM as both a workload and extension/plugin format.
I can’t wait for this stuff to mature so we[^1] as an industry can put this ugly chapter of “run my blog in Kubernetes” behind us.
[^1]: the presumptive “we” here refers to “folks who build complex applications and the infrastructure that runs them on other people’s computers.”
This is an interesting project, but I’m curious why yet another DSL? I’m unsure if you are related to the project OP, but I find DSLs to be frustrating. It guarantees that almost nobody knows the language.
I see there’s a gRPC layer which you could possibly use instead of AuraeScript (AS)? The question remains, why even bother with AuraeScript instead of a native Rust API which is what Aurae is built with. AS seems like a whole extra layer of potential bugs. What’s the benefit there?
From my quick look: AuraeScript is built on top of Deno. Building on top of a javascript-like language immediately makes it very easy to start and is a huge improvement over shell scripting.
Native Rust APIs are good, but Rust is not fast nor easy to compile. Shipping binaries to remote systems is possible, but kills the feedback loop when trying something quickly. A solid scripting layer is always a good thing to have.
I am not affiliated. Your questions are interesting however.