Humans manually typing out the bytes of source code has been an outdated method, since around a year. It simply doesn't scale as much as those same humans directing agentic teams. So yes, it would be about prompts.
The hard part isn't the technology for the language transition, that one is present today. pgrust shows the way. It's ensuring maintainers are cooperative, i.e. a social problem. Eventually you diverge too much if you do a fork, so it's better done in cooperation with upstream.
Just check how long it took LLVM or GCC to switch off svn for example, and a language switch is much more involved than a VCS switch.
[–] anonymous908213 3 days ago
[–] est31 3 days ago
[–] anonymous908213 3 days ago
[–] malisper 1 day ago
> We clarified with the author - while the binary had signs of optimization for specific benchmark queries, we have a reason to believe that the actual runtime didn't use per-query kernels... The usage of a query condition cache and cached statistics per granule is legitimate. The submission of a closed source preview version fine-tuned for benchmark was shady nevertheless. However, the new submission #2751 should move us post all the concerns.
Submitting an incomplete, closed-source preview build was a mistake on my part. Since then, we open-sourced a new version with full SQL support, ClickHouse merged it back into ClickBench, and the new version actually runs 7% faster (geomean) than the preview build that was removed.
You mean the pgrust which was recently caught for cheating benchmarks and incapable of even performing basic queries outside the benchmark set? Would love to see pgrust debunked by Jepsen like this other AI-generated, written in Rust, "formally verified" scam.
https://jepsen.io/analyses/particledb-1.1.4