Live data from Hacker News

Zig → Rust porting guide

github.com

181–190 of 592 posts

Re: Zig → Rust porting guide

#182

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

I like your username.

Re: Zig → Rust porting guide

#184
post #156

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.

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

This should be the top comment in the whole thread. AI is not the point, the PR is just not of a good quality.

Re: Zig → Rust porting guide

#186
post #168

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

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

Re: Zig → Rust porting guide

#187

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…

The industry does not shape bases on HN top posts, nor media buzz. Remember youtube birth. Necessity, available tech, fresh talent.

I believe now we have all but we fail at choosing.

Re: Zig → Rust porting guide

#188

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

> I expect OSS to go the opposite direction: no human contribution allowed.

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

#189
post #168

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

The thing is that this argument doesn't work with Go because its type system (and the whole language, really) is much less expressive and compiler gives a lot less feedback to the LLM. So it tends to have to write more unit tests and do more cycles of testing (and spend more tokens) to get it right.

Re: Zig → Rust porting guide

#190
post #135
post #114

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

In this case I think the current zeitgeist (at least among zoomers and younger millennials) really loves the word "vibe". Once they hear of the term "vibe coding", they just want to be able to say it, even if what they're doing isn't really vibe coding.

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.

Post reply on HN