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.
Where is a source for either of these extraordinary claims?
Zig → Rust porting guide
81–90 of 592 posts
Re: Zig → Rust porting guide
#82Earlier quoted context omitted.
But why should they? This just seems like the groundwork for an initial refactor and moving from one language to another. They haven't actually committed to switching from Zig to Rust yet. I mean, I get if you are an investor and you want to see if they are using their time effectively, but why would it matter to anyone else?
Lots of people, me included, heavily invested their time and expertise into Bun, using it as a daily driver, to bundle production code or even using it in production as a JS/TS runtime. Of course, we are interested in Bun to stay a useful tool. The Anthropic acquisition was worrying enough on its own.
But there isn't any change in someone's expertise in Bun though, currently, just in development. Why would they have to dive you into a daily stand-up about their development process?
Re: Zig → Rust porting guide
#83Re: Zig → Rust porting guide
#84>*No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`.* No `std::fs`, I'm not a rust dev but even I kind of notice that tokio is kind of shunned in most projects. Why is that? Is it just bad or what?
tokio is great and it's pretty performant, but you pay an allocation for every future unless you do some complex organization of your futures. Source: I worked on Deno, competed directly with Bun on HTTP performance (and won on some metrics). Edit: and of course I typed future instead of task (aka "spawned future"). Thanks, child commenters below. Much of Deno was built on spawning futures that mapped to promises and…
Do you mean allocate on every task?
Re: Zig → Rust porting guide
#85Earlier quoted context omitted.
I think the big difficulty here is that Rust's ownership model in particular tends to require certain kinds of control flow to avoid a bunch of weird churning/copying, which makes it not as straightforward of a port target from other imperative languages. Like maybe you get the LLM to try _really hard_ to churn through everything, but this feels like a big case of "perils of the lack of laziness". Of course if you ha…
This is all wild conjecture, but I'd assume that teaching the LLM to do that mapping is an achievable goal and then it get's close to automatic -- effectively slurp the source AST into a rust AST and render. My only experience with ports so far is Python to Go, and it's been near flawless (just enough stupid shit to make me feel justified to be in the loop).
I'm porting a large-ish delphi application to c sharp. It's been pretty hands-off except for converting to async and some language capability mismatch.
Re: Zig → Rust porting guide
#86The problem with vibe coded re-writes is that you basically sign off on understanding the generated codebase at that point. Any historical knowledge of the codebase is gone.
Re: Zig → Rust porting guide
#87Earlier 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.
100%. For many people, Bun is the only reason they've even heard of Zig. I'm not in a position to comment intelligently on comparative language features per se, but when it comes to mindshare and community size, Rust is a clear winner.
fwiw before today I'd heard of Zig and not Bun :D
something JS-adjacent could certainly be more known than an obscure language but are that many people using drop-in node replacements?
Re: Zig → Rust porting guide
#88Earlier quoted context omitted.
I imagine claude is better at Rust than Zig?
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.
I wouldn't call any port "prudent". In general, taking mature software and doing any major rewrite is one of the riskiest thing you can do. It is a large scale attempt to fix what isn't broken.
Sometimes it is worth it, but it may also kill projects. A risky move. And AI doesn't help its cause. AI can save a lot of time when making ports, it is one of the things it does best, but it doesn't protect from regressions.
I am not using Bun in production, but if I was, I would consider it a risk. Not because of Rust vs Zig, but for changing things that work.
Re: Zig → Rust porting guide
#89Interesting. When I thought of Zig, I thought of Bun. In my mind it was the flagship application for that language. Is there another? I wonder how the Zig team feels about this. To me it seems like Rust has definitively won now.
Ghostty is mainly Zig aside from the UI parts.
Re: Zig → Rust porting guide
#90This is a huge loss for the zig language and community.
As a fan of the language, I hope it leads to some reflection on things that might need to change moving forward.