Zig → Rust porting guide
181–190 of 592 posts
Re: Zig → Rust porting guide
#182Earlier 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).
Re: Zig → Rust porting guide
#183If they did, I guess they would rewrite deno in C++
Re: Zig → Rust porting guide
#184Earlier 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.
Even if AI had not been used, the changes would not have been upstreamed, see https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... tl;dr the supposed improvements are not sound and the zig compiler has already gotten a whole lot faster
Re: Zig → Rust porting guide
#185Re: Zig → Rust porting guide
#186Earlier 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.
Re: Zig → Rust porting guide
#187Interesting 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 believe now we have all but we fail at choosing.
Re: Zig → Rust porting guide
#188Earlier quoted context omitted.
https://x.com/jarredsumner/status/2048434628248359284
The gp's interpretation of that tweet is such a completely incorrect reading as to make one think it's likely disingenuous.
How is it an incorrect interpretation? Jared is indeed pitching/suggesting/predicting that human contribution will not be allowed in the near future, i.e. banned.
Re: Zig → Rust porting guide
#189Earlier 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.
Re: Zig → Rust porting guide
#190Earlier quoted context omitted.
Yeah, it's a distinction worth making, and the language for making it kind of sucks. Vibe coding means "AI does the whole thing", or "I use tab autocomplete" depending on who you ask. It's not a very useful term anymore, we need better ones. My benchmark is basically, "are you letting the AI drive." In this case, an AI appears to have written the migration guide...
It was and is a perfectly good term, but people started using it without regard for its definition. I don't know why people wouldn't misuse a "better" term the same way.
And then that leaks outside their social and age groups, because other people hear the incorrect usage, get confused, and incorporate that confusion into their own use of the term.