[HN Gopher] Show HN: Sat, the tiny WebAssembly compute module
___________________________________________________________________
Show HN: Sat, the tiny WebAssembly compute module
Author : ospencer
Score : 38 points
Date : 2021-10-07 16:14 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ospencer wrote:
| 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.
| nyahmacklindev wrote:
| Yep, thrilled to be here and help folks out however we need :)
| Zababa wrote:
| What's the use case for this?
| jagger27 wrote:
| 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
| Zababa wrote:
| 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?
| jagger27 wrote:
| Yes that's right.
| Zababa wrote:
| 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.
| lifeisstillgood wrote:
| 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?
| cohix wrote:
| 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.
| [deleted]
| tonyhb wrote:
| 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 :)
| cohix wrote:
| Sat is a pre-built server and a set of APIs wrapped around
| Wasmtime, it could theoretically use WAMR as well!
| [deleted]
| ignoramous wrote:
| 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.
| cohix wrote:
| 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 :)
| brian_herman wrote:
| This would be really cool to make a crypto currency miner that
| uses webassembly and websockets to infect webpages with.
| [deleted]
| ignoramous wrote:
| > _...make a crypto currency miner that uses wasm..._
|
| cosmos.network already runs its interchain "contracts" on
| wasmer.io: https://archive.is/dvS4q
| hunterb123 wrote:
| The hello world example in the repo is 1.73 MB
|
| edit: thanks for the replies below, I misinterpreted the use case
| for that wasm module.
| bastawhiz wrote:
| That's the compiled rust code for the example, not the size of
| the compiler/interpreter.
| jagger27 wrote:
| 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!"); }
___________________________________________________________________
(page generated 2021-10-07 23:01 UTC)