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

411–420 of 592 posts

Re: Zig → Rust porting guide

#411

Post by saagarjha »

sarreph wrote: post #349
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…

It is a pity that you can't make an experimental commit on an experimental branch without igniting a fire of delirium through some people who -- if they were able to put their emotional response aside for a minute and could weigh this up on the basis of merit -- would probably agree with the motivations for researching this approach. > if/how hard it’d be to get it to pass Bun’s test suite and be maintainable Every m…

This is what it means to work on a popular project, unfortunately.

Re: Zig → Rust porting guide

#412

Post by rdmsr0 »

jeltz wrote: post #293
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.

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…

Side note, but I think using LLMs like this to write PoCs in existing projects is actually a good idea to prove whatever you had in mind is feasible and worth it to pour time into. Obviously you need to not vibecode the entire thing once you're past that point though...

Re: Zig → Rust porting guide

#413

Post by matt_kantor »

MarsIronPI wrote: post #24
nailer wrote: post #13

Earlier quoted context omitted.

> what looks like a massive undertaking for vibe coding It doesn’t look like that at all. Do you think that all use of AI is vibe coding?

It depends on what you mean by "vibe coding". Is AI coding based on an existing implementation vibe coding? What about only from a natural-language spec? How does manual reviewing affect whether or not it's vibe coding?

> How does manual reviewing affect whether or not it's vibe coding?

I think the most commonly-accepted definition of "vibe coding" is when you "forget that the (generated) code even exists"[0]. So vibe-ness entirely hinges upon whether you're manually reviewing. If you make/prompt changes based on what you observe in the generated code (rather than only based on runtime behavior), then you're not "vibe coding".

I think the other things you mentioned are orthogonal to vibe-ness.

[0]: https://en.wikipedia.org/wiki/Vibe_coding#Definition

Re: Zig → Rust porting guide

#414

Post by Hikikomori »

SergeAx wrote: post #354
sarreph wrote: post #349

Earlier quoted context omitted.

It is a pity that you can't make an experimental commit on an experimental branch without igniting a fire of delirium through some people who -- if they were able to put their emotional response aside for a minute and could weigh this up on the basis of merit -- would probably agree with the motivations for researching this approach. > if/how hard it’d be to get it to pass Bun’s test suite and be maintainable Every m…

I am a topic starter, and I had no emotional response, was just being curious. Never expected it will land at HN #1. I specifically posted the link to the first commit and not to the whole branch, because currently the prompt is the most interesting part.

The title kinda set the tone for this post.

Re: Zig → Rust porting guide

#415

Post by dspillett »

matsemann wrote: post #390
sarreph wrote: post #349

Earlier quoted context omitted.

It is a pity that you can't make an experimental commit on an experimental branch without igniting a fire of delirium through some people who -- if they were able to put their emotional response aside for a minute and could weigh this up on the basis of merit -- would probably agree with the motivations for researching this approach. > if/how hard it’d be to get it to pass Bun’s test suite and be maintainable Every m…

That's not a very constructive, nor accurate, way of trying to dismiss all concerns around bun that has been raised.

I think that was a very constructive comment about the unconstructive way people are shoe-horning other concerns about bun into this thread abut a specific aspect which itself turns out to be just an experiment that someone knee-jerk reacted to, despite several active threads already discussing those matters one of which only just fell off the front page.

While the concerns many have about Bun's potential future direction are valid IMO, of the posts on this thread the one you are criticising is one of the more constructive.

Re: Zig → Rust porting guide

#416

Post by techsystems »

dannersy wrote: post #388
_kblcuk_ wrote: post #359

Earlier quoted context omitted.

It's not like OP asked for any criticism to start with, right? This whole thread is pretty good example of why saying "Fools and children should never see half-finished work" exists. ¯\_(ツ)_/¯

Since when was HN ever about asked for criticism?

Not HN, but from my experience of over a decade, it's certainly US culture to criticise without expertise.

Re: Zig → Rust porting guide

#417

Post by luma »

kelnos wrote: post #240
_--__--__ wrote: post #60

Earlier quoted context omitted.

That seems totally reasonable but I wonder if there was some head butting in non-public channels given Bun is one of the biggest players in Zig and planned to push through a change like that on their own.

Even if there was anything in private channels, the reasons stated in that forum post are alone more than enough to reject Bun's Zig changes.

And also great reasons for Bun to port themselves elsewhere. If they aren’t allowed to contribute to Zig, there’s very little reason to select Zig moving forward.

Re: Zig → Rust porting guide

#418

Post by Chris2048 »

jaapz wrote: post #407
latexr wrote: post #385

Earlier quoted context omitted.

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.

given the alleged context, X being something "reported in 2023, still affecting us 3 years later", is this not a reasonable PM / priority decision to question?

Re: Zig → Rust porting guide

#419

Post by Chris2048 »

bouk wrote: post #367
2colours wrote: post #363

Earlier quoted context omitted.

I think the question still deserves a proper answer.

No, open-source maintainers don't owe you anything if you don't pay for it

I have similar problems with product I do pay for, and I still get told I have no say. FO/OSS distinction is a red herring.

At some point it need to be made clear; it's not a legal obligation, but a reputational challenge.

Re: Zig → Rust porting guide

#420

Post by dannersy »

techsystems wrote: post #416
dannersy wrote: post #388

Earlier quoted context omitted.

Since when was HN ever about asked for criticism?

Not HN, but from my experience of over a decade, it's certainly US culture to criticise without expertise.

I can say from expertise that vibing a full move of any project from one language to another is probably not a great way to evaluate if the decision is a good one. I got downvoted, maybe I said it too authoritatively. But hey, that is just like, my experienced opinion, man.
Post reply on HN