pyground VS wasmtime

Yep, it’s all static with no server side and the Python all runs locally. The source is on GitHub: https://github.com/mcintyre94/pyground so you can run it locally or deploy it yourself if you’d like too

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh rustup target install wasm32-wasip1 cargo install --locked --version 1.227.1 wasm-tools cargo install --locked --git https://github.com/dicej/spin --branch wasi-http-p3-demo spin-cli git clone https://github.com/WebAssembly/wasi-http -n && (cd wasi-http && git checkout 505ebdb9) curl -OL https://github.com/bytecodealliance/wasmtime/releases/download/v30.0.2/wasi_snapshot_preview1.reactor.wasm

Wasmtime, developed by the Bytecode Alliance

9x larger in LoC, 50x larger in comments.

I had a wall of supporting tokei but decided against it, but the short of it is, LLVM is phenomenally massive, and libfirm at 135kloc and 35kloc of comments is but a raindrop that is in the 15Mloc+ that is LLVM.

Perhaps instead of looking towards libfirm, we should look at cranelift. It is of comparable size and actually includes 12kloc of documentation, not just comments.

https://github.com/bytecodealliance/wasmtime/tree/main/crane...

Very similar, but Wasm has additional safety properties and affordances. I am trying to get away from dynamic libs as an app extension mechanism. It is especially nice when application extension is open to end users, they won't be able to crash your application shell.

https://wasmtime.dev/ https://github.com/bytecodealliance/wasmtime

>So one of the main problems you run into is that your elegant solution only works about 60-80% of the time. The rest of the time, you end up falling back onto near-unmaintainable, horribly inelegant kludges that end up having to exist

This is generally true, though for small compiler backends they have the luxury to straight up refuse to support such use cases. Take QBE and Cranelift for example, the former lacks x87 support [1], the latter doesn't support varargs[2]; which means either of them support the full x86-64 ABI for C99.

[1]https://github.com/michaelforney/cproc?tab=readme-ov-file#wh...

[2]https://github.com/bytecodealliance/wasmtime/issues/1030

Standards help in a completely different way, too: since all of the HTTP support is now built using wasi-http, applications built with the new SDK that don’t make use of the Spin-specific APIs we also support can run in any environment that supports wasi-http, such as Wasmtime and Node.js (via JCO).

If you’re on Windows, check out the precompiled packages: https://github.com/bytecodealliance/wasmtime/releases

You should look at embedding Wasmtime into your C.

https://github.com/bytecodealliance/wasmtime/tree/main/examp...

And a special thank you to everyone who has been contributing and continues contribute to the WebAssembly ecosystem particularly to the maintainers of the Bytecode Alliance projects, the Wasmtime project and the developers working on WASI and the WebAssembly component model. Their work is instrumental in supporting Spin.