[drob518]

The post focuses on Python, but I think it touches on an interesting question before skipping past it: ideally, what language would be best for our AIs to be programming in? The article says Rust. But can we do better? Rust has strong typing and memory guarantees which I think are important, but it’s also slower to compile. If we’re going to be doing agentic programming, where the agent is operating in a tight loop, iterating on the code, then it seems like we’d want something that can be faster to run after creating new code. Effectively, we’d want the agentic equivalent of a Lisp REPL, but optimized for the agent, or at least a language that compiles quickly, as it is run. This is one of the roles that Python plays today. Perhaps there is also a slow, sophisticated compiler that digests the same syntax and spits out the fastest , most secure code possible once the agent has iterated its way to the final answer.

[reuven]

A very interesting point. Coding with AI definitely requires tight, fast loops. I don't have much experience with Rust, but I had heard that the compiler is slow (because it's doing so much thinking and checking in advance).

I'm OK with Lisp output, but maybe that just shows how old I am. :-)

I wonder if it's possible (or wise) to have two different compilers for a language -- one that's optimized for such tight loops, and another that does thorough checking, etc. You know, kind of like -O, but at a much deeper level.

[aw1621107]

> but I had heard that the compiler is slow (because it's doing so much thinking and checking in advance).

The compiler is indeed not particularly speedy, but the reason you were given is not entirely accurate. As measured in this blog post [0] different parts of the compilation pipeline will take different amounts of time depending on what you're doing (cargo check vs. incremental build vs. full build, building a library vs. binary, etc.), but generally speaking type/borrow checking take up relatively small portions of compilation time (~15% or less, based on eyeballing the charts [1, 2]) compared to everything else.

> one that's optimized for such tight loops, and another that does thorough checking

I think that would risk producing diverging language subsets, especially if the checks are essential for language semantics. For example, what exactly does it mean if a program passes the "relaxed" compiler but fails the "thorough" one? How close does that actually get you to a "real" working program?

[0]: https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-ta...

[1]: https://kobzol.github.io/assets/posts/compile-sections/binar...

[2]: https://kobzol.github.io/assets/posts/compile-sections/libra...

[arw0n]

I mean if we're getting really serious about ai-first development, we might be able to get away with a ton of micro services written with clear, simple apis to communicate all in a giant mono-repo managed by an army of agents. That way the full surface any one agent has to touch is small, compile time of each individual service is very fast, and services can be hand-written if super critical.

Anyway, I've played around with the idea a bit so far, and it seems that current agents/harnesses use way more tokens with that architecture.

[pjmlp]

This exactly how integrating tools with AI agents in low code/no code orchestration engines looks like.

See Workato, Bomi, LangFlow,...

[yjftsjthsd-h]

It seems like the obvious point of tension is that you probably want AI to be constrained to/by some rigor. Rust is good because it enforces some safety measures, but I'm more interested yet in the work to have AI work with lean4 or the like to prove its code is up to spec. But that proof checking is probably in direct conflict with fast compilation.

[dnautics]

yeah but you dont have to proof check every cycle, anyways rust safety is not the slow step

[Garlef]

> what language would be best for our AIs to be programming in

I think "batteries included" is not a good thing to have in the future.

We'll want to be very explicit about what AI generated code can and can not do.

And so some form of effects based scripting language seems like a plausible choice: A language where by default "all batteries are removed".

[drob518]

Good point. I think you’re right. We need more rigor for the AI, which would actually help code generation, I suspect. Included batteries are for humans and AIs don’t need convenience.

[dnautics]

Definitely not python. at least in the immediate future, context is the limiting factor, and not knowing if a function call might mutate your object is not good for context (the llm must either dangerously assume or look it up, both of which are context-expensive)

[satvikpendem]

OCaml, its compiler is very fast, and it has a stronger type system than Rust in some areas.