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

281–290 of 592 posts

Re: Zig → Rust porting guide

#281

Post by mert-kurttutan »

esperent wrote: post #227
foresterre wrote: post #214

Earlier quoted context omitted.

There are other reasons why a project like Zig might not want to accept LLM generated contributions. Zig, as programming language, has a multiplier codebase. A bug may affect a significant larger portion of users than most libraries or binaries will, as it's a fundamental building block of everything that uses Zig. Just that could be worth the extra scrutiny on every individual commit. There's also the usual argument…

> has a multiplier codebase. A bug may affect a significant larger portion of users than most libraries or binaries will Couldn't you say exactly the same about bun?

It might be one of the reasons they want to migrate to Rust, i.e. to handle many these memory related issues by the compiler. Personally I used bun on a very few personal instances. But if you check issue reports, you will see memory bugs being reported say more than deno.

Re: Zig → Rust porting guide

#282

Post by robocat »

Onavo wrote: post #186
wg0 wrote: post #168

Earlier quoted context omitted.

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.

If we are gonna go down that rabbit hole, then the natural conclusion is Haskell.

How good are LLMs at understanding Haskell errors and then dealing with them?

The last time I had a go with Haskell, the errors reminded me so much of hellish terminal compilers from the 80s and 90s that I quickly gave up. Been there, not doing that again.

Re: Zig → Rust porting guide

#283

Post by akie »

Capricorn2481 wrote: post #134

April 26th - Bun announces they used AI to fork Zig so they could make an optimization for a 4x improvement April 27th - Zig contributor mlugg clarifies why the specific optimizations Bun did were ill advised and wouldn't have been accepted in Zig, regardless of AI use [1] May 4 - Bun is looking into Rust as an alternative. This, to me, seems like total whiplash. Has anyone at Bun made a statement on why they're maki…

It's a "you can't tell me what to do" reaction, to be honest.

Re: Zig → Rust porting guide

#284

Post by bigstrat2003 »

brabel wrote: post #273
wtetzner wrote: post #200

Earlier quoted context omitted.

Using an LLM isn't analogous to using a higher level language.

That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic. That may be a problem but it’s still a higher level language, just a much higher level language than anything before.

> That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic.

So it is not, by your own admission, "exactly, literally the same".

Re: Zig → Rust porting guide

#285

Post by brabel »

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…

You are right but recently, vibe coding has become a demeaning term for AI assisted code by anti-AI people. It’s interesting seeing how words evolve very quickly on the internet as they spread to different demographics.

Re: Zig → Rust porting guide

#286

Post by hnlmorg »

speed_spread wrote: post #68
unclad5968 wrote: post #22

Earlier quoted context omitted.

I don't think Zig is different enough from rust or any other systems language for it to matter. If you can write rust you can write Zig.

I'm reminded of the old joke "how to shoot yourself in the foot in 25 different languages". The first one was "C - you shoot yourself in the foot." Zig remains very close to that philosophy. So the difference is not in writing new stuff but in maintaining the existing codebase. Rust's rigidity makes it potentially harder to break stuff compared to Zig's general flexibility. As a project grows and matures, different t…

Oh man. That joke takes me back.

Re: Zig → Rust porting guide

#287

Post by happymellon »

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

You can be against a particular technology without being "anti-technology".

See DRM/surveillance/bad self driving implementations.

Re: Zig → Rust porting guide

#288

Post by nananana9 »

Alright, back to node.

I was hopeful for this project, and I've reported crashes & bugs in the bundler with the hope that it will stabilize over time, but this is just silly - I'm not going to risk them pulling the rug under me and replacing the runtime with 1 million lines of vibecoded rust.

Re: Zig → Rust porting guide

#289

Post by selectnull »

Why not rewrite claude-code in Rust?

So, Anthropic acquires Bun team because claude-code uses Bun. They port Bun from Zig to Rust presumably because Rust "is better" (imagine big air quotes here). Again presumably, they want to make claude-code "better". Why make it so complicated? With all the power of LLMs they have, surely they can make claude-code the best possible by writting it in Rust directly.

Post reply on HN