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

361–370 of 592 posts

Re: Zig → Rust porting guide

#361

Post by jeroenhd »

alethic wrote: post #320
norman784 wrote: post #272

Earlier quoted context omitted.

Not only because the AI part, here's a discussion [0] about it [0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

In the context of this post, that's absolutely hilarious they're vibe-porting their Zig codebase to Rust . I love Rust, but you couldn't pick a language with slower compile times... XD

Compiling Rust is actually quite fast in my experience. The problem with many Rust projects is that they pull in dependencies left, right, and center. Pulling in Tokio makes your project compile an entire thread management system even if you're just compiling Hello World, and simple oneliners containing macros can easily spread out into dozens of lines of code each.

Linking is also slow, and the extreme amounts of metadata produced for LLVM almost serves as a benchmark for LLVM's throughput, but that's all in an effort to produce faster, better binaries in the end.

On godbolt.org, Hello World compiles and runs in about 250ms. Zig's Hello World compiles and runs in 600ms. Of course Zig is still an unfinished language so optimisations like these are probably hardly a priority, but when it comes to lines of code per second, the difference isn't as big as people make it out to be.

What will make the most difference is how many crates the rewrite will pull in. The PORTING.md file specifies "No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`" for the second phase, which should definitely get rid of the excessive compile time many people associate with Rust projects.

Re: Zig → Rust porting guide

#362

Post by throwaway2037 »

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…

Why not offer a bounty to get this issue fixed? Are you otherwise paying any money to the bun team?

Re: Zig → Rust porting guide

#363

Post by 2colours »

throwaway2037 wrote: post #362
weli wrote: 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…

Why not offer a bounty to get this issue fixed? Are you otherwise paying any money to the bun team?

I think the question still deserves a proper answer.

Re: Zig → Rust porting guide

#364

Post by ozgrakkurt »

Just checking some loc numbers from nodejs, bun and deno:

On nodejs: `tokei src`: 98333 LOC C++ Code

On bun: `tokei src` 573572 LOC Zig Code

On deno: `tokei libs cli runtime` 289573 LOC Rust Code

This seems wrong though so would be appreciated if someone who knows the structure of these projects can correct me on the folder names.

Doing `tokei lib src test deps` gives more than 5M loc. but not sure if that is fair

Re: Zig → Rust porting guide

#366

Post by zamalek »

minimaltom wrote: post #153
zamalek wrote: post #130

Earlier quoted context omitted.

Tokio is a general purpose async runtime. Much the same could probably be said for async-std (except IIRC they do have a barebones reactor for you to build your own on). In general, a general-purpose async runtime will do worse for highly specific tasks than a purpose-built one (especially e.g. NUMA). I think avoiding async entirely might be a mistake, and I'm not entirely convinced anything better than a general-pur…

my guess is they want to do AI/O as part of their event loop explicitly, and blocking a thread in a syscall waiting for an IOP (ala std::fs) isn't the vibe.

Ah good point, complete brain fart on my part.

Re: Zig → Rust porting guide

#367

Post by bouk »

2colours wrote: post #363
throwaway2037 wrote: post #362

Earlier quoted context omitted.

Why not offer a bounty to get this issue fixed? Are you otherwise paying any money to the bun team?

I think the question still deserves a proper answer.

No, open-source maintainers don't owe you anything if you don't pay for it

Re: Zig → Rust porting guide

#368

Post by andai »

c0rruptbytes wrote: post #138
andai wrote: post #114

Earlier quoted context omitted.

Yeah, it's a distinction worth making, and the language for making it kind of sucks. Vibe coding means "AI does the whole thing", or "I use tab autocomplete" depending on who you ask. It's not a very useful term anymore, we need better ones. My benchmark is basically, "are you letting the AI drive." In this case, an AI appears to have written the migration guide...

i mean AI docs are usually the result of collabs between users and AI using /plan with superpowers, i see a lot of specs -> impl plan -> execute plan

Yeah. It "might be" that a human actually looked at it. There's just no way to know anymore. So it rightly doesn't inspire confidence.

Re: Zig → Rust porting guide

#369

Post by andai »

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.

Just going off vibes and not even looking at the code was the original definition. But "different people say the same thing but mean different things" is kind of the problem I was getting at.

Re: Zig → Rust porting guide

#370

Post by elktown »

stingraycharles wrote: post #5

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

"Show me the incentive and I'll show you the outcome" is usually the overarching law of software dev/design/arch.
Post reply on HN