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

341–350 of 592 posts

Re: Zig → Rust porting guide

#341

Post by wiseowise »

ai_critic wrote: post #150
endospore wrote: post #137

Earlier quoted context omitted.

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)

It's a combination of pragmatism (not wanting to wade through slop, not wanting to shove out newbie developers) and politics (usual contemporary techie progressive stuff that's now oddly anti-technology).

> usual contemporary techie progressive stuff that's now oddly anti-technology

Just because a thing exists doesn’t mean you have to use it for everything. You don’t use asbestos blanket? Why are you so against asbestos?

Re: Zig → Rust porting guide

#342

Post by Jtarii »

nailer wrote: post #101
malisper wrote: post #94

Earlier quoted context omitted.

> what looks like a massive undertaking for vibe coding fwiw, I suspect it's less of an undertaking than you may think. I've been playing with AI to rewrite Postgres in Rust[0] over the past couple of weeks and I found the AI to be exceptional at doing rewrites. Having an existing codebase you can reference prevents a lot of the problems you have with vibecoding. You have an existing architecture that works well and…

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

Re: Zig → Rust porting guide

#343

Post by wiseowise »

psychoslave wrote: post #309
petre wrote: post #163

Earlier quoted context omitted.

C obviously.

You missed the part were everyone is going to run its own vibe coded assembly tools[1]. So the next step will be that bun will be directly re-written from scratch at every iteration, the repository will only contains the specs for the LLMs. Caching locally the generated code will be authorized for some transition period, but as it’s obviously very dangerous to let people tweak what exactly computers are doing, forbid…

Democratizing knowledge btw

Re: Zig → Rust porting guide

#344

Post by lukaslalinsky »

brabel wrote: post #275
DeathArrow wrote: post #249

Earlier quoted context omitted.

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

> move fast and break things and move at a pace that guarantees everything is rock solid. Zig is famous for taking the former path! Anyone using Zig for a few years knows every release breaks things, and they are still making huge changes which I would classify as “moving fast”, like the recent IO changes!

Exactly, and Zig 0.16 is explicitly a release with known issues, just count the number of TODOs in the std.Io namespace.

Re: Zig → Rust porting guide

#345

Post by andkenneth »

debarshri wrote: post #228
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…

I think itnis ok to use or build vibe coded tools if it is built by experts in the domain and they take the ownership.

I think if it's well built by experts it doesn't deserve the "vibe coded" label even if it was built with agentic tools.

Re: Zig → Rust porting guide

#346

Post by brailsafe »

kelnos wrote: post #231
brailsafe wrote: post #116

Earlier quoted context omitted.

This is just a coined term; definitions evolve over time based on usage

Then "vibe coding" is a useless term, if it just means "LLM-assisted coding". We might as well just say "LLM-assisted coding" or "AI coding" or whatever. As much as I find the word "vibe" generally annoying (in all contexts), I actually really like "vibe coding" as "LLM did everything and I didn't even look at it". It's a succinct, useful way to describe that mode of doing things. Diluting it down to "LLM-assisted co…

Nah, I'm not big on these "it either matches the way ___ used it or it's useless" binaries. The term is the term, it's recent, and people are using various forms of the others you mentioned. People use it loosely, people use it specifically, this is the way for many colloquial terms, and definitions form around them and expand over time or change.

It sort of surprises me how uptight people are getting about a term that was mentioned on X last year and has since been tossed around to loosely imply that a machine did between zero and all of the work. Just because it doesn't match exactly does not mean it's useless, it maps to a concept, if the details are important and ambiguous, then elaborate.

Re: Zig → Rust porting guide

#347

Post by merlindru »

wiseowise wrote: post #305
jeltz wrote: post #293

Earlier quoted context omitted.

I don't see why they think it would work when the reason their patch set was rejected was because it was not correct, did not go in a direction the Zig authors were interested in and is also in an area where they are already working hard on improvements. It would have been much better if the bun team joined forces and helped out instead of vibe coding a broken PoC patch that never can get merged. Compilation speed is…

> It would have been much better if the bun team joined forces and helped out instead of vibe coding a broken PoC patch that never can get merged Bold of you to assume they have the expertise.

Bun folks routinely contribute to WebKit, and bun itself is an incredibly impressive project, so I don't think they're lacking expertise

Re: Zig → Rust porting guide

#348

Post by novok »

mb2100 wrote: post #330
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…

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, including rust versions. Or swapping from one build system to another.

Re: Zig → Rust porting guide

#349

Post by sarreph »

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…

It is a pity that you can't make an experimental commit on an experimental branch without igniting a fire of delirium through some people who -- if they were able to put their emotional response aside for a minute and could weigh this up on the basis of merit -- would probably agree with the motivations for researching this approach.

> if/how hard it’d be to get it to pass Bun’s test suite and be maintainable

Every month brings new opportunities to completely abstract the process of porting code with agents, all using linguistics. What an exciting time.

For those looking for a similarly interesting (and interestingly similar) example, see Cloudflare's port of Next.js[0], "vinext", from a couple of months ago. It had some teething problems at the start but I'm using it in a few production projects now with minimal issues.

[0] - https://github.com/cloudflare/vinext

Re: Zig → Rust porting guide

#350

Post by solumunus »

wg0 wrote: post #168
echelon wrote: post #155

Earlier quoted context omitted.

Rust is legit one of the best languages to "vibe code" in. The emitted AST has a lower defect rate since it incorporates strong types and in-built error handling. Other pros include native code and portability, but downside is the compile time.

This could be a subjective feeling with no real data to back it up. People say same about Go as well that it's type system and limited feature set makes it the best AI friendly language but there too, it just seems like a hunch rather than a proven fact.

Well those people are simply wrong. Go and Rust type systems don't even remotely compare. Go types suck.
Post reply on HN