Zig → Rust porting guide

Post by gjvc » Tue, May 05, 2026, 3:27 PM UTC

desdenova wrote: post #495

sarreph wrote: post #349

Earlier quoted context omitted.

It is a pity that you can't make an experimental commit on an experimental branch without igniting a fire of delirium through some people who -- if they were able to put their emotional response aside for a minute and could weigh this up on the basis of merit -- would probably agree with the motivations for researching this approach. > if/how hard it’d be to get it to pass Bun’s test suite and be maintainable Every m…

The fact someone who works on Bun is willing to create and even push a branch generated by a stochastic parrot is very telling of the direction the project is going. Doesn't matter if it's "experimental", it's a dumb experiment that shouldn't exist.

Post by tcfhgj » Tue, May 05, 2026, 3:42 PM UTC

Tehnix wrote: post #398

jeroenhd wrote: post #361

Earlier quoted context omitted.

Compiling 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 me…

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

Post by zamadatix » Tue, May 05, 2026, 3:48 PM UTC

conartist6 wrote: post #453

ForHackernews wrote: post #446

Earlier quoted context omitted.

Cool. Fork it and maintain your own runtime, then. Why are you complaining about what the bun team does with their project?

Cause I'm sick of this amateur hour shit

Post by ModernMech » Tue, May 05, 2026, 3:59 PM UTC

etoxin wrote: post #46

versecafe wrote: post #21

Earlier quoted context omitted.

This is likely irrelevant given bun has stopped taking community PR's entirely and Jarred is pitching that human contributors should be banned.

There is like 1,713 open PR's on the Bun repo. I'm assuming all are from Claude or robobun?. I guess this gives us an insight on what the claude-code workflow look likes. Crazy times.

Post by professoretc » Tue, May 05, 2026, 4:06 PM UTC

_vertigo wrote: post #439

0xpgm wrote: post #400

Earlier quoted context omitted.

Perhaps a viable approach might be to vibe code the translation tool itself and observe that for every input it gives the expected output. Then once the translation is done, the translation tool can be discarded. This would require a robust test suite though. One of the cases where vibe coding might actually be useful, writing a throwaway tool.

I see this dilemma with LLMs all of the time. Should you use the LLM to do the thing directly, or use the LLM to implement a tool that does the thing? I tend to reach for the latter, it’s easier to reason about.