Hi ospencer, cohix, nyahmacklindev, and jagger27:

- Could you share some insights on why wasmtime and not wasm3 or wasmer in particular (other than the fact that the bytecodealliance is putting its weight behind wasmtime)?

- What do you make of Cloudflare's / Deno.land's approach of relying on v8 isolates (which can run WASM) versus relying on WASI for the nanoprocess model? Do you think eventually most edge-functions would be WASM-only (as opposed to v8 / firecracker)? Or, are there inherent limitations in the WASM-only approach?

- Azure's Deis Labs (krustlet.dev) has been experimenting a bunch with server-side WASM lately (as are startups such as golioth.io / hotg.ai) and it seems like things are indeed brewing up fast in this space. Any developments you'd particularly recommend folks keep an eye on?

- How did the team get together to work on suborbital?

One look at "What comes after k8s" thread (item?id=27155526) and it is clear most developers here think serverless or an alt k8s (like k0s / k3s / hashicorp nomad) is the way forward. I particularly think WASM is poised to take over serverless itself. So, all the best and hope you folks make it. Thx.

Hello!

> Could you share some insights on why wasmtime and not wasm3 or wasmer in particular

The underlying architecture also supports Wasmer (there's a compiler flag to switch between them), and between the two, Wasmtime is better suited to be statically compiled into the Sat binary, which was a pre-set requirement for this experiment. Wasm3 is also awesome, but Wasmtime does have a performance leg up on Wasm3.

> What do you make of Cloudflare's / Deno.land's approach of relying on v8 isolates (which can run WASM) versus relying on WASI for the nanoprocess model? Do you think eventually most edge-functions would be WASM-only (as opposed to v8 / firecracker)? Or, are there inherent limitations in the WASM-only approach?

I personally believe that eventually the Wasm/WASI-only approach will be very viable, and even today you could run Sat on bare-metal with the right configuration and get very good sandboxing. CloudFlare/Deno are using one of the most natural on-ramps into the Wasm ecosystem, and I think it's a perfectly valid approach that will likely work very well, the V8 code optimizer is no slouch.

> Any developments you'd particularly recommend folks keep an eye on?

The ones you mentioned certainly, as well as wasmCloud, Lunatic, Yew, AssemblyLift, and Fastly's Compute@Edge are all projects to watch in the WebAssembly space.

> How did the team get together to work on suborbital?

Suborbital started as an open source project (Reactr), and is now a startup that focuses the majority of its efforts on open source Wasm tooling/frameworks/etc. I am the founder of said company, and the others are the founding team!

> I particularly think WASM is poised to take over serverless itself. So, all the best and hope you folks make it. Thx.

Thank you, and I agree :)

Hey, co-founder of HOTG.ai here! Nice to see how folks are getting more interested in WASM and deployments. We hadn't specifically targeted the serverless cloud area but we are considering it. We are an edge first company (mobile web, mobile, embedded linux etc). Are you using WASM in production today? If not, why not?

Hi: Yes, we use WASM by the way of Deno-Deploy and Cloudflare Workers but for web & logging workloads. We do not have a specific need for WASM but it speed: It is faster than any other serverless sandboxes (Kata/gVisor/Firecracker/Docker) out there. TinyML is something I keep a keen eye on as that's likely going to be what we would next use serverless for and prefer if it was WASM-able.

So Webassembly is definitely the future as far as "what do I target when the platform is everyone's browser"

I am wondering what the win is if you are running it in docker - at this point you can choose any language / form you wish.

But this is very cool. what did you learn most about webassembly that I ought to know writing it?

The end goal is that Docker isn't needed at all, you could just run Sat on bare metal and you'd get all the nice sandboxing properties of Wasm. That said, the tooling in the industry is largely container-based, so that's the starting point for now.

The benefit you get today is you can actually run un-trusted code in Wasm and have a higher level of sandboxing than a container, for example you can run user-submitted code with the right configuration.

When writing for Wasm, I'd say the best thing to keep in mind is that the ecosystem is young and so not everything is fleshed out, but there are already a ton of cool things you can do, and the experience will vary depending on the language you're using to target it.

What's the difference behind this and https://github.com/bytecodealliance/wasm-micro-runtime?

I'm using wasm-micro-runtime at https://www.inngest.com to transform events on the fly, to run secure templating everywhere, and (sometimes) to run custom actions.

WAMR also has the capability to run AOT compiled WASM, which is kind of ideal for the immutable, fast running wasm modules we're running.

Would love to learn more, because it seems like they have shared goals, and this is a very, very interesting subject :)

Sat is a pre-built server and a set of APIs wrapped around Wasmtime, it could theoretically use WAMR as well!

This has been a fun experiment! I'm available if anyone has any questions as well as other folks from the Suborbital team—cohix, nyahmacklindev, and jagger27.

Yep, thrilled to be here and help folks out however we need :)

What's the use case for this?

One of the first things we've used it for internally is to run one-off isolated tests on WebAssembly modules instead of feeding them through a production Atmo[0] instance. It basically serves as a dumb pipe for feeding data in and out of any Wasm module built for Reactr[1].

0: https://github.com/suborbital/atmo

1: https://github.com/suborbital/reactr

So, from what I understand Atmo and Reactr are about building an app as functions, and then Atmo and Reactr takes care of invoking them when they're needed? Is that correct?

Yes that’s right.

This appear to be using Wasmtime to run the WASM. The main point seems to be:

> Sat has the ability to create a mesh with other instances using local network discovery and websockets. By default, Sat starts on a random port, and listens for requests from its peers. In the future, this will enable some very interesting network topologies and potentially an integration with Atmo, but for now we are focused on being tiny and fast.

I'm not sure what this means/implies though.

This would be really cool to make a crypto currency miner that uses webassembly and websockets to infect webpages with.

> ...make a crypto currency miner that uses wasm...

cosmos.network already runs its interchain "contracts" on wasmer.io: https://archive.is/dvS4q

That's the compiled rust code for the example, not the size of the compiler/interpreter.

Right! I'll also just mention that this Wasm module isn't sent to the clients and run in the browser. It runs server-side.

And for a bit of context, the hello world example below produces a 409K binary straight out of rustc on my machine. It does much less than our example, which also includes some shim libraries not shown in lib.rs.

    fn main() {
        println!("Hello World!");
    }