6 ms·
They recently tried to upstream an improvement to zig, but were prevented from doing so because zig has a hard and fast "no AI code" rule. Whether you think thi
by andkenneth 5mo ago
They recently tried to upstream an improvement to zig, but were prevented from doing so because zig has a hard and fast "no AI code" rule. Whether you think this response is trying to put pressure on zig or whether they're just moving for practical reasons is up to you.
It's probably a bit of both.
- deleted 5mo ago[deleted]
- pton_xd 5mo agoAnthropic just needs to buy Zig! Problem solved.
- xeonmc 5mo agoTake off every Zig
- ratioprosperous 5mo agoIt's time! https://xkcd.com/286/ https://xkcd.com/286/
- kelnos 5mo agoWow. That xkcd was written in 2007, and part of the dialog is "didn't that [meme] die like five years ago?" Which means All Your Base, as a meme, was already getting somewhat stale by around 2002. It's hard to believe it's been that long.
- vaylian 5mo agoRelevant XKCDs: * https://xkcd.com/647/ https://xkcd.com/647/ * https://xkcd.com/1477/ https://xkcd.com/1477/
- deleted 5mo ago[deleted]
- Meneth 5mo agoYou know what you doing!
- mirekrusin 5mo ago...and rewrite it in rs.
- esperent 5mo agoPerfect A/B experiment opportunity. Fork Zig, call the fork Zag. Lock the syntax/api together for a couple of years. Allow AI code in Zag. Review after a few years, see which is better.
- GCUMstlyHarmls 5mo agoInteresting experiment, would it actually function if Zag was syntax/api locked to Zig? I guess Zag could still have api extensions.
- peesem 5mo agolast zig fork didn't go so well: https://ziglang.org/news/statement-regarding-zen-programming-language/ https://ziglang.org/news/statement-regarding-zen-programming...
- endospore 5mo agoMakes me wonder why zig announced the strict LLM rule recently. I'm afraid one reason could be that zig doesn't want to accept code from the bun fork in the first place (because of LLM usage, deviation and other reasons)
- ai_critic 5mo agoIt's a combination of pragmatism (not wanting to wade through slop, not wanting to shove out newbie developers) and politics (usual contemporary techie progressive stuff that's now oddly anti-technology).
- deleted 5mo ago[deleted]
- Onavo 5mo agoI like your username.
- deleted 5mo ago[deleted]
- happymellon 5mo ago> usual contemporary techie progressive stuff that's now oddly anti-technology You can be against a particular technology without being "anti-technology". See DRM/surveillance/bad self driving implementations.
- wiseowise 5mo ago> usual contemporary techie progressive stuff that's now oddly anti-technology Just because a thing exists doesn’t mean you have to use it for everything. You don’t use asbestos blanket? Why are you so against asbestos?
- a96 5mo agoAgainst blankets would be even more like that argument.
- wg0 5mo agoSo if tomorrow Rust denied the "improvement" to upstream Rust then what's the next language they plan to vibe code it in?
- echelon 5mo agoRust is legit one of the best languages to "vibe code" in. The emitted AST has a lower defect rate since it incorporates strong types and in-built error handling. Other pros include native code and portability, but downside is the compile time.
- nvader 5mo agoExcellent comment. As a downside, the compile time is somewhat offset once you're using agents (and especially parallel agents) anyway. Since all of your edits cost a round-trip API call to a third party server, you can accept a slightly slower compile step.
- wg0 5mo agoThis could be a subjective feeling with no real data to back it up. People say same about Go as well that it's type system and limited feature set makes it the best AI friendly language but there too, it just seems like a hunch rather than a proven fact.
- Onavo 5mo agoIf we are gonna go down that rabbit hole, then the natural conclusion is Haskell.
- boxed 5mo agoWhich seems pretty reasonable tbh. Claude Code is amazing with Elm in my experience.
- robocat 5mo agoHow good are LLMs at understanding Haskell errors and then dealing with them? The last time I had a go with Haskell, the errors reminded me so much of hellish terminal compilers from the 80s and 90s that I quickly gave up. Been there, not doing that again.
- abacadaba 5mo agoseems easier to fork zig
- kimos 5mo agoThen that becomes an ongoing effort. The rewrite is once. (Good idea or not)
- cybercatgurrl 5mo agogood, more reason to stay away from zig
- postepowanieadm 5mo agoStay away. Everyone wins.
- rdmsr0 5mo agoEven if AI had not been used, the changes would not have been upstreamed, see https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19?u=badtuple https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... tl;dr the supposed improvements are not sound and the zig compiler has already gotten a whole lot faster
- abpin 5mo agoThanks, that is the answer.
- abtinf 5mo agoThat is a devastating comment. I will now be extremely skeptical of bun.
- NewJazz 5mo agoWhat a sober, detailed forum post.
- nechuchelo 5mo agoThis should be the top comment in the whole thread. AI is not the point, the PR is just not of a good quality.
- parchley 5mo agoRead the previous discussions on the topic. Your summary is a sensationalist lie, since their change was apparently a smoking pile of hot garbage, and Zig already had similar performance gains in a newer release.
- deleted 5mo ago[deleted]
- DeathArrow 5mo ago>They recently tried to upstream an improvement to zig, but were prevented from doing so because zig has a hard and fast "no AI code" rule. And will Rust team accept their vibe coded patches?
- Hendrikto 5mo agoVery likely not, if they are of similarly low quality.
- kibwen 5mo agoNo. The Rust project developers are more lenient when it comes to developing patches with AI assistance, but the amount of leniency one receives is proportional to the amount of pre-existing trust a contributor has with the project, and every PR still has to be reviewed by an independent human. A stranger dumping a zillion lines of slop in a PR is a one-way ticket to having your PR politely closed.
- slanterns 5mo agoIt depends: https://github.com/rust-lang/rust/pull/155403#issuecomment-4263344910 https://github.com/rust-lang/rust/pull/155403#issuecomment-4...
- giancarlostoro 5mo agoProbably moreso going with the native language that is reliable and battle tested. Rust runs on Firefox, and in production at several systems across major orgs, this is not surprising.
- sevenzero 5mo agoI see that as a win for Zig.
- SkiFire13 5mo ago> but were prevented from doing so because zig has a hard and fast "no AI code" rule The patch would have been rejected either way because it was out of date and conflicted with other work going on.
- norman784 5mo agoNot only because the AI part, here's a discussion [0] about it [0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19 https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
- alethic 5mo agoIn the context of this post, that's absolutely hilarious they're vibe-porting their Zig codebase to Rust. I love Rust, but you couldn't pick a language with slower compile times... XD
- deleted 5mo ago[deleted]
- jeroenhd 5mo agoCompiling Rust is actually quite fast in my experience. The problem with many Rust projects is that they pull in dependencies left, right, and center. Pulling in Tokio makes your project compile an entire thread management system even if you're just compiling Hello World, and simple oneliners containing macros can easily spread out into dozens of lines of code each. Linking is also slow, and the extreme amounts of metadata produced for LLVM almost serves as a benchmark for LLVM's throughput, but that's all in an effort to produce faster, better binaries in the end. On godbolt.org, Hello World compiles and runs in about 250ms. Zig's Hello World compiles and runs in 600ms. Of course Zig is still an unfinished language so optimisations like these are probably hardly a priority, but when it comes to lines of code per second, the difference isn't as big as people make it out to be. What will make the most difference is how many crates the rewrite will pull in. The PORTING.md file specifies "No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`" for the second phase, which should definitely get rid of the excessive compile time many people associate with Rust projects.
- Tehnix 5mo ago>Compiling Rust is actually quite fast in my experience I guess it's all relative. I find Rust's compile times abhorrent and it's objectively slower than many many other languages that also pull in dependencies left, right, and center. I guess that just means Rust scales very badly with amount of code. I'd put it at a bit better than Haskell, but honestly not by much. I really wish Rust would focus much more on compile times, or on making smaller parallel compilation units. It's quite a chore to have to keep splitting your program into smaller and smaller crates just to not sit and wait for an eternity. As a comparison my CI job for Rust takes 14m running on a 16vCPU machine while my much larger TypeScript project compiles in 1m on a 2vCPU machine. I know people that have to spend quite a lot of work on keeping compile times manageable for Rust (nix, smaller crates, aggressive caching, etc etc). Rust still brings me enough value that I'll stick with it, but one can still dream of a better future :)
- jeltz 5mo agoI don't see why they think it would work when the reason their patch set was rejected was because it was not correct, did not go in a direction the Zig authors were interested in and is also in an area where they are already working hard on improvements. It would have been much better if the bun team joined forces and helped out instead of vibe coding a broken PoC patch that never can get merged. Compilation speed is one of the current main focuses of Zig and changing the type system to make that possible was a big part of 0.16. Anyone can hack up a quick PoC, even without LLMs, the hard part is writing code that is correct and maintainable.
- wiseowise 5mo ago> It would have been much better if the bun team joined forces and helped out instead of vibe coding a broken PoC patch that never can get merged Bold of you to assume they have the expertise.
- merlindru 5mo agoBun folks routinely contribute to WebKit, and bun itself is an incredibly impressive project, so I don't think they're lacking expertise
- jeltz 5mo agoI think they do. Building bun is a complex task and engineers who can do that should also be able to figure out how to help out with a compiler. It is just a matter of immersing yourself in the code and be willing to put in the hours and hard work. Sure, they may not be able to help out with designing the type resolution but there is other work which needs to be done that any skilled engineer can do.
- rdmsr0 5mo agoSide note, but I think using LLMs like this to write PoCs in existing projects is actually a good idea to prove whatever you had in mind is feasible and worth it to pour time into. Obviously you need to not vibecode the entire thing once you're past that point though...
- 5mo ago
- rob74 5mo agoYeah, now that I think about it, having a major project written in a language that doesn't accept AI contributions now owned by a major AI company was a recipe for dis... er, conflict. I'm not a huge fan of Rust, but I guess having a project like Bun in an actually memory safe language is probably a win? Guess it depends on how good Claude is at writing Rust code...
- codethief 5mo ago> but were prevented from doing so because zig has a hard and fast "no AI code" rule No, they were prevented from doing so because the Zig devs didn't like the proposed changes and are preparing a more comprehensive improvement.
- TiredOfLife 5mo ago> They recently tried to upstream an improvement to zig They didn't.
- Hendrikto 5mo agoThe Zig maintainers did a pretty in-depth review of the PR, and laid out multiple technical reasons for why it would not get merged. They did not reject it simply for being vibe-coded (though that is likely the cause of it sucking).
- fridder 5mo agoNot only that but Zig was working on a similar improvement to their change already