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

521–530 of 592 posts

Re: Zig → Rust porting guide

#521

Post by Chris2048 »

uncircle wrote: post #303
DeathArrow wrote: post #269

Earlier quoted context omitted.

>The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code. That is if you use something like C, C+=, Java, .NET, Go. With Javascript and Python I don't think knowing assembly would make any difference because it's hard to optimize the code in these languages for how the CPU and memory works.

Knowing assembly in this day and age is the result of being curious and wanting to understand how computers work, which means knowledge of algorithms, data structures, etc. The same applies to vibe coding: the best "vibe coder" will paradoxically be the person with enough knowledge and curiosity to understand programming, how computer works and the subject at hand; one that could write the whole thing from scratch so…

> wanting to understand how computers work, which means knowledge of algorithms, data structures, etc.

It's possible to know in general terms, how computers work, and what assembly is without "knowing assembly" in the sense of being familiar with using/debugging it as a programming language.

Re: Zig → Rust porting guide

#522

Post by Chris2048 »

skydhash wrote: post #402
DeathArrow wrote: post #269

Earlier quoted context omitted.

>The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code. That is if you use something like C, C+=, Java, .NET, Go. With Javascript and Python I don't think knowing assembly would make any difference because it's hard to optimize the code in these languages for how the CPU and memory works.

Knowing assembly doesn’t mean you would spend your time writing assembly (aka being familiar with opcodes and architecture optimizations). But in the process, you get familiar with the working of the computer hardware and the OS that sits on top of it. That is always useful knowledge especially when needing to deal with binary format and protocols or FFI.

> But in the process..

Then it's sufficient to know assembly, but not necessary.

This is compatible with "[developers] that still understand assembly to this day tend to be better developers", but not with "[on developers who] don’t know assembly, which speaks to [their] quality".

Re: Zig → Rust porting guide

#523

Post by ktm5j »

weli wrote: post #504
ktm5j wrote: post #502

Earlier quoted context omitted.

Okay, let's be honest. That's a feature request, not a bug report.

I'd agree but bun is supposed to be a "drop-in replacement" and is marketed as such. This breaks several packages and projects.

Ohh thanks, did not realize. That I can understand.

Re: Zig → Rust porting guide

#524

Post by tracker1 »

novok wrote: post #348
mb2100 wrote: post #330

Earlier quoted context omitted.

What's the main motivation for considering Rust? For what it's worth, in my last experience with Bun[0] I ran into a couple of bugs where it seemed Rust could have helped, e.g. using Bun.write [0]: https://mastrojs.github.io/blog/2025-10-29-what-struggled-wi... )

With AI agents and how good they are in doing "language translation" tasks against an identical target with a comprehensive test suite, you end up doing these things out of curiosity. The AI agent has the originals to test it's assumptions with too. I've had surprisingly good results from getting AI agents to take a script in shell, python or typescript and have it translate it into those other programming languages,…

Totally agreed... It enables you to try swapping out dependencies you might not otherwise even consider because of the cognitive load in trying to do so as an individual, and get it done/working in a few hours and a few days to follow in order to review.

Or take on an additional/related feature (like Redis grepping over the new array data types). Because you can be relatively sure the borders are stable and you can limit the surface/scope.

Re: Zig → Rust porting guide

#526

Post by jazzypants »

Klonoar wrote: post #494
MisterTea wrote: post #483

Earlier quoted context omitted.

Advice for the future: experiments should be explicitly tagged as such. The commit message "docs: add Phase-A porting guide" says nothing about the experimental and looks like a planned move to rust. That message certainly looks very official to me. > 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 throw…

Or the community at large could stop acting deranged over language wars like it’s 2001. It’s their repo, let them do what they want lol

I didn't get the impression that anyone cares about the source or destination language. I think the concern is centered around the long history of failure with large scale rewrites like this-- See Netscape 5, Perl 5, etc. Joel Spolsky wrote a legendary article about this [0]. I think the NextJS app router might be slowly joining this conversation as well.

It could get even worse if they get Second System Syndrome[1] and try to add features as they rewrite it. Considering Bun's rapid development cycle, this seems likely.

[0] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[1] https://en.wikipedia.org/wiki/Second-system_effect

Re: Zig → Rust porting guide

#527

Post by tracker1 »

kennykartman wrote: post #371
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…

Thank you, Jarred, for your work. It’s unfortunate to see so much backlash toward legitimate research. Bun is often seen by some as “the flagship project for zig” - especially among those frustrated with rust who want zig to "win over rust" for whatever reasons. At the end of the day, you should do what makes the most sense for your project and your circumstances, regardless of the language or tools involved. Persona…

I can only speak for myself... but I've found at least Claude Opus to handle Rust very well, and in my own use cases WebAssembly (wasm) and FFI for interoperation with TS/JS has been pretty smooth.

Re: Zig → Rust porting guide

#528

Post by fithisux »

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…

A research prototype. This is normal.

Re: Zig → Rust porting guide

#529

Post by tracker1 »

psychoslave wrote: post #472
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…

Will you have a way to measure the ecological impact it has to make such a throw away attempt? Not actually pointing on you or anyone in particular here to be clear. And if the answer would be "not much more than forgetting the light when leaving the toilets", certainly that would be a "go have fun" cheerleading on my part. But otherwise we collectively have to keep in mind that the prompt that we can throw mindlessl…

Less than the impact of people who can't be bothered to remember basic historical facts or directions in terms of hitting Google services dozens of times a day across the population.

Probably less than the impact of having dozens/hundreds of actual developers, each with a dedicated computer running for months/years in what it would take for a similar effort.

If you want to go live in the woods and farm/hunt for yourself, feel free. I'd suggest you stay away from the museums with paint and not glue yourself to a car mfg.

Post reply on HN