Rewriting it using an LLM is one. But did all the contributors became as proficient in Rust as they were in Zig over night as well?
They are owned by Anthropic. They have virtually unlimited Claude credits.
Zig → Rust porting guide
271–280 of 592 posts
Re: Zig → Rust porting guide
#272Interesting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”. Yet here we are, what looks like a massive undertaking for vibe coding. Time will tell how this will turn out. Would be nice if the Bun maintainers could…
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.
Not only because the AI part, here's a discussion [0] about it
[0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
Re: Zig → Rust porting guide
#273Earlier quoted context omitted.
Yeah, I remember when the lazy bastards started writing programs using compilers instead of learning assembly language. Now I don’t have a single colleague who can write assembly. There’s whole generations now who can’t code assembly. Most don’t even know what a register is. Hope Zig holds against this latest attempt to make everyone stupid.
Using an LLM isn't analogous to using a higher level language.
That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic. That may be a problem but it’s still a higher level language, just a much higher level language than anything before.
Re: Zig → Rust porting guide
#274Its never been easier to rewrite X in Rust than today. Will everything eventually be rewritten in Rust and we finally achieve utopia?
... or will it all rust away?
OK I'm sorry, I'll see myself out.
Re: Zig → Rust porting guide
#275Earlier quoted context omitted.
Makes 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)
>Makes me wonder why zig announced the strict LLM rule recently. I guess there are 2 philosophies in software development: move fast and break things and move at a pace that guarantees everything is rock solid. Most commercial software, Anthropic included is taking the former path, while most infrastructure teams are taking the later. I guess Linux and FreeBSD kernels are also not accepting LLM based contributions ye…
> move fast and break things and move at a pace that guarantees everything is rock solid.
Zig is famous for taking the former path! Anyone using Zig for a few years knows every release breaks things, and they are still making huge changes which I would classify as “moving fast”, like the recent IO changes!
Re: Zig → Rust porting guide
#276Earlier quoted context omitted.
Yeah, I remember when the lazy bastards started writing programs using compilers instead of learning assembly language. Now I don’t have a single colleague who can write assembly. There’s whole generations now who can’t code assembly. Most don’t even know what a register is. Hope Zig holds against this latest attempt to make everyone stupid.
To add to the other commenters, loads of people don’t know assembly, which speaks to the quality of the average developer. The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code.
I'd be very surprised if the "average" developer across the board was in fact not just a JavaScript / TypeScript only developer. I have no expectations or really even hope that the average developer I work with has ever written a line of assembly.
Re: Zig → Rust porting guide
#277Earlier quoted context omitted.
Using an LLM isn't analogous to using a higher level language.
That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic. That may be a problem but it’s still a higher level language, just a much higher level language than anything before.
The main difference is that the input to an LLM is in an ambiguous language.
Re: Zig → Rust porting guide
#278Earlier quoted context omitted.
There are other reasons why a project like Zig might not want to accept LLM generated contributions. Zig, as programming language, has a multiplier codebase. A bug may affect a significant larger portion of users than most libraries or binaries will, as it's a fundamental building block of everything that uses Zig. Just that could be worth the extra scrutiny on every individual commit. There's also the usual argument…
> has a multiplier codebase. A bug may affect a significant larger portion of users than most libraries or binaries will Couldn't you say exactly the same about bun?
Sure, but Bun is now owned by a company who's entire shtick is creating AI models. That shifts priorities.
Re: Zig → Rust porting guide
#279I'll be very interested in how this AI port turns out. I am involved in a number of active projects that are being held back by the language / framework is holding back the project, but where a rewrite would be too big of a project to undertake by using only human power. I've had more success vibe coding Rust than I have in more dynamic languages. I suspect the strictness of the Rust compiler forces the AI agent to p…
> It could be just that I am less familiar with Rust so it feels like it's doing a better job. Dunning Kruger effect. At least you admit it.
This is pretty much the opposite of Dunning Kruger effect.
Re: Zig → Rust porting guide
#280Earlier quoted context omitted.
Zig is a moving target. 0.15 -> 0.16 includes some massive structural changes concerning IO and async/threading. Claude has absolutely no idea what it's doing with bleeding edge zig unless you feed it source and guide it closely (in which case it's useful for focused work) - I'm building a game engine & tcp/udp servers with it and it requires a hands-on approach and actually understanding what's being built. I imagin…
> it requires a hands-on approach and actually understanding what's being built. I think this is true regardless of what language you’re using. I’ve built a lot in Zig and there’s no difference between vibing stuff in it versus TypeScript/React. Claude can “one-shot” them both, and will mimic existing code or grep the standard library to figure everything out.
The code may run but it's rarely idiomatic. For example they almost never define functions inside the struct/union/enum namespace unless it already exists and follows that style, i.e. I expect "foo.bar()" but they make it "FooMod.bar(foo)".