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

701–710 of 822 posts

Re: Rewrite Bun in Rust has been merged

#701

Post by alethic »

Jarred wrote: post #422
vitaminCPP wrote: post #253

> +1009257 -4024 Bun is now over 1M lines of Rust code. This is approaching the size of the Rust compiler itself; except that BunJs is mostly a JavaScript interpreter wrapper + a reimplementation of the NodeJS library (Rust STD wrapper). I think BunJS is becoming the canary for software complexity management in the LLM era.

> mostly a JavaScript interpreter wrapper Not accurate. Bun is a batteries-included JavaScript & CSS transpiler (parser), minifier, bundler, npm-like package manager, Jest-like test runner, as well as runtime APIs like a builtin Postgres, MySQL and Redis client. This is naturally a ton of code.

Don't forget the image rendering library!

Re: Rewrite Bun in Rust has been merged

#702

Post by davidatbu »

debugnik wrote: post #685
davidatbu wrote: post #537

Earlier quoted context omitted.

Ah, I just learnt that you don't. Jarred's comment saying exactly that: https://news.ycombinator.com/item?id=48133806

I'll actually concede that, on a slower skim, some changes to the test suite and fixtures that first seemed suspicious to me indeed align with what those tests were doing previously, and I wish I could retract that comment. I still think it's not such an impressive test suite as it's being claimed; which, if this actually works out, should say more about Claude's skill than the people driving it.

