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

121–130 of 179 posts

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

#121

Post by woadwarrior01 »

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…

I remember the time when Python was the underdog and most of AI/ML code was written in the Matlab or Lua (torch). People would roll their eyes when you told them that you were doing deep learning with Python (theano).

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

#122

Post by Tade0 »

Kerrick wrote: post #109
Tade0 wrote: post #100

Earlier quoted context omitted.

> In JS, you have the Node / Deno split, You do? Deno is maybe a single digit percentage of the market, just hyped tremendously. > E.G. compare tsx versus Node's native ts execution JSX/TSX, despite what React people might want you to believe, are not part of the language. > which only work if you pray three times on the day of the full moon. It only doesn't work in some contexts due to legacy reasons. Otherwise it's…

> JSX/TSX, despite what React people might want you to believe, are not part of the language. Similarly: TypeScript, despite what Node people might want you to believe, is not part of the JavaScript language.

Yes. As pointed out by someone else I misunderstood and it's the other tsx they were talking about.

I've always used ts-node, so I forgot about tsx's existence, but still those are just tools used for convenience.

Nothing currently actually runs TypeScript natively and the blessed way was always to compile it to JS and run that.

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

#123

Post by jstanley »

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…

> 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.

This is true in a sense, but every little papercut at the lower levels of abstraction degrades performance at higher levels as the LLM needs to spend its efforts on hacking around jank in the Python interpreter instead of solving the real problem.

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

#124

Post by Tade0 »

mcintyre1994 wrote: post #110
Tade0 wrote: post #100

Earlier quoted context omitted.

> In JS, you have the Node / Deno split, You do? Deno is maybe a single digit percentage of the market, just hyped tremendously. > E.G. compare tsx versus Node's native ts execution JSX/TSX, despite what React people might want you to believe, are not part of the language. > which only work if you pray three times on the day of the full moon. It only doesn't work in some contexts due to legacy reasons. Otherwise it's…

> JSX/TSX, despite what React people might want you to believe, are not part of the language. I think you misunderstood this. tsx in this context is/was a way to run typescript files locally without doing tsc yourself first, ie make them run like a script. You can just use Node now, but for a long time it couldn’t natively run typescript files. The only limitation I run into using Node natively is you need to do impo…

Yes, thank you for pointing that out. Forgot that there's a another thing named "tsx" out there.

I wouldn't call it running TS natively - what they're doing is either using an external tool, or just stripping types, so several things, like most notably enums, don't work by default.

I mean, that's more than enough for my use cases and I'm happy that the feature exists, but I don't think we'll ever see a native TypeScript engine. Would have been cool, though, considering JS engines define their own internal types anyway.

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

#125

Post by 1313ed01 »

wiseowise wrote: post #95
bee_rider wrote: post #78

Earlier quoted context omitted.

Python has the advantage that everybody sort of knows it is bad and slow, which is an important trait for a glue language. This increases the incentive to do the right thing: call a library written in C or Fortran or something.

It might be slow, but it is definitely not bad. In the contrary, it is a great language. The closest to pseudocode you can get in a mainstream.

That used to be true, but much of modern python code I see looks nothing like pseudocode. That advantage was lost around version 3, if not even before that.

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

#126

Post by theanonymousone »

johndough wrote: post #116
theanonymousone wrote: post #98

I wish someone commanded their agent to write a Python "compiler" targeting WASM. I'm quite surprised there is still no such thing at this day and age...

Not sure if this is what you are looking for, but here is Python compiled to WASM: https://pyodide.org/en/stable/ Web demo: https://pyodide.org/en/stable/console.html

No it's not. It's an "interpreter": The whole interpreter binary (in wasm) as well as the Python source is transferred to the client to be executed.

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

#127

Post by odiroot »

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…

For me it's the opposite. I'm actively looking for tools in Python because at least they're gonna be lightweight and easy for me to debug.

Really tired of every AI-related tool released as of late being a half-GB node behemoth with hundreds of library dependencies.

Or alternatively some cryptic academic Rust codebase.

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

#129

Post by ontouchstart »

ontouchstart wrote: post #128

I wonder when the title will be upgraded to “A minimal, secure Rust interpreter written in Python for use by AI”. Any human or AI want to take the challenge?

We already have a starting point:

https://play.rust-lang.org

https://github.com/rust-lang/rust-playground

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

#130

Post by 63stack »

miki123211 wrote: post #94
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…

3 reasons why Python is much better than JS for this IMO. 1. Large built-in standard library (CSV, sqlite3, xml/json, zipfile). 2. In Python, whatever the LLM is likely to do will probably work. In JS, you have the Node / Deno split, far too many libraries that do the same thing (XMLHTTPRequest / Axios / fetch), many mutually-incompatible import syntaxes (E.G. compare tsx versus Node's native ts execution), and featu…

>In Python, whatever the LLM is likely to do will probably work.

Do you not realize how this sounds?

>many mutually-incompatible import syntaxes

Do you think there are 22 competing package managers in python because the package/import system "just works"?

Post reply on HN