the thing I don't understand about this, given that the goal was a line-by-line transpilation, and the author had already transpiled it once from Go to Zig, why not write an actual transpiler? A problem is as complex as the smallest program required to solve it, and having an LLM, which doesn't produce deterministic output churn through almost 200 grand when you only need to write a deterministic program maybe 5% of that size seems like not a great way to go about this
Because the author isn't employed by a transpiler company.
The entire point is to get people to spend money on LLMs. Writing a transpiler - even a LLM-coded one - pretty much defeats the purpose.
This is a frequently mentioned criticism. Is there a good argument about why that approach could have been done in the same amount of time? Seems like larger scope and more uncertainty to me.
>Is there a good argument about why that approach could have been done in the same amount of time?
as I said because it's a much smaller codebase. This is a million lines of code project. A literal Zig to Rust translation that is mostly syntactic is not going to be more than 10-20k LOC for a transpiler. That's two orders of magnitude less work.