logoalt Hacker News

reuventoday at 2:14 PM2 repliesview on HN

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.


Replies

aw1621107today at 5:35 PM

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

arw0ntoday at 3:08 PM

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.

show 1 reply