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

181–190 of 754 posts

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

#181

Post by staticassertion »

cornholio wrote: post #172
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. It's strict type system makes is less likely to make very dumb mistakes that other languages might allow. I question this. Yes, strong enforcement of invariants at compile time helps the LLM generate functional code since it gets rapid feedback and retraces as opposed to generating buggy code that fails at runtime in edge cases. On the other hand, Rust is a complex…

It's very easy to just instruct the LLM to build using isolated crates, to maintain boundaries, focus on "ports and adapters", etc, and not run into this - in my experience.

I haven't had any issues with this getting out of hand on >10KLOC vibed rust codebases.

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

#182

Post by johnny22 »

m4rtink wrote: post #117
scared_together wrote: post #27

Earlier quoted context omitted.

Unlike the GNU coreutils rewrite in Rust, the Bun rewrite in Rust is being undertaken by the owners of the project. That said, yes, you’re correct that Bun isn’t GPL: https://github.com/oven-sh/bun?tab=License-1-ov-file

Hmm, that's unfortunate - why does so much Rust stuff seem to default to MIT/BSD ? Just because Mozilla used that for most of the Rust stuff ? Do developers using Rust even know the difference ? Like how anyone can basically take all you work & base a proprietary fork on it with maybe saying "thanks" (attribution) if they feel like it ? :P

for the same reason most ruby and javascript/typescript stuff is. Heck, even most python.

Most of them never got into the GPL in the first place.

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

#184

Post by raincole »

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…

Yeah, that means it's an extremely successful experiment so far.

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

#186

Post by BearOso »

baq wrote: post #103
nbf_1995 wrote: post #33

Earlier quoted context omitted.

I can't help but wonder what this cost in USD assuming you paid standard rates from Anthropic. Can someone even ballpark the price?

Much less than what it’d costs for a team of rust engineers. This is both amazing and scary; has been for a while now.

It costs several times what it would cost a small team of engineers, even assuming you gave the engineers more time to do it. I'm guessing (wildly) this was around 0.5M USD in compute time. You do get the result quicker, though.

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

#187

Post by [deleted] »

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…

[deleted]

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

#189

Post by mort96 »

aystatic wrote: post #145
mort96 wrote: post #65

Earlier quoted context omitted.

It's not hallucination, it's a basic extrapolation. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" is the same statement as "using Zig resulted in Bun having an extremely high amount of crashes/memory bugs". It is then natural to ask whether their position is "using Zig results in an extremely high amount of crashes/bugs" in general.

That's a hell of a lot more than "basic extrapolation." You're misrepresenting the original claim to fight against one that's trivially easy to dispute. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" (which unlike Rust, doesn't prevent you from writing them) is a completely different statement than your "using Zig results in an extremely high amount of crashes/bugs." Implying that…

The point is that the "extremely high amount of crashes/bugs" is maybe not the fault of Zig after all, as was implied.

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

#190

Post by nyrikki »

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?

Zig is a middle ground. It solves some of the common foot-guns in C, Without the costs of affine substructural typing that offers Rust its super powers.

I am of the opinion that it is horses for courses and not a universal better proposition.

Because my needs don’t fit in with Rust’s decisions very well I will use zig for personal projects when needed. I just need linked lists, graphs etc…

While hopefully someone can provide a more comprehensive explanation here are the two huge wins for my use case.

1) In Zig, accessing an array or slice out of bounds is considered detectable illegal behavior.

2) defer[0] allows you to collocate the the freeing of resources with code.

That at least ‘feels’ safer to me than a bunch of ‘unsafe’ rust that is required for my very specific use case.

I was working on some eBPF code in C and did really miss zig.

For me it fits the Pareto principle but zig is also just a sometimes food for me, so take that for what it is worth.

[0] https://zig.guide/language-basics/defer/

Post reply on HN