Hacker News Reader

Comment by piker | Hacker News Reader

C increasingly makes sense for compile times if you can have a separate Fable pass on memory safety, etc.

Assembly is increasingly making sense for compile times if you can have a separate Fable pass on code correctness, etc.

I think you’re kidding, but wouldn’t you have to maintain different code bases for each platform? C compiler gets you everywhere and WASM.

Yes, and? As the cost of code generation approaches zero, this starts to make more sense, especially if you do have mechanisms in place to ensure safety and correctness.

I did an experiment a couple weeks ago of having Opus 5.5 translate an MP3 decoder from Rust into Cortex-M33 assembly language, both raw asm and symbolasm. The code was 3x smaller and ~1.5x faster than Rust -O3. These seem like gains that are worth it.

Yes that makes sense, but if you're iterating on software then I think C will generally win due to its ability to compile cross-platform until you want to build a "release" which you could do by having Fable translate it to ASM at that point.

Did you have it go directly to asm or emit the assembly from the Rust toolchain and then contract that? For small stuff, I have been having it write directly, or larger pieces I am having better results via contractions.

For this experiment I had it write directly.

I should add, part of the experiment was to test whether having variable names and (C style) types would help the LLM. For a task of this size (about 1.5 kLoC Rust, 3k insn asm) it was inconclusive, but for larger projects I suspect it would make a difference.

And the plan for symbolasm is to move past C style types into Rust style and maybe dependent typing, specifically to facilitate automated proofs.

at that point, how hard would it be to get the LLM to just make the binary? (iow, llm as compiler)

As the cost of code gen approaches 0 the cost of the test suite actually grows. Not just in definition, but execution.

An MP3 decoder for a single target doesn't really run into that complexity, a UI components library for (Linux, Windows, macOS) * (x86-64, ARM64) suddenly has a 6x multiplier on what was already something with waaay deeper dependencies and integrations than MP3.

At least that's what I've noticed vibing my DE without external libraries. It went really fast when the complexity was small because most of the work was in adding code. Then it started taking longer to build and test, even with optimized builds and tests, than it took for the AI to do its part.

Just ask the slop machine to translate the binary to every platform.

Once you have Wasm, it gets you everywhere and the best path to Wasm is Rust.

Funny in a thread that started with `increasingly makes sense for compile times`

Fine, I'll make a fast rust compiler.

Rust with no deps and a single compilation unit is already fast.

But Rust is unreadable compared to reasonably well written C. It matters if you care to read any of the code yourself and/or want to retain the ability to make manual changes. There is a reason C hasn't been displaced after all this time.

What an odd statement. Unreadable code is unreadable regardless of language. I’ve seen my fair share of unreadable C. Indeed Rust can be ugly in advanced use cases with heavy syntax but C’s simpler syntax does not mean it is always readable either. Hell, I've seen unreadable Python and Lua!

C has in fact been displaced in many places. Just because it survives in a few holdout contexts is a historical artifact more than a testament to the language.

C has always made sense for building software as long as you do a memory safety pass.

The tools have gotten fancier, for sure, though.

I'm observing the opposite phenomenon. I recently vibecoded (with supervision) a 25k-line Rust codebase that takes 15 seconds for every build. If I were writing that by hand, a 15-second build time would drive me crazy and I would stop working until I could find a good way to speed it up. With vibecoding it barely matters, because the interval between builds is much longer and the agent (Opus 5.5) spends most of its time thinking or running tests. Unlike me, the agent rarely makes the kind of trivial mistakes that require rebuilding multiple times in a row.

For larger codebases, things might be different.

https://fil-c.org/ exists

Leaving memory safety up to a model is wild. That's not a sound guarantee of safety for anything.

Reply on news.ycombinator.com