Interesting. What are the main trade-offs they expect from the switch?
Zig → Rust porting guide
241–250 of 592 posts
Re: Zig → Rust porting guide
#242Interesting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”. Yet here we are, what looks like a massive undertaking for vibe coding. Time will tell how this will turn out. Would be nice if the Bun maintainers could…
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.
[deleted]
Re: Zig → Rust porting guide
#243I wonder if a successful, albeit slower, approach would be to walk the git commit history in lockstep, applying the behavioral intent behind each commit. If they did this, I would be interested in knowing if they were able to skip certain bug fix commits because the Rust implementation sidestepped the problem.
Many segfaults in Bun issue tracker. I bet it would sidestep many.
Well…there would still be panics.
Re: Zig → Rust porting guide
#244what a win
Re: Zig → Rust porting guide
#245Earlier quoted context omitted.
It was and is a perfectly good term, but people started using it without regard for its definition. I don't know why people wouldn't misuse a "better" term the same way.
In this case I think the current zeitgeist (at least among zoomers and younger millennials) really loves the word "vibe". Once they hear of the term "vibe coding", they just want to be able to say it, even if what they're doing isn't really vibe coding. And then that leaks outside their social and age groups, because other people hear the incorrect usage, get confused, and incorporate that confusion into their own us…
Waiting until they decide to call non-assisted programming ‘unc coding’
Re: Zig → Rust porting guide
#246Interesting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”. Yet here we are, what looks like a massive undertaking for vibe coding. Time will tell how this will turn out. Would be nice if the Bun maintainers could…
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.
>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.
And will Rust team accept their vibe coded patches?
Re: Zig → Rust porting guide
#247Earlier quoted context omitted.
[flagged]
Normal, emotionally stable people don’t care if the creators of a programming language disagree with them about tariffs.
I can't find any evidence that the creators of Zig hold the views GP seems to suggest, but I think your assertion is wrong.
Normal, emotionally stable people do sometimes make decisions about what businesses to patronize based on the political leanings of the business owners. Same thing happens with art appreciation, movie/TV watching, and plenty of other things. Zig might not be a business, but the same rules apply.
You may think that's foolish, and not make your decisions that way, but it's a perfectly valid way to make decisions.
Re: Zig → Rust porting guide
#248Earlier quoted context omitted.
In this case I think the current zeitgeist (at least among zoomers and younger millennials) really loves the word "vibe". Once they hear of the term "vibe coding", they just want to be able to say it, even if what they're doing isn't really vibe coding. And then that leaks outside their social and age groups, because other people hear the incorrect usage, get confused, and incorporate that confusion into their own us…
Waiting until they decide to call non-assisted programming ‘unc coding’
As someone who might be described as an "unc", I had to look up what "unc" meant.
Re: Zig → Rust porting guide
#249Earlier 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.
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 yet.
Re: Zig → Rust porting guide
#250Earlier quoted context omitted.
One non-obvious reason is that an important aspect of their community is to shepherd new contributors [1]. LLMs crushing everything would reduce that. More obvious is all the toil for maintainers dealing with LLM PRs (broadly it’s an issue). The Zig maintainers prefer to put their energy into improving people and fostering those relationship. [1] https://kristoff.it/blog/contributor-poker-and-ai/
That's a solid reason to keep LLMs away from the kind of tasks that help with onboarding. But a patch series from a competent team that changes 3000 lines should probably be evaluated on its own merits. Or at least, the collaboration-based reasons to reject AI don't apply and the real reason would be something else. (Though I don't know if this particular patch series would get accepted on its own merits.)
> patch series from a competent team that changes 3000 lines should probably be
split into a bunch of much smaller changes?