| |
| ▲ | raphlinus a day ago | parent | next [-] | | 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. | | |
| ▲ | zamadatix a day ago | parent | next [-] | | 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. | |
| ▲ | piker a day ago | parent | prev | next [-] | | 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. | |
| ▲ | genxy a day ago | parent | prev | next [-] | | 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. | | |
| ▲ | raphlinus a day ago | parent [-] | | 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. |
| |
| ▲ | mlfreeman a day ago | parent | prev [-] | | at that point, how hard would it be to get the LLM to just make the binary? (iow, llm as compiler) |
| |
| ▲ | genxy a day ago | parent | prev | next [-] | | Once you have Wasm, it gets you everywhere and the best path to Wasm is Rust. | | |
| ▲ | drnick1 a day ago | parent | next [-] | | 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. | | |
| ▲ | lazypenguin a day ago | parent | next [-] | | 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. | |
| ▲ | a day ago | parent | prev [-] | | [deleted] |
| |
| ▲ | arbll a day ago | parent | prev [-] | | Funny in a thread that started with `increasingly makes sense for compile times` | | |
| ▲ | genxy a day ago | parent [-] | | Fine, I'll make a fast rust compiler. Rust with no deps and a single compilation unit is already fast. |
|
| |
| ▲ | linkdd a day ago | parent | prev [-] | | Just ask the slop machine to translate the binary to every platform. |
|
