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

501–510 of 754 posts

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

#501

Post by drysine »

zephen wrote: post #464
fooker wrote: post #422

Earlier quoted context omitted.

How is defer not magic sauce?

Whether you consider it magic is up to you, but, unlike a destructor in RAII, there is nothing automatic going on. If you don't explicitly invoke a destructor, you won't get a destructor. The fact that you can explicitly invoke the destructor to happen later is simply syntactic sugar, just like if/else/while, or any other control construct more powerful than a conditional jump instruction.

> If you don't explicitly invoke a destructor, you won't get a destructor.

When you explicitly invoke a "destructor", you do it on many code paths (and miss one or two)

>The fact that you can explicitly invoke the destructor to happen later

You don't specify where the `defer`-red "destructor" will be invoked.

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

#502

Post by baranul »

sysguest wrote: post #118
Jarred wrote: post #105

Earlier quoted context omitted.

cargo check reported over 16,000 compiler errors when I wrote that message. It could not print a version number or run JavaScript. I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive. There’ll be a blog post with more details.

> I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. haven't used zig...(only used rust) but zig doesn't solve those problems?

It is quite obvious that Zig is pre 1.0 with thousands of stranded unsolved issues (per their GitHub repo). A review of Zig hype gives the strong impression it was created by being relentlessly and suspiciously pushed on HN, beyond logic or its language rankings (per TIOBE or GitHub stats), so that many were under the illusion that the language was something more or other than what it really is.

Zig is still under development and beta. Stability, crashes, and leaks should not be surprising, and even expected. To stick with a beta language, usually companies and developers are philosophically and/or financially aligned with the language. An example is JangaFX and Odin, where they not only have committed to using the language (despite being beta) in their products, but have directly hired GingerBill.

Team Bun appears to have "alignment and relationship issues" with Zig, to the point they have decided to extensively explore their options. Now Bun is rewritten in Rust. They are seeing if Rust solves their requirements. As with any relationship, if one ignores or takes a partner for granted, don't be surprised if they want a divorce or jump to someone else.

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

#503

Post by kzrdude »

aurareturn wrote: post #5

6 days of work to do this. Even if it doesn't end up becoming meaningful, it shows just how tokens and work done will be linked now and in the future. It's going to be hard to compete with someone or a company that has more compute. They will just be able to do things you can't.

It's a new era of capital, literally, in software development. Ownership of the means of production is now concentrated.

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

#504

Post by jwpapi »

NewsaHackO wrote: post #421
stingraycharles wrote: post #402

Earlier quoted context omitted.

Ah, fair enough then, you mean want to clarify that a bit as it can be interpreted both ways. And the whiny baby part seems a bit uncalled for and distracting from the point you’re trying to make.

Don't give them too much credit, they responded to other comments clearly referring to the developers' comments on twitter about his technical motivations. He's just backtracking now due to your comment.

I meant the developers motivation with "whiny baby" and I take the point that this was over the top and I could’ve found better words.

But I meant that my comment is "politics-based and not technical", because the gut feeling is more based on my reading of soft factors than it is from in-depth technical analysis of everything involved.

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

#505

Post by oytis »

cdelsolar wrote: post #374
oytis wrote: post #267

Earlier quoted context omitted.

But what is the purpose? When you rewrite a project in another language, it's for engineers to be able to maintain and further develop the project better on some metrics due to advantages of the language. It doesn't hold when LLM does the rewrite, since there is no one who understands the code after that. It's a good demonstration of capabilities, sure, but the result itself makes no sense. We'll have to figure out w…

why do you think no one understands the code after the LLM rewrites it?

Becase no one has written it. You can't ask the guy who has written it, not because this guy has left, but because he does not exist. Also, it often reads weirdly.

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

#506

Post by AppAttestationz »

I suspect that the test suite isn't that great tho. Bun has so many different behaviors compared to other JS engines, sometimes just plain wrong or contradicting the spec. Test suite didnt catch those.. Not sure how much I trust the rewrite :)

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

#507

Post by zozbot234 »

gobdovan wrote: post #225
carllerche wrote: post #191

Earlier quoted context omitted.

> On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code. Are you saying this out of personal experience or just hypothesizing? I am working on a large, complex rust project with Claude Code and do not experience this at all.

It can happen like this: - write sleek operator-overloading-based code for simple mathematical operations on your custom pet algebra - decide that you want to turn it into an autograd library [0] - realise that you now need either `RefCell` for interior mutability, or arenas to save the computation graph and local gradients - realise that `RefCell` puts borrow checks on the runtime path and can panic if you get alias…

You can still use the fancy operators for readability, just use a macro to translate them into the actual code. Very common pattern in non-trivial Rust libraries.

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

#508

Post by stingraycharles »

gamegod wrote: post #318
oytis wrote: post #267

Earlier quoted context omitted.

But what is the purpose? When you rewrite a project in another language, it's for engineers to be able to maintain and further develop the project better on some metrics due to advantages of the language. It doesn't hold when LLM does the rewrite, since there is no one who understands the code after that. It's a good demonstration of capabilities, sure, but the result itself makes no sense. We'll have to figure out w…

This is such an insightful comment. It also underscores why these AI companies' marketing efforts are promoting rewrites.

I agree that the comment is insightful, but I don’t think AI companies are particularly promoting rewrites, other than that it’s a task LLMs are good at as “the code is the spec”.

The industry as a whole still is realizing that any LLM usage that actually writes all the code for you is causing cognitive debt, and we’re even slowly losing our skills of the art.

I’m trying my best to navigate this myself, but no matter what we do, using LLMs is both a blessing and a curse.

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

#509

Post by logicchains »

mohsen1 wrote: post #75

Very impressive that they could do this so quickly because I have been on a similar project (porting TypeScript to Rust) for 5 months. But I guess I don't have access to Mythos and unlimited tokens. I'm also close to 100% pass rate. 99.6% at the time of writing. https://tsz.dev Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languag…

>Rust is perfect for writing all of code using LLM.

Rust is a terrible language for using LLMs to write code if Rust's low latency isn't needed, because of its extreme compile times. LLMs code faster than humans so a far bigger fraction of the time is spent waiting for the compiler, and a reasonably sized project will take literally 10x longer to compile in Rust than in e.g. Zig or Go.

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

#510

Post by _flux »

X-Istence wrote: post #174
baq wrote: post #112

Earlier quoted context omitted.

You should try GPT, I’d be really interested to hear if it works better. (Exclusively using GPT for systems work at $DAYJOB, but compare with opus every couple weeks and GPT consistently gives me better results)

I've been comparing Claude vs Codex using GPT and Claude consistently is better than GPT about reasoning, about writing code, and using the tools as appropriate. GPT for instance had a lot of issues using git worktrees, and didn't understand how to correctly use it to then merge stuff back into a main branch, vs Claude which seems to do this much more naturally. GPT also left me with broken tests/code that I had to i…

> GPT for instance had a lot of issues using git worktrees, and didn't understand how to correctly use it to then merge stuff back into a main branch, vs Claude which seems to do this much more naturally.

I wonder how much of that is due to the model being somehow better, or the harness having built-in instructions on how to use them.

I've used worktrees with Codex just fine, but I instructed it to use my scripts for setting it up and tearing it down. The scripts also reflinked existing compilation artifacts to speed up compiling and allocated a fresh db instance for it, but then also applied a simple protocol for locking the master repository during merges, so multiple agents wouldn't try to merge at the same time. It has been following those instructions quite well.

Post reply on HN