Gotcha. I'm genuinely curious: by "impressive", are you referring to coverage? I'd be grateful if you could say a few words about it could be more impressive (e.g, if you indeed meant to talk about coverage, say what functionality/edge cases aren't covered as of now)

Re: Rewrite Bun in Rust has been merged

#703

Post by dgb23 »

petcat wrote: post #308
gm678 wrote: post #249

$ rg 'unsafe [{]' src/ | wc -l 10428 $ rg 'unsafe [{]' src/ -l | wc -l 736 Language Files Lines Code Comments Blanks ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Rust 1443 929213 732281 116293 80639 Zig 1298 711112 574563 59118 77431 TypeScript 2604 654684 510464 82254 61966 JavaScript 4370 364928 293211 36108 35609 C 111 305123 205875 79077 20171 C++ 586 262475 217111 19004 26360 C Header 779 100979…

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?

There is a qualitative difference between unsafe Rust and Zig as far as I know.

Re: Rewrite Bun in Rust has been merged

#704

Post by bmitc »

sesm wrote: post #368

When announcements say that rewrite took 1 week, I wonder how much time went into preparing this file with very detailed instructions on mapping Zig to Rust idioms: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573... On top of that, if you look at 'Pointers & ownership' and 'Collections' sections, the Bun codebase is already prepared, using internal smart pointer types that map 1-to-1 to Rust equivalents,…

That makes the Bun owner's claim, just a week ago in this site, even more dubious when he came on here and said this code was just an experiment and likely to be thrown away.

Re: Rewrite Bun in Rust has been merged

#705

Post by bmitc »

cortesoft wrote: post #656
jaccola wrote: post #373

Earlier quoted context omitted.

Yeah I don’t know what’s true when reading about LLMs. Same with comments here on hacker news. So much money on the line it’s clear they would seed communities with marketing shills (and some people are just tribal). Same since they own Bun, they have every incentive to make this seem easier than it was.

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

Most people do use LLMs, which is why they have the so-called pessimistic opinions they do.

Re: Rewrite Bun in Rust has been merged

#706

Post by bmitc »

prashantk_ wrote: post #698
gm678 wrote: post #249

$ rg 'unsafe [{]' src/ | wc -l 10428 $ rg 'unsafe [{]' src/ -l | wc -l 736 Language Files Lines Code Comments Blanks ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Rust 1443 929213 732281 116293 80639 Zig 1298 711112 574563 59118 77431 TypeScript 2604 654684 510464 82254 61966 JavaScript 4370 364928 293211 36108 35609 C 111 305123 205875 79077 20171 C++ 586 262475 217111 19004 26360 C Header 779 100979…

Better to know where memory bugs may happen than them being everywhere. Also, bun team are looking it to reduce it by a large margin. Since it was a line by line port, there is a good space for improvement. By first rust release, a significant number of it should be resolved.

Wouldn't it be better to port more idiomatically? Otherwise, you've done nothing but port all the existing bugs while creating new ones.

Re: Rewrite Bun in Rust has been merged

#707

Post by ozozozd »

adampunk wrote: post #527
asciimoo wrote: post #179

Earlier quoted context omitted.

The difference is exactly the speed. Slowly transitioning from one thing to another gives the opportunity to contributors to get involved in the process.

So? Keep up. Just because some set of hypothetical contributors want a slow-moving target and the maintainers want to be on Rust now, I'm supposed to be mad at the maintainers? Why?

I think they’re pointing out that maintainers would not care to continue.

You know, for some people the word _community_ doesn’t mean “my free developers.”

Re: Rewrite Bun in Rust has been merged

#708

Post by msdz »

Daishiman wrote: post #639
Barrin92 wrote: post #585

Earlier quoted context omitted.

>You're being extremely negative about this whole endeavour without looking at the evidence that this effort is going far more smoothly than expected no I'm being negative because as I just said, if you want to do a purely syntactic translation you don't even need an LLM , that's called transpilation and we've been doing it programmatically for decades . This is the kind of thing that looks great to people who can't…

A. Transpilation is not 100% compatible because there are many idioms in some languages that cannot be directly translated to others. The lifetime system in Rust disallows a lot of constructs coming from languages with more relaxed constraints. Ironically transpilation will produce code with worse semantics than an LLM. B. At this point it's clear that LLMs reason very effectively about code and its intent. If you ha…

Push comes to shove, you could probably still ask an LLM to generate transpiler code, if you're so inclined, and then have it fix the remaining "edge cases" afterward, right…?

Re: Rewrite Bun in Rust has been merged

#709

Post by bmitc »

Daishiman wrote: post #364
Barrin92 wrote: post #344

Earlier quoted context omitted.

if half of your files in a million line codebase are unsafe that doesn't tell you much any more. Presumably the point of a Rust rewrite is that you actually make use of Rust's safety features in a coherent way. But given the whole "let AI rewrite this for me" stunt nature of this project that was not going to happen because that would require well, actual thinking and a re-design. So now you have Zig disguised as Rus…

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…

COBOL to Java is a completely different thing and pretty much unrelated.

Rust can easily call C libraries and vice versa and so can Zig. A more appropriate and designed rewrite would identify the core pieces of the Zig code that were the primary sources of all the big issues. Then, you rewrite that component in Rust and verify that you get the expected improvements. That keeps the codebase stable, it keeps you honest on actually reducing bugs and issues, and other benefits. Then you either just keep it that way or slowly rinse and repeat.

Without doing the analysis of what the core issues were in the first place, the author of Bun can make no claims towards the rewrite. He claims to have fixed flaky tests and improved memory safety. Where is the analysis that shows this? Where is the proof and data? Does he even know where the issues in the Zig codebase were at? I saw a commit where a test had a one second sleep put in place.

Compare this to say the Racket rewrite where a significant portion of the C core was replaced by Chez Scheme and Racket itself. There were several blog posts doing both pre- and post-analysis, and Racket has far less users than Bun.

This rewrite is totally unprofessional and has been poorly and even antagonistically communicated. The author was on this site just days ago telling everyone to relax and that he'd probably throw out this code, and that was even after it had been brought up that this wasn't pre-communicated to users. If I was a dependent in Bun, I would migrate off immediately.

So I push back in the idea that this is the way to do a rewrite like this.

Re: Rewrite Bun in Rust has been merged

#710

Post by ozozozd »

hombre_fatal wrote: post #406
12_throw_away wrote: post #309

Earlier quoted context omitted.

The maddening thing is that there's a right way to do this if you have the patience and professionalism to do so. It requires building a bit of scaffolding (feature flags, cross-language calling support, harnesses for shadow testing, etc.), then you ship-of-theseus the codebase incrementally . This is not even incompatible with LLM-assistance, plus it breaks the thing up into smaller, reviewable changes that don't br…

There is never a right way, only trade offs. The thing about being a Monday morning quarterback is that you can always claim you would have used even more caution and process.

I mean, some trade-offs are “something for nothing” which by definition makes them “the wrong way.”

Real life does exist.

Post reply on HN