Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monty: A minimal, secure Python interpreter written in Rust for use by AI

github.com

Post reply on HN
Print view View original

141–150 of 179 posts

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#141

Post by OutOfHere »

maxbond wrote: post #86
OutOfHere wrote: post #57

Earlier quoted context omitted.

Speed is not a feature if there isn't even syntax parity with CPython.

Not having parity is a property they want, similar to Starlark. They explicitly want a less capable language for sandboxing. Think of it as a language for their use case with Python's syntax and not a Python implementation. I don't know if it's a good idea or not, I'm just an intrigued onlooker, but I think lifting a familiar syntax is a legitimate strategy for writing DSLs.

Not having syntax parity with Python == not Python. End of story. The title stays "Python interpreter" which accordingly it is not.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#142

Post by ontouchstart »

simonw wrote: post #138
IhateAI wrote: post #82

Earlier quoted context omitted.

Previously, open source software didn't contribute to automating away jobs, at least not at scale. Open Source libraries weren't potentially maintaining themselves (I know we aren't there yet, but that seems to be the goal). You cannot compare any open source software, even as a whole, to the impact that LLMs have had on labor and are projected too. However, I might now argue it would have been better to not have so…

This is a solid answer to my question, thanks. I'm an optimist on this and I remain hopeful that AI will create more and better jobs, but I'm not at all certain about that. It's possible it will play out the way you describe, and that will suck. I'm not ready to blame the 100,000s of software layoffs on AI though - I think the more likely explanation for those is over-hiring during Covid combined with the end of ZIRP…

I think there are two use cases of open source, one is for people who need a solution to grab and use. In this case, I think LLM Agents will pick up quickly and replace grab and use type of engineering.

The second use case is for HUMAN to learn from human. Your open source projects are excellent examples, same with Django and Python open source ecosystem.

I just hope humans will not stop learning. As long as you share your passion of learning, people will learn from you. It has nothing to do automation.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#143

Post by verdverm »

avaer wrote: post #8

This feels like the time I was a Mercurial user before I moved to Git. Everyone was using git for reasons to me that seemed bandwagon-y, when Mercurial just had such a better UX and mental model to me. Now, everyone is writing agent `exec`s in Python, when I think TypeScript/JS is far better suited for the job (it was always fast + secure, not to mention more reliable and information dense b/c of typing). But I think…

Don't extrapolate

There is a ton of wheel reinvention going on right now cause everyone wants to be cool in the age of ai

Use boring tech, you'll thank me and yourself later

Which in this case means, just use regular python. Your devops team is unlikely to allow knock off python in production. TS is fine too, I mainly write Go

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#144

Post by OutOfHere »

simonw wrote: post #63
OutOfHere wrote: post #56

Earlier quoted context omitted.

Docker and other container runners allow it. https://containers.dev/ allows it too. https://github.com/microsoft/litebox might somehow allow it too if a tool can be built on top of it, but there is no documentation.

Every time I use Docker as a sandbox people warn me to watch out for "container escapes". I trust Firecracker more because it was built by AWS specifically to sandbox Lambdas, but it doesn't work on macOS and is pretty fiddly to run on Linux.

I think ChatGPT can do a much better job than I can for guiding how to safely use Docker as a sandbox: /share/69875282-1e38-8012-b627-7c0a678f9365

It's not industrial-grade safety for public use, but it'll do for personal use. Other tools for it are also mentioned.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#145

Post by staticassertion »

scolvin wrote: post #40
ushakov wrote: post #35

Earlier quoted context omitted.

there’s no way around VMs for secure, untrusted workloads. everything else, like Monty has too many tradeoffs that makes it non-viable for any real workloads disclaimer: i work at E2B, opinions my own

As discussed on twitter, v8 shows that's not true. But to be clear, we're not even targeting the same "computer use" use case I think e2b, daytona, cloudflare, modal, fly.io, deno, google, aws are going after - we're aiming to support programmatic tool calling with minimal latency and complexity - it's a fundamentally different offering. Chill, e2b has its use case, at least for now.

V8 itself is intended to be heavily sandboxed. Not through a microvm, but otherwise it's probably the most heavily sandboxed piece of code ever ie: in Chrome it can make virtually no system calls and runs with every restriction an OS can possibly provide and more and seccomp-bpf was basically invented for it.

Perhaps you're using v8 isolates, which then you're back into the "heavily restricted environment within the process" and you lose the things you'd want your AI to be able to do, and even then you still have to sandbox the hell out of it to be safe and you have to seriously consider side channel leaks.

And even after all of that you'd better hope you're staying up to date with patches.

MicroVMs are going to just be way simpler IMO. I don't really get the appeal of using V8 for this unless you have platform/ deployment limitations. Talking over Firecracker's vsock is extremely fast. Firecracker is also insanely safe - 3 CVEs ever, and IMO none are exploitable.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#146

Post by vghaisas »

16bitvoid wrote: post #112
vghaisas wrote: post #104

Earlier quoted context omitted.

This is very cool, but I'm having some trouble understanding the use cases. Is this mostly just for codemode where the MCP calls instead go through a Monty function call? Is it to do some quick maths or pre/post-processing to answer queries? Or maybe to implement CaMeL? It feels like the power of terminal agents is partly because they can access the network/filesystem, and so sandboxed containers are a natural extens…

It's right there in the README. > Monty avoids the cost, latency, complexity and general faff of using full container based sandbox for running LLM generated code. > Instead, it let's you safely run Python code written by an LLM embedded in your agent, with startup times measured in single digit microseconds not hundreds of milliseconds.

Oh I did read the README, but still have the question: while it does save on cost, latency and complexity, the tradeoff is that the agents can't run whatever they want in a sandbox, which would make them less capable too.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#147

Post by zahlman »

Cyphase wrote: post #20
zahlman wrote: post #2

> Instead, it let's you run safely run Python code written by an LLM embedded in your agent, with startup times measured in single digit microseconds not hundreds of milliseconds. Perhaps if the interpreter is in turn embedded in the executable and runs in-process, but even a do-nothing `uv` invocation takes ~10ms on my system. I like the idea of a minimal implementation like this, though. I hadn't even considered it…

uv is written in Rust, not Python.

Yes. That's why I compare it (a compiled Rust executable) to Monty (a compiled Rust executable). The point is that loading large compiled executables into memory takes long enough to raise an objection to the "startup times measured in single digit microseconds not hundreds of milliseconds" claim.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#148

Post by zahlman »

saberience wrote: post #120
simonw wrote: post #5

I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…

I really don't understand the use-case here. My models are writing code all day in 3/4 different languages, why would I want to: a) Restrict them to Python b) Restrict them to a cutdown, less-useful version of Python? My models write me Typescript and C# and Python all day with zero issues. Why do I need this?

For sandboxing, as described in the README.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#149

Post by [deleted] »

OutOfHere wrote: post #141
maxbond wrote: post #86

Earlier quoted context omitted.

Not having parity is a property they want, similar to Starlark. They explicitly want a less capable language for sandboxing. Think of it as a language for their use case with Python's syntax and not a Python implementation. I don't know if it's a good idea or not, I'm just an intrigued onlooker, but I think lifting a familiar syntax is a legitimate strategy for writing DSLs.

Not having syntax parity with Python == not Python. End of story. The title stays "Python interpreter" which accordingly it is not.

[deleted]

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#150

Post by falcor84 »

saberience wrote: post #120
simonw wrote: post #5

I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…

I really don't understand the use-case here. My models are writing code all day in 3/4 different languages, why would I want to: a) Restrict them to Python b) Restrict them to a cutdown, less-useful version of Python? My models write me Typescript and C# and Python all day with zero issues. Why do I need this?

For extremely rapid iteration - they can run a quick script with this in under 1ms - it removes a significant bottleneck, especially for math-heavy reasoning
Post reply on HN