I basically want to do something like this:
my-sandbox-cli-tool 'print("hello world")
I am on a continued quest to figure out the cleanest way to achieve this, I have so many projects I would want to build on top of this capability!
disclaimer: i work there
% wasmtime run --dir .::/ python.wasm -c 'print("hello world")'
hello world
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")'
wasmtime run --dir .::/ python.wasm -c 'print(len(open("python.wasm", "rb").read()))'
# Outputs 28775526
wasmtime run --dir .::/ python.wasm -c 'open("python.wasm", "wb").write(b"blah")'
Although... I guess I could use unix filesystem permissions to make those read-only? That could work.
whats this magic
[1] https://developer.fermyon.com/spin/v3/writing-apps#declaring...
We finally in 2024 sort of have esm for workers, for example. But not import-maps, so the distributed esm modules aren't directly usable. This category of "making using the spec actually possible" problems tends to dwell for far too long alas.
In part inspired by terminal colors but purple (instead of black) makes it feel more modern and sophisticated.
Perhaps "--dir .::/" means treat the host directory "." as the guest directory "/"?
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.
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.
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
As such you're probably not the right fit for me, I should be looking more at things like wasmer and wasmtime.
From a pragmatic end-user point-of-view explanation, I would still stand by saying WASM Component Model may be similar to working within the JVM multi-language ecosystem. One can work with code compiled from multiple different languages, but the generated code may be different because of the different compilers.
So no, we're still a long way from the abstractions of a JVM, even taking the component model into account.
It's a good step in the direction of better interoperability between languages, though, don't get me wrong.
With that in mind, the other confusing thing one may come across is composition vs linking within your WASM runtime that supports the Component Model. When you hear "composition" think of compile-time merging of libraries such that the bundle may have less unresolved dependencies of WASM code/implemented component interfaces. Anything unresolved needs to be linked at runtime with your WASM runtime of choice, like wasmtime [3]. Pretty interesting reading/potential after reading if you ask me -- sounds like you could implement something like a custom Java classloader hierarchy [4].
But I'd agree with a statement saying it is still a long way for general usage.
[1] https://github.com/WebAssembly/component-model/blob/5a34794d...
[2] https://github.com/WebAssembly/gc
[3] https://github.com/bytecodealliance/wasmtime/blob/ba8131c6bf...
[4] https://www.digitalocean.com/community/tutorials/java-classl...