Monty itself seems much more interesting than a Go wrapper for a WASM runtime running the Rust implementation that runs the Python code. There was a big discussion about it 6 months ago: https://news.ycombinator.com/item?id=46918254
It implements the new subprocess model for spawning Monty VMs that help keep your main thread isolated if one of the VMs crashes.
Because Monty is packaged as a binary now, you don't need to do the WASM embedding stuff, you just need to make sure you have the binary. (Similar to how you would run playwright in Go, for example)
Are there significant differences re: sandboxing between Lua and monty? Just curious if there are any holes that a Lua sandbox has that monty might account for
The main property that's really important is that Monty VM state is fully serializable and resumable. So you can run the VM code until you get to a host call, then serialize and persist the state to disk. Then, at a later time you can resume the VM with the tool call results.
Even Luau (which was made for sandboxing user code) don't really have this property.
If you're going to run Python code inside a WebAssembly container anyway why go with the Monty subset when you could use full CPython (or MicroPython) compiled to WASM instead?
1. Control and guardrails. I want agent-authored code to be able to express itself in code but I want to own the external tools that are available to the agent.
2. Suspension and resumption. Monty's VM state is fully serializable so I can run the VM until it gets to a tool call and persist the VM state. I could resume it days later with the results of the tool call with no issues. Doing that guaranteed with CPython is really tricky (tools like Pickle can get you close but if you have open sockets or other weird stuff you're in a world of hurt).
I'm pretty sure that first one can be achieved using MicroPython or CPython.
Your point 2 is very convincing: I hadn't realized Monty had serializable state as a core feature, that's a very compelling attribute for an agent runtime! I have my own projects that could benefit from that.
Absolutely the first one could be achieved using one of those tools. But Monty makes it feel so native, it even packages a type checker so you can provide stubs for the external functions (so you provide feedback to the agent on the type of those things).
Serializable state is the most cool property though. It's really undersold in the explanations but makes running durable agent workflows authored in code possible!
I've implemented and shipped a version of this that uses full CPython with a custom filesystem implementation in userspace. I think this is a bit more interesting if a bit more low level.
Is this Python in Rust in WASM in Go?
The Monty name was a perfect choice, Yakety Sax was playing in the distance as I read through the readme.
Jokes aside, I do love seeing WASM as a bridge to enable cool stuff like this.
Monty itself seems much more interesting than a Go wrapper for a WASM runtime running the Rust implementation that runs the Python code. There was a big discussion about it 6 months ago: https://news.ycombinator.com/item?id=46918254
Funny -- I just built a pure go wrapper myself because this one is super out of date!
https://github.com/CamdenClark/monty-go
It implements the new subprocess model for spawning Monty VMs that help keep your main thread isolated if one of the VMs crashes.
Because Monty is packaged as a binary now, you don't need to do the WASM embedding stuff, you just need to make sure you have the binary. (Similar to how you would run playwright in Go, for example)
Are there significant differences re: sandboxing between Lua and monty? Just curious if there are any holes that a Lua sandbox has that monty might account for
The main property that's really important is that Monty VM state is fully serializable and resumable. So you can run the VM code until you get to a host call, then serialize and persist the state to disk. Then, at a later time you can resume the VM with the tool call results.
Even Luau (which was made for sandboxing user code) don't really have this property.
If you're going to run Python code inside a WebAssembly container anyway why go with the Monty subset when you could use full CPython (or MicroPython) compiled to WASM instead?
1. Control and guardrails. I want agent-authored code to be able to express itself in code but I want to own the external tools that are available to the agent.
2. Suspension and resumption. Monty's VM state is fully serializable so I can run the VM until it gets to a tool call and persist the VM state. I could resume it days later with the results of the tool call with no issues. Doing that guaranteed with CPython is really tricky (tools like Pickle can get you close but if you have open sockets or other weird stuff you're in a world of hurt).
I'm pretty sure that first one can be achieved using MicroPython or CPython.
Your point 2 is very convincing: I hadn't realized Monty had serializable state as a core feature, that's a very compelling attribute for an agent runtime! I have my own projects that could benefit from that.
Absolutely the first one could be achieved using one of those tools. But Monty makes it feel so native, it even packages a type checker so you can provide stubs for the external functions (so you provide feedback to the agent on the type of those things).
Serializable state is the most cool property though. It's really undersold in the explanations but makes running durable agent workflows authored in code possible!
I've implemented and shipped a version of this that uses full CPython with a custom filesystem implementation in userspace. I think this is a bit more interesting if a bit more low level.
loving to see more uses of wazero in the wild! I think these uses of the Wasm sandbox show a lot of promise!