Live data from Hacker News

Zig → Rust porting guide

github.com

451–460 of 592 posts

Re: Zig → Rust porting guide

#451

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

Nah, let the Zig foundation cook.

Both their AI policy and their rejection of Bun's performance PR were level-headed and well-reasoned. And the link seems more like a proof-of-concept than anything else.

It's true corporate sponsors are a big help with language development, but not at the expense of conceptual integrity.

Re: Zig → Rust porting guide

#453

Earlier quoted context omitted.

The "too late" argument isn't gonna fly with someone like me who has both the time and energy to own a Javascript runtime. Heck, I'm quickly becoming the most prolific author of the ES spec too.

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

Re: Zig → Rust porting guide

#454

Earlier quoted context omitted.

The title kinda set the tone for this post.

The title is "Bun is being ported from Zig to Rust". The docs/PORTING.MD starts with "Zig → Rust porting guide" I don't think the tone was the problem.

Imaging title it "Bun is being ported from Zig to Rust in an experimental branch" though. Not enough drama with that

Re: Zig → Rust porting guide

#455
post #332

Earlier quoted context omitted.

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

Do you know which project gets the most hate? Nodejs, so in that sense, Nodejs has made it and it is widely deployed but this hate was the reason that two seperate alternatives for Node have emerged as Deno and bun.

Recently Bun's latest version had memory leaks which crashed production code from my understanding and their attitude[0] of saying OSS will have no human contribution allowed, now doing these ports of zig to rust, going back for years what the decision making of using zig was and this code basically being vibed as there is no way that they are reviewing the code while being VC funded/bought by anthropic.

These are all genuine issues which cause hate. You can say people are hating because people rely on it but the true thing is that also seems like a bait and switch and that people switched from node.js to bun (maybe even being locked inside bun), only for them to do these highly questionable decisions which is the reason why people are starting to hate on bun.

Atleast that's my interpretation right now reading this whole thread.

[0]:https://x.com/jarredsumner/status/2048434628248359284: "I expect OSS to go the opposite direction: no human contribution allowed. Slop will be a nostalgic relic of 2025 & 2026."

- Jarred Sumner

Re: Zig → Rust porting guide

#456

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

From what I'm reading, it's too late for Bun. I hear the whole dev stream is slop now. It was nice while it lasted, but that's not a foundation to build rock-solid stuff on top of. Not for me, not for them, not for anyone.

Re: Zig → Rust porting guide

#457

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

You might be interested in learning more about `-fincremental`, that's how Zig gives you fast rebuilds.

Re: Zig → Rust porting guide

#458
post #383

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

The big loss for the Zig community would be if they stopped donating to ZSF. They have estranged themselves from it for a while.

Bun has stopped donating to the ZSF after the Anthropic acquisition.

Re: Zig → Rust porting guide

#459
post #454

Earlier quoted context omitted.

The title is "Bun is being ported from Zig to Rust". The docs/PORTING.MD starts with "Zig → Rust porting guide" I don't think the tone was the problem.

Imaging title it "Bun is being ported from Zig to Rust in an experimental branch" though. Not enough drama with that

I couldn't use that title because I didn't know if it an experiment at the moment. Even now the correct title would be "Bun author says that he is entertaining the idea of porting it from Zig to Rust, creates an experimental branch".

Re: Zig → Rust porting guide

#460
post #450

Earlier quoted context omitted.

Why does the deterministic nature matter? The interesting part is having oracle tests, not determinism. If someone is deterministic and wrong you use oracle tests to catch that.

People keep saying "deterministic" when they mean "probabilistic". For illustration, a bloom filter is deterministic, but it's also probabilistic. LLMs are the same.

I assume he means deterministic here, meaning that the translation program always produces the same output for a given input.

But none of these properties are what let you perform a successful port. The port is going to rely entirely on oracle testing.

Post reply on HN