Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig → Rust porting guide

github.com

Post reply on HN
Print view View original

301–310 of 592 posts

Re: Zig → Rust porting guide

#301

Post by epolanski »

TheRoque wrote: post #62
fcarraldo wrote: post #19

Earlier quoted context omitted.

Contributors and maintainers will also be easier to find in Rust than Zig. Zig is a great language and I want to see it succeed, but this is a prudent move for Bun.

Why didn't they use Rust in the first place then ? All this was true before AI

Zig has some advantages for such projects, especially in the beginning.

Among them:

- much easier to iterate on (due to the language being simpler and compilation much faster)

- native C/C++ interops (Zig can compile C and C++ and mix it with Zig) which is crucial for a node-replacement runtime that runs an open source JS engine

- fewer dependencies and trivial static linking

I guess that now that they've been acquired by Anthropic there's this combination of having both in-house Rust talent, AI which does better on Rust, and the funding and resources necessary to undertake such a migration.

Re: Zig → Rust porting guide

#302

Post by jeltz »

DeathArrow wrote: post #249
endospore wrote: post #137

Earlier 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…

> I guess Linux and FreeBSD kernels are also not accepting LLM based contributions yet.

PostgreSQL, a famously slow and rock solid project, accepts LLM-based contributions. But they are held to the same high standard, if you cannot explain the patch you submitted it likely get rejected.

Re: Zig → Rust porting guide

#303

Post by uncircle »

DeathArrow wrote: post #269
uncircle wrote: post #237

Earlier quoted context omitted.

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.

>The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code. That is if you use something like C, C+=, Java, .NET, Go. With Javascript and Python I don't think knowing assembly would make any difference because it's hard to optimize the code in these languages for how the CPU and memory works.

Knowing assembly in this day and age is the result of being curious and wanting to understand how computers work, which means knowledge of algorithms, data structures, etc.

The same applies to vibe coding: the best "vibe coder" will paradoxically be the person with enough knowledge and curiosity to understand programming, how computer works and the subject at hand; one that could write the whole thing from scratch so they have enough judgement to review generated code.

Of course the vast majority will be mediocre vibe coders, and even worse programmers; at least that's the direction we're going.

Re: Zig → Rust porting guide

#304

Post by sandbags »

Philpax wrote: post #195
slopinthebag wrote: post #188

Earlier quoted context omitted.

> I expect OSS to go the opposite direction: no human contribution allowed. How is it an incorrect interpretation? Jared is indeed pitching/suggesting/predicting that human contribution will not be allowed in the near future, i.e. banned.

A prediction is not a policy.

When you use the word “allowed” it becomes a policy.

Re: Zig → Rust porting guide

#305

Post by wiseowise »

jeltz wrote: post #293
andkenneth wrote: post #100

Earlier quoted context omitted.

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.

I 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…

> 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.

Re: Zig → Rust porting guide

#306

Post by jillesvangurp »

Humphrey wrote: post #16

I'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…

I've been targeting Go instead of Rust for a few things. But same deal, I'm not really a Go programmer and it seems to work well enough. I do have a few decades of engineering all sorts of code bases; so I'm not coming at this completely naively.

My way of compensating for my own inability to do detailed code reviews is making sure the tests, integration tests, end to end tests, cover everything I care about. Without that, you can't be sure it is not skipping detail work. I've also made it do some bench marking and stress testing and then analyze the code base for potential bottlenecks. After it found and fixed a few issues, it got better. Finally, prompting it to do critical reviews, look for refactoring opportunities, etc. can give you a nice list of stuff to fix next. Having it run memory leak checkers and static code analysis tools also is a good strategy. Once you start running low on issues you find this way, the code is probably not horrible. Or at least you hit some sort of local optimum.

The lack of code reviews sounds pretty horrible. But it is now quickly becoming the biggest bottleneck in AI assisted coding. Eliminating that bottleneck is scary but it enables a few step changes in volume of code that becomes possible. Using strict compilers and strict memory management helps eliminate a few categories of bugs and issues.

I was previously doing this with languages I do understand. Once you start routinely dealing with larger and larger commits, reviews become a problem.

I expect working with larger code bases like this will get a lot easier and better over time. I noticed that the main headaches I face with this type of engineering are the tendency of models to keep deliberately cutting corners, only doing happy path testing, or deferring essential work for later. I suspect a lot of the models are simply biased to conserving token usage. Pretty annoying but also easy to compensate for with follow up prompts and testing. And probably something that becomes less of an issue as the models get tuned to behave better without additional prompting.

Re: Zig → Rust porting guide

#307

Post by jedisct1 »

allthetime wrote: post #25
Avicebron wrote: post #8

Earlier quoted context omitted.

I imagine claude is better at Rust than Zig?

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…

The Rust ecosystem is also a moving target.

Virtually all crates are still at version 0.x and introduce constant breaking changes: [https://00f.net/2025/10/17/state-of-the-rust-ecosystem/](https://00f.net/2025/10/17/state-of-the-rust-ecosystem/)

If you don’t want to use obsolete versions of dependencies, you need to explicitly tell the model that. Then you have to hope it can adopt new APIs it wasn’t trained on, rewrite existing code to handle the breaking changes, and keep your fingers crossed that nothing else breaks in the process.

LLMs perform much better with Go, not only because of the lack of hidden control flow (LLMs can deal with that, but it costs a lot of tokens) but mainly because both the language and its dependencies introduce very few breaking changes.

Re: Zig → Rust porting guide

#308

Post by vga1 »

Capricorn2481 wrote: post #134

April 26th - Bun announces they used AI to fork Zig so they could make an optimization for a 4x improvement April 27th - Zig contributor mlugg clarifies why the specific optimizations Bun did were ill advised and wouldn't have been accepted in Zig, regardless of AI use [1] May 4 - Bun is looking into Rust as an alternative. This, to me, seems like total whiplash. Has anyone at Bun made a statement on why they're maki…

I would assume that Zig was a risky choice to start with, and Rust was always lurking as a sensible option behind the corner. This probably just broke the camel's back.

Re: Zig → Rust porting guide

#309

Post by psychoslave »

petre wrote: post #163
wg0 wrote: post #145

Earlier quoted context omitted.

So if tomorrow Rust denied the "improvement" to upstream Rust then what's the next language they plan to vibe code it in?

C obviously.

You missed the part were everyone is going to run its own vibe coded assembly tools[1].

So the next step will be that bun will be directly re-written from scratch at every iteration, the repository will only contains the specs for the LLMs.

Caching locally the generated code will be authorized for some transition period, but as it’s obviously very dangerous to let people tweak what exactly computers are doing, forbidding such a practice using safe secure boot mandatory mode is already planed. Only nazi pedophiles would do otherwise anyway, thus the enactment of the companion law is an obvious go to.

[1] https://news.ycombinator.com/item?id=47997947

Post reply on HN