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

Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

twitter.com

Post reply on HN
Print view View original

441–450 of 754 posts

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#441

Post by rkajdh »

johncolanduoni wrote: post #425
baranul wrote: post #364

Earlier quoted context omitted.

Especially if given near unlimited tokens to burn through, because any level of success fuels the LLM hype machine, which brings ROI. > It’s engineering. Significantly, but not totally. The marketing value can't be ignored.

What do you think one would have to pay to have flesh-and-blood engineers get a cross-language port of a codebase of over half a million lines with a broad test suite to over 99% conformance? I think it would be astronomically high, especially given that for this specific project your hiring pool is going to be limited to people who can get up to speed with Zig and JavaScriptCore right away (or you’re going to have t…

The hype machine is real and we will talk about it as long as it pleases us. It took decades to get rid of smoking in public places and restaurants, and the clankers will eventually fall, too.

So cash out before that.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#442

Post by ozgrakkurt »

Tiberium wrote: post #34

I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust. Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

[flagged]

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#443

Post by andy_ppp »

lioeters wrote: post #244
legerdemain wrote: post #38

From 4 days ago: https://news.ycombinator.com/item?id=48019226 > 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 i…

Also a few days before that: > I expect OSS to go the opposite direction: no human contribution allowed. Slop will be a nostalgic relic of 2025 & 2026. We should have seen this coming after they got acquired by Anthropic, but it's still disappointing. I'm not against large language models as a technology, just thoroughly disgusted how these "AI" companies rose to power, eating the software industry and the rest of so…

It isn’t really slop anymore and it will keep improving.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#444

Post by skeledrew »

wiseowise wrote: post #281
tempaccount5050 wrote: post #258

Earlier quoted context omitted.

Software companies have been about automating human labor since the invention of computers. It's the whole damn point. Why do you think finance used to be (sometimes still is) the head of the IT dept? Because we automated accounting away. Then typists. Then secretaries. Then drafting. Etc etc.

> It's the whole damn point. Believe it or not, for some of us it’s not “the whole damn point”.

Why else would one create software, if not to do something that a human does/did?

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#445

Post by ozgrakkurt »

thayne wrote: post #162
leecommamichael wrote: post #47

Earlier quoted context omitted.

Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? There is a lot of quality stuff made with C/C++, so what is Zig doing wrong?

It is much harder to write quality stuff in c/c++ that doesn't have memory bugs (use after free, out of bounds access, use of unitialized memory, double free, memory races, etc.). I wouldn't say it isn't feasible to build high quality software in those languages, but even the highest quality software written in those languages has these types of bugs. Zig is better than c, and maybe a little bit better than c++, espe…

I use clang, LLM, zig compiler, brave, firefox, kde, linux, steam, PC games, neovim, ghostty and more software written in c/c++/zig, and I can't remember the last time I had a crash issue with memory issues.

KDE also includes many other programs inside it like music player, document reader etc. that I never had any issues with.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#446

Post by pier25 »

jwpapi wrote: post #314

Completely unbased, but I don’t want to have to do anything with bun anymore. It’s just a gut feeling, but I don’t trust them and support them. They fork Zig to utilize LLM rewrites and build something the Zig team clearly disregarded (non-deterministic compiling) And now like a whiny baby they LLM rewrite to Rust. There is a very real chance that Zig design philosophy got them to the point where they are now by enfo…

> It’s purely politics-based not technical

Jarred mentioned having to work on fixing memory leaks as the main motivation to try this.

https://xcancel.com/jarredsumner/status/2053058171338682875#...

I was never fully comfortable with Zig given it's much less mature than Rust. Maybe this will be for the better.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#447

Post by Georgelemental »

gravypod wrote: post #420
tempaccount5050 wrote: post #306

Earlier quoted context omitted.

Whether or not you want to admit that is up to you. If you're selling automation or efficiency gains, you're removing human labor.

My first "job" in computing, where someone else paid me for code, was in a research context where we were modeling radio propagation. Nothing about that was removing human labor. It in face eventually called for a bunch of humans to interact with each other. See: https://www.hamsci.org/basic-project/2017-total-solar-eclips... I don't think it is fair to claim computers are about putting people out of jobs.

Human labor could do the math by hand

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#448

Post by dnautics »

josephg wrote: post #380
dnautics wrote: post #175

Earlier quoted context omitted.

It's not.. but im pretty sure it could be. could probably even take this (WIP) idea and bolt on a formal verifier pretty easily. https://github.com/ityonemo/clr

It'd take more than that to match rust's borrow checker. Rust's borrow checker tracks lifetimes, and sometimes needs annotations in code to help it understand what you're actually trying to do. I suppose you could work around that by adding lifetime annotations in zig comments. Then you've have a language that's a lot like rust, but without an ecosystem of borrowck-safe libraries. And with worse ergonomics (rust know…

> I suppose you could work around that by adding lifetime annotations in zig comments.

you can make a no-op function that gets compiled out but survives AIR

> rust knows when it can Drop.

and its possible to cause problems if you aren't aware where rust picks to dropp.

> And rust can put noalias everywhere in emitted code.

zig has noalias and it should be posssible to do alias tracking as a refinement.

> But if you want static memory safety in a low level systems language, its probably much easier to just use rust.

don't use that attitude to suck oxygen out of the air. rust comes with its own baggage, so "just using rust because its the only choice" keeps you in a local minimum.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#449

Post by refulgentis »

thrwaway55 wrote: post #434
perching_aix wrote: post #413

Earlier quoted context omitted.

So do you picture them locking up the Rust port behind closed doors as well, or what's the game gonna be? Cause it reads like it's kinda all public already.

Absolutely not, I think they prioritize it because it's internal. I to expect to see a stronger marketing push on its ability to do language translations because there is honestly value in that. Question is when they have compute but it's less crisis marketing then their security stuff so I'd see it at a lower priority. I just don't think it's as honest as the parent post posits

The Mythos-truther community is absolutely batshit, sorry. You wrote fanfic and now you're writing more fanfic. The company is faking for marketing so therefore they're faking for marketing. The only things in common between the two situations are you and the word Anthropic, the rest of us are just confused and worried. I'm worried, that's why I'm speaking to you plainly.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#450

Post by davidatbu »

Robdel12 wrote: post #113

Bun is going this route because their proposed fix wasn’t great. https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... Cannot imagine this agent rewrite had anyone review any the code (you can’t at that speed). I’m positive this will go extremely well :p

Fwiw, that's not the stated motivation for the rewrite experiment. In fact, the Rust rewrite is slower to compile than the zig code when compiled with their internal fork of zig (tho it is faster when OG zig is used).

I don't want to infringe upon your right to speculate. I just want to point out that your statement is at best a speculation.

Post reply on HN