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

401–410 of 592 posts

Re: Zig → Rust porting guide

#401

Post by sureglymop »

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…

To be fair, this seems to be Buns original creator themselves experimenting. Unclear if there's any relation to the Anthropic acquisition. But I think it's best we refrain from prematurely speculating if we just don't know.

Re: Zig → Rust porting guide

#402

Post by skydhash »

DeathArrow wrote: post #269
uncircle wrote: post #237

Earlier quoted context omitted.

To add to the other commenters, loads of people don’t know assembly, which speaks to the quality of the average developer. The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code.

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

Re: Zig → Rust porting guide

#403

Post by a96 »

wiseowise wrote: post #341
ai_critic wrote: post #150

Earlier quoted context omitted.

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?

Against blankets would be even more like that argument.

Re: Zig → Rust porting guide

#405

Post by skydhash »

brabel wrote: post #374
xigoi wrote: post #277

Earlier quoted context omitted.

The main difference is that the input to an LLM is in an ambiguous language.

A programming language is allowed to be ambiguous, I don’t know of a definition that excludes that!

The language specs may be, but an implementation is never ambiguous. When you encounter and undefined behavior in the specs, that’s when you look at your compiler/interpreter docs.

Re: Zig → Rust porting guide

#406

Post by a96 »

wg0 wrote: post #145
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.

So if tomorrow Rust denied the "improvement" to upstream Rust then what's the next language they plan to vibe code it in?

Javascript

Re: Zig → Rust porting guide

#407

Post by jaapz »

latexr wrote: post #385
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?

This is getting stupid. Now one can’t even make a reasonable polite question with praise without being asked if they pay. Bun raised millions of dollars and was acquired by a commercial entity which bragged in the same blog post of reaching $1B. They’re not a guy with an eyepatch and a tin can out on the street. Open-source developers should be compensated, but they don’t have to be. You can’t reasonably offer your w…

Come on, whenever a project is discussed on hackernews, there is always one comment of "why are you working on X, when you should be fixing bug Y?!".

We are all software engineers on here (or at least many of us are), we all know how project management and prioritisation works right? We can't work on everything all at once.

Re: Zig → Rust porting guide

#408

Post by gozzoo »

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…

[dead]

Re: Zig → Rust porting guide

#409

Post by jadbox »

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'm very curious what Zig vs Rust code looks like for the same project! What are your thoughts so far?

Re: Zig → Rust porting guide

#410

Post by raincole »

lionkor wrote: post #299
selectnull wrote: post #289

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.

Presumably they aren't falling for their (extremely obvious) "grassroots" marketing, and know, like any good engineer, that LLMs are not the right tool for this. It's easy to just see Bun as a marketing stunt, as well.

> that LLMs are not the right tool for this.

Claude Code itself is already heavily written by LLMs[0], so I'm not sure what's "this" here. You mean LLMs are okay for writing code but not porting?

[0]: No, it's not just marketing. The codebase was leaked and anyone who glanced at it would realize the claim is likely true.

Post reply on HN