Live data from Hacker News

Zig → Rust porting guide

github.com

371–380 of 592 posts

Re: Zig → Rust porting guide

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

Personally, I find this experiment interesting and I’m curious to see how it develops. Writing idiomatic rust requires a shift in mindset, so it’ll be worth watching how well LLMs adapt to that over time.

Re: Zig → Rust porting guide

#372

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)

One non-obvious reason is that an important aspect of their community is to shepherd new contributors [1]. LLMs crushing everything would reduce that. More obvious is all the toil for maintainers dealing with LLM PRs (broadly it’s an issue). The Zig maintainers prefer to put their energy into improving people and fostering those relationship. [1] https://kristoff.it/blog/contributor-poker-and-ai/

It's important that developers have an accurate mental model of how things work, are structured and why.

LLMs promote a decoupling of mental models and the actual codebase.

As much as some may want to believe, just reviewing what the LLM outputs is not equivalent to thinking about implementation details, motivations, exactly how and why things are, and how and why they work the way they do, and then writing it yourself. The process itself is what instills that knowledge in you.

Re: Zig → Rust porting guide

#373
post #273

Earlier quoted context omitted.

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.

So by your logic all the PMs, managers and customers are programmers, right? After all, there’s a human compiler that takes their input and produces a program?

They are programmers when they write a prompt and get runnable code as a result, yes… but no if asking a human to write the code because if you have an intermediate, manual step between the text and the running code, you don’t have an automated process and hence it’s no longer even an application, let alone a “compiler”.

Re: Zig → Rust porting guide

#374
post #277
post #273

Earlier quoted context omitted.

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.

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!

Re: Zig → Rust porting guide

#375

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 it doesn't. No opensource dev need to answer anything, if you dont like it, fork it and do the work yourself.

Re: Zig → Rust porting guide

#376

Earlier quoted context omitted.

> unless you feed it source Which isn't particularly difficult - the language docs and std source come with the installation, so all you need to do is tell Claude where those directories are in your skill/plugin/CLAUDE.md. > and guide it closely (in which case it's useful for focused work) It does struggle sometimes with writing code that compiles and uses the APIs correctly. My approach to that so far has been to wr…

You're already at a disadvantage having to stuff the context and spend extra tokens coercing the model in the correct direction compared to it already knowing what to do (rust, ts, go, etc.) Here, I just did a quick test with claude. 1. "make a simple tcp echo server that uses rust" compiles and runs - took a few seconds to generate. 2. "make a simple tcp echo server that uses zig" result: compile error, took literal…

I guess now we can't make new programming languages anymore.

Re: Zig → Rust porting guide

#377
post #375

Earlier quoted context omitted.

I think the question still deserves a proper answer.

No it doesn't. No opensource dev need to answer anything, if you dont like it, fork it and do the work yourself.

Maybe it can be better phrased as "I think this question doesn't deserve that answer"

Re: Zig → Rust porting guide

#378

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.

The answer is because YOU haven’t fixed it yet. Chop chop, we’re all waiting on you.

Re: Zig → Rust porting guide

#379

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.

Please observe a policy of extreme wisdom: https://github.com/Fody/Home/blob/master/pages/licensing-pat...
Post reply on HN