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

441–450 of 592 posts

Re: Zig → Rust porting guide

#441

Post by staticassertion »

kelnos wrote: post #236
kgeist wrote: post #71

Interesting how times have changed. Back in 2015, the entire Go runtime (already a mature codebase) was rewritten from C to Go semi-automatically: one of the maintainers wrote a C-to-Go conversion tool (for a subset of C they used) so that it compiled and produced identical output, and then the resulting code was manually refactored to make the Go code more idiomatic and optimized. And now you can just ask a language…

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…

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.

Re: Zig → Rust porting guide

#442

Post by gobdovan »

pie_flavor wrote: post #379
2colours wrote: post #363

Earlier quoted context omitted.

I think the question still deserves a proper answer.

Please observe a policy of extreme wisdom: https://github.com/Fody/Home/blob/master/pages/licensing-pat...

Are you being ironic or serious? I can see both pros (encourage people to see themselves as customers) and cons (less initial adoption) to the licensing, although I'd maybe leave bug issues open for everybody.

What aspect do you think dominates?

Re: Zig → Rust porting guide

#443

Post by dcre »

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.

Most of Bun’s code is already written by LLMs. If you feel that way, it’s already been too late for a while. Furthermore, we’re talking about a million line port done in a couple of days. The question of whether it’s worth the time looks extremely different if done by hand. It would take a year.

Re: Zig → Rust porting guide

#444

Post by conartist6 »

dcre wrote: post #443
conartist6 wrote: post #426

Earlier quoted context omitted.

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.

Most of Bun’s code is already written by LLMs. If you feel that way, it’s already been too late for a while. Furthermore, we’re talking about a million line port done in a couple of days. The question of whether it’s worth the time looks extremely different if done by hand. It would take a year.

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.

Re: Zig → Rust porting guide

#445

Post by magicmicah85 »

Hikikomori wrote: post #414
SergeAx wrote: post #354

Earlier quoted context omitted.

I am a topic starter, and I had no emotional response, was just being curious. Never expected it will land at HN #1. I specifically posted the link to the first commit and not to the whole branch, because currently the prompt is the most interesting part.

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.

Re: Zig → Rust porting guide

#446

Post by ForHackernews »

conartist6 wrote: post #444
dcre wrote: post #443

Earlier quoted context omitted.

Most of Bun’s code is already written by LLMs. If you feel that way, it’s already been too late for a while. Furthermore, we’re talking about a million line port done in a couple of days. The question of whether it’s worth the time looks extremely different if done by hand. It would take a year.

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?

Re: Zig → Rust porting guide

#447

Post by nailer »

Jtarii wrote: post #342
nailer wrote: post #101

Earlier quoted context omitted.

> I suspect it's less of an undertaking than you may think... having an existing codebase you can reference prevents a lot of the problems you have with vibecoding. That's because it's not vibe coding - stingraycharles doesn't seem to understand what vibe coding is. Vibe coding was defined here https://x.com/karpathy/status/1886192184808149383 > There's a new kind of coding I call “vibe coding”, where you fully give…

That is one person's definition of vibe coding, not "the definition" of vibe coding. Words have multiple meanings.

It’s the person that created the term’s definition.

Re: Zig → Rust porting guide

#448

Post by kibwen »

DeathArrow wrote: post #246
andkenneth wrote: post #100

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

>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?

No. The Rust project developers are more lenient when it comes to developing patches with AI assistance, but the amount of leniency one receives is proportional to the amount of pre-existing trust a contributor has with the project, and every PR still has to be reviewed by an independent human. A stranger dumping a zillion lines of slop in a PR is a one-way ticket to having your PR politely closed.

Re: Zig → Rust porting guide

#449

Post by nailer »

kelnos wrote: post #235
LamaOfRuin wrote: post #131

Earlier quoted context omitted.

The commit would look exactly like that if it was a 100% deterministic transpilation (like Golang did with their original C implementation?). This is obviously very different from that, but the way the commit looks doesn't make it so.

The question isn't whether or not you'd get the same line count with a non-LLM tool. The question of whether or not it's vibe-coded depends on whether or not the committer actually reviewed and understood the new code. And with a 75k line difference, that seems unlikely.

> The question of whether or not it's vibe-coded depends on whether or not the committer actually reviewed and understood the new code

Why? Do you think large changes not made by LLMs are also reviewed line by line?

Re: Zig → Rust porting guide

#450

Post by kibwen »

staticassertion wrote: post #441
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…

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.
Post reply on HN