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.
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)
Even Luau (which was made for sandboxing user code) don't really have this property.
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).
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.
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!