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

431–440 of 592 posts

Re: Zig → Rust porting guide

#431

Post by PKop »

esjeon wrote: post #356
padjo wrote: post #239

Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Purely on that basis and ignoring the recent drama this seems like a reasonable idea for tech debt pay down to me. Assuming automated conversion can work without making things worse, which is not exactly a given.

Partially, the team would have never expected the project to be acquire before Bun touches v1.0.

Or, even if they 100% expected to be acquired before Bun touches 1.0, you could see how they might not care about this type of tech debt.

Re: Zig → Rust porting guide

#432

Post by [deleted] »

conartist6 wrote: post #426
Jarred wrote: post #319

I work on Bun and this is my branch This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to co…

Hoping that an AI rewrite is thrown out. You may even be an OK programmer, but IF YOU AREN'T ABLE TO DO THE WORK I DON'T WANT TO USE IT. Not worth your time? Not worth my time.

[deleted]

Re: Zig → Rust porting guide

#433

Post by bastawhiz »

archargelod wrote: post #59

Linked commit is probably not the most convincing for this tagline. Here's a branch[0] of Claude mass rewriting Zig code into Rust which is currently at 773,950 additions and 151 deletions: [0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port

Yikes. When Jarred left Stripe for the first time, he left behind multiple 10k+ line PRs rewriting code in the dashboard (this is before LLMs). It took months to work through those. A three quarter million line diff is essentially unreviewable.

Re: Zig → Rust porting guide

#435

Post by ozgrakkurt »

carpenecopinum wrote: post #296

Given the recent gripe that Bun/Anthropic indicated regarding compile times with Zig (i.e. that their vibe-coded 4x compilation speedup PR wasn't accepted), it appears to me as an "interesting" move to switch to a language that probably delivers 4x longer compilations than even vanilla Zig.

I am very sceptical zig actually compiles faster than rust.

I had similar code written in zig and c++ and cold compilation was many times faster in c++ and incremental compilation was instant in c++.

I think the reason most rust projects compile slow is because of excessive usage of dependencies and also the excessive use of metaprogramming in code.

Zig doesn’t have multiple compilation units so it doesn’t parallelize compilation

Re: Zig → Rust porting guide

#436

Post by sebastianconcpt »

Jarred wrote: post #319

I work on Bun and this is my branch This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to co…

Calm and curious about your results.

I hope you get the code elegant and not only maintainable but future friendly and performant.

Re: Zig → Rust porting guide

#437

Post by ozgrakkurt »

cropcirclbureau wrote: post #92

The only Bun shipped product I've used in anger is OpenCode and I regularly run into segfaults on it. I doubt this is the reason for migration but every time it happens, it reminds me the real cost of unsafe code. That being said, Zig is an absolute pleasure to write and I can't wait until it has a real library ecosystem, Rust's greatest boon.

How do you even run it with bun?

I get nodejs not found error when running opencode command in terminal. I installed it via bun too.

Re: Zig → Rust porting guide

#438

Post by Imustaskforhelp »

csande17 wrote: post #81
jabedude wrote: post #72

Earlier quoted context omitted.

Where is a source for either of these extraordinary claims?

https://x.com/jarredsumner/status/2048434628248359284

Jesus christ, This is the thing which should be talked about more. What an abysmally bad take. This actually makes me worry about the faith of bun more than any other thing discussed here.

Re: Zig → Rust porting guide

#439

Post by _vertigo »

0xpgm wrote: post #400
kelnos wrote: post #236

Earlier quoted context omitted.

The big difference here is that the C-to-Go tool was presumably deterministic: running it over and over again should produce the exact same result. You can trust that result because the human wrote the conversion tool, understood it, tested it, and worked the bugs out. The LLM is non-deterministic. You could have it independently do the conversion 10 times, and you'd get 10 different results, and some of them might e…

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.

Re: Zig → Rust porting guide

#440

Post by hardwaregeek »

weli wrote: post #332
Jarred wrote: post #319

I work on Bun and this is my branch This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to co…

I love your work on bun. How do you feel about all the constant concerns being raised about the quality of the project lately? I understand some of them might just be typical twitter hate but some of them are real. And I think people are right to question why you are adding image processing or web views inside a javascript runtime when there are bugs affecting production that sit unaddressed. For example on of our bi…

When you start getting hate, you’ve made it. Up until then you’re a hypothetical that people like. Maybe they’ve built a side project with you or read the docs. You only get hate when people have used your tool and butted up against limitations. We saw this with Deno too where they went from beloved potential savior to realistic, limited tool. Hate is good. It means people rely on you
Post reply on HN