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

Rewrite Bun in Rust has been merged

github.com

Post reply on HN
Print view View original

671–680 of 822 posts

Re: Rewrite Bun in Rust has been merged

#671

Post by famouswaffles »

drzaiusx11 wrote: post #640
famouswaffles wrote: post #624

Earlier quoted context omitted.

Transpilation won't get you passing 99.8% of a comprehensive test suite of a 700K+ codebase in a week (and maybe none at all) and that's assuming transpilation is practical for the pair in question. So if you remotely want these kinds of results, then you most certainly do need an LLM.

There are literally formally verified language transpilers out there today. They can get you 100% coverage without "cheating" like LLMs tend to do by modifying test suites to pass, etc. I'm currently using an LLM in my day job to accelerate such a 1:1translation, and it's certainly "working"/making progress but God I wish I had a formally verified machine translator instead of this probalistic bullshitting LLM. Don't…

I mean No-one is forcing you to not use a transpiler right? If it was quicker to use one or build a specific, limited one for your existing codebase and run it then you would certainly have done that already.

Re: Rewrite Bun in Rust has been merged

#672

Post by vintermann »

LAC-Tech wrote: post #637
petcat wrote: post #308

Earlier quoted context omitted.

Cool you can just search specifically for potentially unsafe code in Rust. How do you search for unsafe code in Zig? Or do you just have to assume it's everywhere?

It's worth pointing out that "unsafe" in rust is not a very sound concept - it's not like a monad or "function colour" whereby the compiler can say "this code ultimately calls unsafe". It's more like a comment on steroids; you call unsafe in a function, write a comment about it, and no caller of that function would have any idea that it's calling unsafe code.

Yes, the point of unsafe is that you promise it's safe, you promise to preserve the necessary invariants to make it safe to call no matter from where. It was never supposed to "taint" all code that calls it, that would defeat its purpose. It's sound enough, it's just not at all trying to do that.

Re: Rewrite Bun in Rust has been merged

#673

Post by _puk »

abustamam wrote: post #668
cortesoft wrote: post #656

Earlier quoted context omitted.

You can just use AI for yourself and see. It isn't some mysterious product that only a few people get to use.

While this is true, it's also true that few people have the budget to spend a bunch of tokens on porting bun over to rust.

And yet we have stories[0] of companies judging merit on tokens used.

Rather than using these tokens to do rewrites that have the potential to massively improve the day to day, they're just burnt for the sake of burning them.

It's individual initiative, and company culture that are at play as much as budget.

0: https://news.ycombinator.com/item?id=48110529

Re: Rewrite Bun in Rust has been merged

#674

Post by dgoldstein0 »

fbernier wrote: post #304
ordu wrote: post #289

Earlier quoted context omitted.

The half of the files contain 'unsafe' keyword? It doesn't seem as a good rewrite. What is the point of rewrite into Rust, if ~half of your code is still unsafe?

Bun is fundamentally a boundary-heavy system and it also rolls its own version of a lot of things that people typically use via libraries, where unsafe is hidden. (no async, memory arenas, etc). It also uses FFI heavily which requires unsafe. It also looks like the top 2 maintainers are currently actively working on getting the amount of unsafe down and it's going down quickly.

If the unsafe can be iteratively removed and the final code is of reasonable quality that seems like a sane strategy. Any large migration just needs to be doable incrementally so progress can be made.

Re: Rewrite Bun in Rust has been merged

#675

Post by vintermann »

Barrin92 wrote: post #516
Daishiman wrote: post #364

Earlier quoted context omitted.

And? This is absolutely the correct and standardized way to do mechanical rewrites: you do a rewrite that maps directly to the original source so you can rely on the original correctness guarantees and bug-for-bug compatibility and log issues, and then you go into the next phase where you begin to use idiomatic constructs. This is the same in COBOL-to-Java ports that have been done in banking and insurance for the pa…

