Nothing. You can always vibe-code in Rust even when the rust-lang/rust repository itself largely forbids vibe coding.
reply> even when the rust-lang/rust repository itself largely forbids vibe coding.
replyThis policy does not seem to forbid vibe coding?
It does in the narrower sense of vibe coding (as opposed to more general agentic coding, which is also called vibe coding from time to time...).
reply> Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM are allowed, with disclosure.
Vibe coding (in its original meaning) would have hard time arguing it's of high quality.
I read it as a hypothetical
replyBut one of the reasons they switched was because the compiler upstream for the original language they used, Zig, wouldn't accept slop contributions they wanted to make for Bun perf. What will they do when they need to try to push a slop contribution upstream to rust?
replyAt this point they will probably just fork yet again and maintain some vibe compiler.
Is there a citation for this? This was my suspicion but it's quite amazing if this was the actual reason for the bun spectacle
replyNo, they've explicitly denied it.[0] However, they do regularly dig at how much faster their fork is[1][2] that they can't merge because of Zig's AI policy.
reply[0]: https://x.com/jarredsumner/status/2051600118886138262
Huh. I wonder if the original intent was to merge an AI generated PR to a high-profile project like Zig. It makes the headlines and generates hype. But that went embarassingly bad for them so they had "port Bun to Rust" as a backup.
replyThey should make FullstackLang. It compiles English in .md to machine code that can directly run on the specialized hardware it designs for it that you have to 3d print at runtime. Every program gets its own custom hardware. Composability and reuse be damned. Pay the token masters for every thought you have
reply