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

81–90 of 179 posts

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

#81

Post by kodablah »

bityard wrote: post #21
kodablah wrote: post #3

I'm of the mind that it will be better to construct more strict/structured languages for AI use than to reuse existing ones. My reasoning is 1) AIs can comprehend specs easily, especially if simple, 2) it is only valuable to "meet developers where they are" if really needing the developers' history/experience which I'd argue LLMs don't need as much (or only need because lang is so flexible/loose), and 3) human langua…

I think the hard part about that is you first have to train the model on a BUTT TON of that new language, because that's the only way they "learn" anything. They already know a lot of Python, so telling them to write restricted and sandboxed Python ("you can only call _these_ functions") is a lot easier. But I'd be interested to see what you come up with.

> that's the only way they "learn" anything

I think skills and other things have shown that a good bit of learning can be done on-demand, assuming good programming fundamentals and no surprise behavior. But agreed, having a large corpus at training time is important.

I have seen, given a solid lang spec to a never-before-seen lang, modern models can do a great job of writing code in it. I've done no research on ability to leverage large stdlib/ecosystem this way though.

> But I'd be interested to see what you come up with.

Under active dev at https://github.com/cretz/duralade, super POC level atm (work continues in a branch)

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

#82

Post by IhateAI »

simonw wrote: post #73
IhateAI wrote: post #60

Earlier quoted context omitted.

[flagged]

How do you feel about software engineers who build open source libraries? Open source has been responsible for enormous productivity boosts in our industry, because we don't all have to build duplicates of exactly the same thing time and time again. But think of all of the jobs that were lost by people who would otherwise been employed building the 500th version of a CSS design system, or a template engine, or code t…

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 much open source, as its clearly being processed through these plagiarism laundering training regimes.

I don't really think LLMs, robotics and ML in general are going to increase GDP globally, they will instead just replace the inputs that were maintain the status quo (the workers). If they can't successfully replace human labor, it will at minimum greatly reduce its value, which is extremely dangerous.

Jobs grew greatly during the last 30 years of open source development but over the last 16 months we've had 350-400k SWE layoffs in the last 16 months in the USA. Many of these layoffs have been directly correlated to AI enhanced productivity. 25% of recent college graduates are unemployed. Jobs data is super unreliable at the moment, but we also will see large swaths of the lower skilled sectors, customer service for example, see huge layoffs in the coming 24 months.

Despite what C-Suites say about AI giving them more free time for their hobbies or whatever, they've yet to answer how people are going to afford those hobbies. Working as a barista lol? These same mouthpieces will say that llms are going to allow the same amount of engineers to get 10x more done, but they're not reflecting that in their business decisions. They are laying people off in swaths when equities are at all time highs, its abnormal.

I think its more likely the ruling classes will give us something to do by making us so poor that young men will beg to go fight wars. Put us to use on behalf of their conquest for more resources, that certainly did the trick in the 20s, 30s and 40s :/

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

#83

Post by eichin »

fulafel wrote: post #80
scolvin wrote: post #40

Earlier quoted context omitted.

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.

There's been a constant stream of v8 VM sandbox escape discoveries since its dawn of course. Considering those have mostly existed for a long time before publication it's very porous most of the time. And Python VM had/has its sandboxing features too, previously rexec and still https://github.com/zopefoundation/RestrictedPython - in the same category I'd argue. Then there's of course hypervisor based virtualization a…

part of why rexec is "historical" is that Guido was looking at some lockdown work and asked (twitter, probably?) the community to come up with attack ideas (on a specific more-locked-down-than-default proposed version.) After a couple of hours, it was clear that "patching the problems" was entirely doomed given how flexible python is and it was better to do something else entirely and stop pretending...

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

#84

Post by maxbond »

wewewedxfgdf wrote: post #58

If I say my code is secure does hat make it secure? Or is all Rust code secure unquestionably?

Of course not, especially when the security model is about access to resources like file systems that are outside the scope of what the Rust compiler can verify. While you won't have a data race in safe Rust you absolutely can have data races accessing the file system in any language.

Their security model, as explained in the README, is in not including the standard library and limiting all access to the environment to functions you write & control. Does that make it secure? I'll leave it to you to evaluate that in the context of your use case/threat model.

It would appear to me that they used Rust primarily because a.) they want to deliver very fast startup times and b.) they want it to be accessible from a variety of host languages (like Python and JavaScript). Those are things Rust does well, though not to the exclusion of C or other GC-free compiled languages. They certainly do not claim that Rust is pixie dust you sprinkle on a project to make it secure. That would clearly be cargo culting.

I find this language war tiring. Don't you? Let's make 2026 the year we all agree to build cool stuff in whatever language we want without this pointless quarreling. (I've personally been saying this for three years at this point.)

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

#85

Post by JoshPurtell »

IhateAI wrote: post #74
JoshPurtell wrote: post #69

Earlier quoted context omitted.

Every AI advancement liberates real humans from drudgery and allows them to create what they want more easily. The invention of the digital calculator turned human calculators into accountants, and that's great! We're contributing to the same process now

It liberates those who have massive resources to run gigantic models at whatever scale they want. Corporations and billionaires will get Ti-Nspires we get Ti-83s. I do not agree that inference will get more affordable in time to prevent harm. It will cause way more problems with the devaluation of labor before it starts to solve those problems, and in that period they will solidify their control over society. We alre…

Billionaires and corporations can hire teams of people to work for them full-time. You, likely, can hire one or two (or zero!). Not to make it personal.

These inequalities already exist

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

#86

Post by maxbond »

OutOfHere wrote: post #57
avaer wrote: post #11

Earlier quoted context omitted.

The repo does make a case for this, namely speed, which does make sense.

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.

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

#87

Post by spacedatum »

JoshPurtell wrote: post #70
spacedatum wrote: post #55

There is no reason to continue writing Python in 2026. Tell Claude to write Rust apriori. Your future self will thank you.

I do both and compile times are very unfriendly to AI!

Compile times, I can live with. You can run previous models on the gpu while your new model is compiling. Or switch from cargo to bazel if it is that bad.

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

#88

Post by JoshPurtell »

spacedatum wrote: post #87
JoshPurtell wrote: post #70

Earlier quoted context omitted.

I do both and compile times are very unfriendly to AI!

Compile times, I can live with. You can run previous models on the gpu while your new model is compiling. Or switch from cargo to bazel if it is that bad.

What compile times do you work with? I use bazel and it still hurts

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

#89

Post by globular-toast »

I don't get what "the complexity of a sandbox" is. You don't have to use Docker. I've been running agents in bubblewrap sandboxes since they first came out.[0]

If the agent can only use the Python interpreter you choose then you could just sandbox regular Python, assuming you trust the agent. But I don't trust any of them because they've probably been vibe coded, so I'll continue to just sandbox the agent using bubblewrap.

[0] https://blog.gpkb.org/posts/ai-agent-sandbox/

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

#90

Post by catlifeonmars »

redman25 wrote: post #64
catlifeonmars wrote: post #25

Earlier quoted context omitted.

Seems like we should fix the LLMs instead of bending over backwards no?

They’re good at it because they’ve learned from the existing mountains of python and javascript.

I think the next big breakthrough will be cost effective model specialization, maybe through modular models. The monolithic nature of today’s models is a major weakness.
Post reply on HN