zlacker

[return to "Monty: A minimal, secure Python interpreter written in Rust for use by AI"]
1. avaer+Mm[view] [source] 2026-02-06 23:36:09
>>dmpetr+(OP)
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'm gonna lose this one too.

◧◩
2. miki12+621[view] [source] 2026-02-07 08:17:57
>>avaer+Mm
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 features like top-level await (very important for small scripts, and something that an LLM is likely to use!), which only work if you pray three times on the day of the full moon.

3. Much better ecosystem for data processing (particularly csv/pandas), partially resulting from operator overloading being a thing.

◧◩◪
3. Tade0+Q61[view] [source] 2026-02-07 09:26:34
>>miki12+621
> 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 just elaborate syntax sugar for `Promise`.

◧◩◪◨
4. mcinty+k91[view] [source] 2026-02-07 10:10:20
>>Tade0+Q61
> 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 import types as type imports, which I doubt would be an issue in practice for agents.

◧◩◪◨⬒
5. Tade0+If1[view] [source] 2026-02-07 11:42:03
>>mcinty+k91
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.

[go to top]