Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting Bun in Rust

bun.com

Post reply on HN
Print view View original

411–420 of 560 posts

Re: Rewriting Bun in Rust

#411

Post by woodruffw »

pier25 wrote: post #190
alexjurkiewicz wrote: post #166

Earlier quoted context omitted.

Paying customers get LTS. Are any paying customers asking for a Zig branch LTS? Or are you expecting open source maintainers to do free work for no particular reason?

Java, Node, and .NET have LTS versions all of which are free to use. > Or are you expecting open source maintainers to do free work for no particular reason? Free work? Last I heard Anthropic had acquired Bun.

I don’t follow how it would be in Anthropic’s interests to maintain an LTS version of Bun. It seems unlikely they’d use it, and it would cost them money (in the form of labor).

To my understanding, Java and .NET offer public LTSes because they’re financially buoyed by huge companies using those LTS versions, and Oracle and Microsoft are fundamentally selling that LTS support as a product. I have no idea why Node does, maybe it’s similar. But Bun’s position appears to be different than all three.

Re: Rewriting Bun in Rust

#412

Post by QuadmasterXLII »

Putting on my machine learning PhD student hat, the way to do this was to leave 10% of the tests out as a ‘test’ set and then once the port was done, bring them back in and find out how good the port is. The port may genuinely be good but because they spent 100k of compute hill climbing the whole test suite, “the test suite passes” now provides far less evidence that the port is good. Its weird that at Anthropic, a very ML phd company, no one pointed this out.

Re: Rewriting Bun in Rust

#413

Post by karatchov »

solid_fuel wrote: post #205
sashank_1509 wrote: post #125

I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow. Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify…

Ehh, I think this take needs a grain of salt. There's a few significant facts here: - They had an existing functional Zig implementation - They had an existing test suite for the Zip implementation - They had a separate JavaScript compliance test suite with ~ 1 million tests - The person overseeing the rewrite was responsible for a huge portion of the existing codebase and was very familiar with the existing architec…

You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !

and btw, if it can write code, it can write tests and test suite

Ai has come a long way, 2 years ago, this task would be impossible ! 1 year ago, it would hit a dead-end in the first hours of the execution

This blog post is nothing short of an amazing and fascinating tale, yet in some aspect very very scary ...

Re: Rewriting Bun in Rust

#414

Post by graemep »

zamadatix wrote: post #361
pier25 wrote: post #190

Earlier quoted context omitted.

Java, Node, and .NET have LTS versions all of which are free to use. > Or are you expecting open source maintainers to do free work for no particular reason? Free work? Last I heard Anthropic had acquired Bun.

Getting to an LTS release train of bun is probably a good idea, assuming they are still interested in external adoption rates. They shipped 1.0 a little under 3 years ago and the acquisition has had ~6 months to get settled. Looking at an LTS release would enable a lot of the more slower moving places to look at bun within being worried about getting caught up in the velocity. I don't know it makes sense to try to ma…

> assuming they are still interested in external adoption rates.

If they are not it would be a good reason to move away from it.

Re: Rewriting Bun in Rust

#415

Post by pohl »

Barrin92 wrote: post #129

the thing I don't understand about this, given that the goal was a line-by-line transpilation, and the author had already transpiled it once from Go to Zig, why not write an actual transpiler? A problem is as complex as the smallest program required to solve it, and having an LLM, which doesn't produce deterministic output churn through almost 200 grand when you only need to write a deterministic program maybe 5% of…

This is a frequently mentioned criticism. Is there a good argument about why that approach could have been done in the same amount of time? Seems like larger scope and more uncertainty to me.

Re: Rewriting Bun in Rust

#416

Post by StriverGuy »

QuadmasterXLII wrote: post #412

Putting on my machine learning PhD student hat, the way to do this was to leave 10% of the tests out as a ‘test’ set and then once the port was done, bring them back in and find out how good the port is. The port may genuinely be good but because they spent 100k of compute hill climbing the whole test suite, “the test suite passes” now provides far less evidence that the port is good. Its weird that at Anthropic, a v…

Huh? This approach makes sense for non-deterministic problems. Not engineering problems that have deterministic end results.

Re: Rewriting Bun in Rust

#418

Post by akanet »

jsnell wrote: post #167
suby wrote: post #139

I'm so jaded at this point. The AI translation from Bun to Rust doesn't bother me, I think it's interesting, but that this blog was so clearly written by LLM's is offputting for some reason. I think after having to interact with LLM's for much of the day, it's exhausting to read LLM speak in so many things I see online. It feels almost disrespectful to the reader. It's written from a first person perspective, but Jar…

> that this blog was so clearly written by LLM's is offputting for some reason It doesn't read at all AI-generated to me. What section do you think is? (Pangram is very good at distinguishing between AI-generated and human text, and assigns a very low score to the article: https://www.salahadawi.com/hacker-news-ai-detector/rewriting... ) > Contrary to the amount of times "But honestly" or "genuinely" is mentioned, no…

The article is very clearly human written. The author discussed on twitter that he used Claude for visualization and feedback. You can simply say you don't like the writing style, but it is not a very useful comment to have written in any case.

Re: Rewriting Bun in Rust

#419

Post by randusername »

Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

I hope this isn't the takeaway!

Zig was the right tool to start, Rust is the right tool to finish.

Making something possible and refining something until it is high security and reliability are different problems. Zig is great, but for a JS runtime, I just don't think that's the best long-term fit.

Re: Rewriting Bun in Rust

#420

Post by metalspot »

jameskraus wrote: post #131
sashank_1509 wrote: post #125

I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow. Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify…

It's funny, I see the opposite and I would only trust a senior engineer with conducting such a wide-reaching change. I would be more likely to hire a senior engineer who might now be able to effect such change.

Exactly. AI opens up a massive development frontier of projects that were simply impossible before. It does differentiate though. In the old world most "software engineering" work had nothing to do with software engineering so being highly skilled, educated, and experienced in software engineering made very little difference in compensation, position, promotion, etc. "software engineer" isn't a real thing anyway. coding is a secretarial job. you have to move beyond the mindset that coding is doing something useful. it's not. it is a means to an end and now better means exist. if you want to be an engineer you have to think in terms of systems engineering and building systems that deliver defined externally testable capabilities. in a few more years the idea of reading and writing source code will seem as absurd as reading and writing asm seems today.
Post reply on HN