Hacker News Reader

Comment by gregwebs | Hacker News Reader

Rust does have one glaring weakness: compile times. I suspect in the LLM era we will see the rise of a language or perhaps some sort of Rust redesign that achieves what Rust has with great performance and great type safety but also has better support for fast compilation.

I have found that agents are good at writing Verus proofs in a Rust code base, and that these proofs have only a minimal negative effect on the normal compilation path. I have a skill for using Verus: https://github.com/gregwebs/skills-sdlc/blob/main/skills/rus...

View on HN

Compile times are really only an issue of you need to iterate extremely fast.

One of my spare time projects is a "prompted" 3D modeling app that is now (incl sub-crates I maintain) about 500k lines of Rust.

The link stage is the longest. An incremental build (w. sccache+mold) where I changed a few source files is done and runs after maybe 20s max on my 2022 Rhyzen 6800H-powered laptop.

I think this is acceptable when working on that kind of project.

For games where this matters I usually prototype in some other language first, TS, Python, Lua, whatever then translate to Rust when game mechanics and magic numbers are settled.

Or you simply put those into a config file that gets watched by the game.

At work we have an image manipulation crate that takes like 30mins to 'dev' and about an hour to 'release' build.

The WASM version takes even longer, about 2h, and needs like 55GB RAM during build.

But that crate has only to be built once a month.

And if it mattered we could split it because it's a metacrate made of ~20 sub-crates.

Yeah, it would be nice if Rust were even faster (I remember compile times almost a decade ago, when I started using it)!

But I think for the typical use cases where you would (should!) reach for it, it's quite ok already.

And if not you can work around it quite painlessly.

> Compile times are really only an issue of you need to iterate extremely fast.

Isn't that the point of agents?

The agents are only blocked by this when the features they implement are extremely simple.

The average feature I spec and have an agent implement takes an hour or two (Either Opus 5.5 or DeepSeek 4.1 Flash, both at high and using subagents).

In-between the agents do not build that often because that is instructed in my setup.

They build maybe every 20mins when the target is Rust.

Ofc the models do not work like this by default. In fact they want to build all the time.

But as always, you need to tune the harness/setup for what you're using.

IMHO: if you use these models with Rust w/o those constraints/instructions "you're holding it wrong".

It’s especially bad when working on multiple projects at the same time. Memory and CPU contention kills performance.

I’ve switched one of my projects to Go and it took a day for Opus to do the port and another couple of days to finish the features I wanted. I’ve never liked the language and still use Rust in plenty of places, but I can’t argue with how much faster iteration is.

That is because rustc really maxes out the cores.

Ask your agent to build a simple bash/zsh/whatever cargo wrapper that maintains a machine build lock.

It should exclude cargo check, tree etc. ofc.

CPU contention from parallel cargo runs absolutely kills (build) performance.

Also my setup has instructions that agents keep working if they have open items while the lock is taken; i.e. launch a subagent or a shell with a watcher to run the build and don't block on it.

This makes all the difference when you have multiple agents on multiple workstreams on the same machine and they target Rust.

Mojo looks interesting [0]. It is designed by Chris Lattner himself [1] and has an interesting take on borrowing references (Rust's DNA) comptime execution inspired by Zig. And it targets CPU and GPU (NPU, TPU) as first class targets. Recently reached 1.0 release.

[0] https://mojolang.org/

[1] https://en.wikipedia.org/wiki/Chris_Lattner

Precompiled libraries would go a long way, there aren't that many popular combinations of OS/CPU/...

Yes but multiply by feature flag combinations.

I don't think that would make such a change when developing; you typically only build 3rd-party libs only once.

We're coming from (huge) C++ codebases, which aren't particularly fast either. It's not a major problem IMO.

The cost highlighted in the article is not the compilation time, but the process of integrating the proof tool itself.

Reply on news.ycombinator.com