>This is the same in COBOL-to-Java ports it isn't, because those guys didn't think a naive 1-1 machine translation would give them the benefits of Java, which somehow the people involved in this rust rewriting seem to think they've already gained despite the virtually identical code. If the whole point genuinely would have been to do a purely mechanical translation they could and should have written a transpiler, whi…

You gain some benefits. You could in theory gain benefits in compilation speed, portability or even memory use and execution speed, from an automatic language translation. But everyone, including the bun people, understand that you certainly don't get code clarity benefits, and safety benefits is extremely dubious.

Re: Rewrite Bun in Rust has been merged

#676

Post by lelanthran »

antonvs wrote: post #621
BoorishBears wrote: post #462

Earlier quoted context omitted.

It's really simple. 9 days ago this is how the migration was described: > 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…

> Those people essentially predicted that Bun's actions would shortly reflect much more conviction than was being let on. Ironically these people are displaying great confidence in AI’s abilities. If that’s the case, what are they objecting to exactly?

> Ironically these people are displaying great confidence in AI’s abilities.

Maybe they were displaying high confidence in a marketing machine's ability to commit to dangerous stunts.

Re: Rewrite Bun in Rust has been merged

#677

Post by kursus »

docmars wrote: post #655

I hate to say this, but this reeks of "We're owned by Anthropic now and we were put to task to prove Claude Opus as the ultimate AI model, so we were forced to do a full port of something millions of developers rely on to Rust in record time. Just ignore the slop and unsafe statements." (sweeps the broom) This is nothing more than a marketing stunt from Anthropic. Nothing to see here.

> millions of developers

Try a few thousands.

Re: Rewrite Bun in Rust has been merged

#678

Post by sph »

swatcoder wrote: post #403
ordu wrote: post #289

Earlier quoted context omitted.

The half of the files contain 'unsafe' keyword? It doesn't seem as a good rewrite. What is the point of rewrite into Rust, if ~half of your code is still unsafe?

> What is the point of rewrite To win a news cycle. For the forseeable future, the AI market competition is not about which product can provide the most valuable utility to users. It's about which product can be holding the protective aura of social media and investment zeitgeist while competitors buckle under the strain from unfulfilled hype and over-leveraging. Utility, engineering, efficiency... these are all meni…

Bannon’s ‘flood the zone’ strategy applied to AI.

Re: Rewrite Bun in Rust has been merged

#679

Post by jorangreef »

j-pb wrote: post #488
jorangreef wrote: post #445

Earlier quoted context omitted.

> I wonder if Tigerbeetle will also have problems arguing for their solution now that the other project they can point to for customer assurance is gone. In general, we never like to appeal to popularity (a logical fallacy), but why would you assume here that we would point to Bun specifically (or any project for that matter) [1] as an example of Zig’s quality? We prefer to judge Zig’s quality on its own intrinsic me…

Correct me if I'm wrong, but the three largest Zig project (by far, with a huge gap between them and the rest of the pack) are Bun, Ghostty, and TigerBeetle. A language so niche that it only has 3 major projects is a liability. Now it has 2 major projects, one of which is yours. Even I as a weird language connoisseur would raise an eyebrow at that. After switching from Zig to Rust, I felt like the language was helpin…

> Correct me if I'm wrong, but the three largest Zig project

I did correct you where you are wrong (“appeal to popularity” as a logical fallacy).

> I can't help and wonder where you could be by now if your language was lifting you up, instead of you having to lift up your language.

Did you know we’ve had on the order of 3 memory bugs in 6 years of TigerBeetle?

We also reached production in 3.5 years, bringing not only a global consensus implementation, but also a local storage engine to market. (Each of these typically take 5-10 years elsewhere to reach maturity).

Zig does lift us up.

In fact, Zig’s memory model has always been the perfect expression of TigerStyle. And TB could not have been designed the way it is today in any other language (including Rust). Implicit allocation, global allocator… you automatically lose OOM-safety. But the zero-copy intrusive memory techniques we use… Zig is perfect for TigerBeetle.

Post reply on HN