Live data from Hacker News

Spin 3.0 – open-source tooling for building and running WASM apps

fermyon.com

21–30 of 44 posts

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#21
post #19
post #13

Earlier quoted context omitted.

Wow that's almost what I want. wget https://github.com/brettcannon/cpython-wasi-build/releases/download/v3.13.0/python-3.13.0-wasi_sdk-24.zip unzip python-3.13.0-wasi_sdk-24.zip wasmtime run --dir .::/ python.wasm -c 'print("hello world")' So far so good! But... it looks like that --dir option mounts the current directory as both readable and writable: wasmtime run --dir .::/ python.wasm -c 'print(len(open("python.wa…

This is just a limitation of the wasmtime CLI. The full Rust API let's you mount filesystems as read-only. Not sure why it's not exposed as an argument.

Thanks - I just found an open issue for exposing that in the Python API: https://github.com/bytecodealliance/wasmtime-py/issues/251

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#22
post #20
post #16

Earlier quoted context omitted.

Is that something I can run on my own laptop? It says it's "open source" but the docs seem to be for client libraries that need an API key.

everything, including the infra is open-source (below), but it currently requires more than just your laptop (gcp, nomad, firecracker, postgres, etc.) this way, we're able to run millions secure sandbox environments i appreciate asking though and will be forwarding to my team to see if we can come up with a way for users to emulate the execution locally source code: https://github.com/e2b-dev/infra

My objectives here are pretty specific: I'm building open source Python tools for people to run on their own machines, and I want to add "execute untrusted code" features to those tools (mainly for code written by LLMs) such that people can use those features with a clean 'pip install x' of my software on Mac, Linux and hopefully also Windows.

As such you're probably not the right fit for me, I should be looking more at things like wasmer and wasmtime.

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#23
post #8
post #6

Earlier quoted context omitted.

Wasm components can talk to each other, you do not need the JS FFI boundary.

Can you give an example? Say between a wasm component written in Rust and wasm component written in dart.

WASM is basically similar to JVM bytecode. So the comparison would be like using compiled code from Java, Scala and/or Kotlin for example.

The source language only determines how the code is expressed in WASM and whether or not it also needs to bundle / compile-in some runtime code baggage for it to work.

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#24
post #13

Earlier quoted context omitted.

Wow that's almost what I want. wget https://github.com/brettcannon/cpython-wasi-build/releases/download/v3.13.0/python-3.13.0-wasi_sdk-24.zip unzip python-3.13.0-wasi_sdk-24.zip wasmtime run --dir .::/ python.wasm -c 'print("hello world")' So far so good! But... it looks like that --dir option mounts the current directory as both readable and writable: wasmtime run --dir .::/ python.wasm -c 'print(len(open("python.wa…

You might need to wrap the wasmtime command in firejail or bubblewrap with appropriate arguments to get the operation restrictions you want.

While that might be a workable stop gap, there is zero reason why this couldn’t be handle in the wasi shim layer. This is exactly what wasi was designed for.

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#25

Component dependency is pretty wild and could massively simplify some complex apps

Yes, its great to see progress in the tooling [1] so that the component building is easier. Although I do like to think of the component model as the "ABI linking model". You can only bind one implementation to an interface import.

[1] https://developer.fermyon.com/spin/v3/writing-apps#declaring...

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#26
post #22
post #20

Earlier quoted context omitted.

everything, including the infra is open-source (below), but it currently requires more than just your laptop (gcp, nomad, firecracker, postgres, etc.) this way, we're able to run millions secure sandbox environments i appreciate asking though and will be forwarding to my team to see if we can come up with a way for users to emulate the execution locally source code: https://github.com/e2b-dev/infra

My objectives here are pretty specific: I'm building open source Python tools for people to run on their own machines, and I want to add "execute untrusted code" features to those tools (mainly for code written by LLMs) such that people can use those features with a clean 'pip install x' of my software on Mac, Linux and hopefully also Windows. As such you're probably not the right fit for me, I should be looking more…

You are a big pyiodide user? Does it provide a trampoline to create another sibling instance?

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#27
post #26
post #22

Earlier quoted context omitted.

My objectives here are pretty specific: I'm building open source Python tools for people to run on their own machines, and I want to add "execute untrusted code" features to those tools (mainly for code written by LLMs) such that people can use those features with a clean 'pip install x' of my software on Mac, Linux and hopefully also Windows. As such you're probably not the right fit for me, I should be looking more…

You are a big pyiodide user? Does it provide a trampoline to create another sibling instance?

I love Pyodide in the browser but I've had trouble running it not-in-the-browser, aside from this experiment with Deno: https://til.simonwillison.net/deno/pyodide-sandbox

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#28
post #8

Earlier quoted context omitted.

Can you give an example? Say between a wasm component written in Rust and wasm component written in dart.

WASM is basically similar to JVM bytecode. So the comparison would be like using compiled code from Java, Scala and/or Kotlin for example. The source language only determines how the code is expressed in WASM and whether or not it also needs to bundle / compile-in some runtime code baggage for it to work.

I develop the Scala-to-Wasm compiler, and also maintain the JVM backend of Scala. I can tell you that Wasm is very different from JVM bytecode.

The fundamental difference is that the JVM bytecode has an object model. When they talk to each other, Java, Scala and Kotlin do so at the abstraction level of the JVM object model. You can directly call methods between them because virtual dispatch of methods is a concept with semantics in the bytecode.

There's no such thing in Wasm, even with the GC extension. You get structs and arrays, but nothing like methods. If you want virtual dispatch, you encode it yourself using your own design of virtual method tables. That means Java, Scala and Kotlin, despite all having their Wasm GC backend at this point, cannot call each other's methods in Wasm.

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#29
post #10
post #7

Does anyone know what the simplest possible recipe for running a Python script in a WASM sandbox using Spin is? I basically want to do something like this: my-sandbox-cli-tool 'print("hello world") And have the snippet of Python code I provide run inside a WebAssembly container that runs one of the Python compiled to WASM builds ( https://github.com/brettcannon/cpython-wasi-build for example) - with a time limit and…

wasmtime works as long as you make sure to include the lib directory % wasmtime run --dir .::/ python.wasm -c 'print("hello world")' hello world disclaimer: I run a code execution API service ( https://riza.io/playground ) that does this and more (HTTP, packages, etc.)

> .::/

whats this magic

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#30
post #28

Earlier quoted context omitted.

WASM is basically similar to JVM bytecode. So the comparison would be like using compiled code from Java, Scala and/or Kotlin for example. The source language only determines how the code is expressed in WASM and whether or not it also needs to bundle / compile-in some runtime code baggage for it to work.

I develop the Scala-to-Wasm compiler, and also maintain the JVM backend of Scala. I can tell you that Wasm is very different from JVM bytecode. The fundamental difference is that the JVM bytecode has an object model . When they talk to each other, Java, Scala and Kotlin do so at the abstraction level of the JVM object model. You can directly call methods between them because virtual dispatch of methods is a concept w…

I am confused. You are referring to wasm modules here? And Component Model / WASI / WIT will give us polyglot interface-based programming then, right? Call each other's methods through the WIT interface between components.
Post reply on HN