Let the guy cook, would be nice benchmark of llm nothing else. Damn I wish I had access to infinite tokens for crazy experiments like this.
Zig → Rust porting guide
331–340 of 592 posts
Re: Zig → Rust porting guide
#332I 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 love your work on bun. How do you feel about all the constant concerns being raised about the quality of the project lately? I understand some of them might just be typical twitter hate but some of them are real. And I think people are right to question why you are adding image processing or web views inside a javascript runtime when there are bugs affecting production that sit unaddressed. For example on of our biggest blockers right now is https://github.com/oven-sh/bun/issues/6608 which was reported in 2023, still affecting us 3 years later.
Re: Zig → Rust porting guide
#333Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Purely on that basis and ignoring the recent drama this seems like a reasonable idea for tech debt pay down to me. Assuming automated conversion can work without making things worse, which is not exactly a given.
> Picking a pre 1.0 language to build your product always seemed like a bad choice to me.
Such as React Native? :D
Re: Zig → Rust porting guide
#334Earlier 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.
I think they do. Building bun is a complex task and engineers who can do that should also be able to figure out how to help out with a compiler. It is just a matter of immersing yourself in the code and be willing to put in the hours and hard work. Sure, they may not be able to help out with designing the type resolution but there is other work which needs to be done that any skilled engineer can do.
Re: Zig → Rust porting guide
#335Re: Zig → Rust porting guide
#336The only Bun shipped product I've used in anger is OpenCode and I regularly run into segfaults on it. I doubt this is the reason for migration but every time it happens, it reminds me the real cost of unsafe code. That being said, Zig is an absolute pleasure to write and I can't wait until it has a real library ecosystem, Rust's greatest boon.
the rust port (at least currently) heavily uses unsafe as well https://github.com/oven-sh/bun/compare/claude/phase-a-port#d... that isn't particularly surprising, but the point is I would expect getting things more stable than the zig version would take a bit.
That's completely normal at the first step of the language transformation. Actually it's required if you do a file by file transformation first while wanting to maintain interface compatibility.
I'm not sure I would take this kind of path, I would much more focus on refactoring the project to small and easily translatable components with small boundaries, but it's cheap to try things.
Re: Zig → Rust porting guide
#337Earlier 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.
> 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".
Take it gently, the poor thing doesn't understand the difference between code and talking about code.
Re: Zig → Rust porting guide
#338Earlier quoted context omitted.
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/
Yeah, I remember when the lazy bastards started writing programs using compilers instead of learning assembly language. Now I don’t have a single colleague who can write assembly. There’s whole generations now who can’t code assembly. Most don’t even know what a register is. Hope Zig holds against this latest attempt to make everyone stupid.
There’s a big difference between (mostly) deterministic compiler and non-deterministic LLMs.
Re: Zig → Rust porting guide
#339Earlier 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.
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)
The LLM rule has been a thing for a very long time at this point.
Re: Zig → Rust porting guide
#340Earlier 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.
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?