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

651–660 of 822 posts

Re: Rewrite Bun in Rust has been merged

#651

Post by thayne »

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,…

Given zig instability (as in frequent breaking changes), it wouldn't surprise me if they intentionally design bun from the start in a way to make it easier to migrate to rust if needed.

Re: Rewrite Bun in Rust has been merged

#652

Post by giancarlostoro »

shimman wrote: post #645
giancarlostoro wrote: post #629

Earlier quoted context omitted.

Do you have any proof Anthropic pushed for this? Because the author has been clear this was an experiment they wanted to test out on their own, only when it seemed to be in a working state did they consider, okay maybe this might work for us.

Does it take a phd in psychoanalysis to not see that the company that has been marketing the fuck out of lame publicity stunts, to not take advantage of another publicity stunt? Good lord, no wonder the public hates tech workers.

I refuse to blindly hate something because someone tells me to with no evidence, if you want to hate me for that, so be it, that sounds like a personal problem.

Re: Rewrite Bun in Rust has been merged

#653

Post by giancarlostoro »

tempest_ wrote: post #636
giancarlostoro wrote: post #626

Earlier quoted context omitted.

Plus I seem to recall the Rust community solved this issue by making tooling that proofs if unsafe code is truly unsafe, I remember one of the concurrent frameworks got scanned and people freaked out, the creator was about to abandon ship entirely as a result, don't recall what fully came of it. Anyway my overall point being, if there's already tooling to find the truly unsafe / bad code, it might make fixing it simp…

There is no Rust tooling that tells you if your unsafe code is shit or not. If there was you wouldn't need the unsafe stuff at all. The Actix web stuff was the maintainer using unsafe code to increase performance (iirc, it was a long time ago) in what was the most popular rust web frameworks at the time. It has since declined and been supplanted by other projects but the push was mainly a web framework shouldn't need…

Maybe my memory is hazy on it, but yeah that's the exact drama I remember.

Re: Rewrite Bun in Rust has been merged

#654

Post by ryukoposting »

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,…

Similar highly crafted success stories getting passed around within some big tech firms right now.

We got told that someone wrote a huge, sophisticated driver in Rust in a single day using Claude Code. This is being pushed as a case of AI doing something that we encounter on a regular basis, way faster than a human could do it.

Some ommitted details: Turns out the official spec for this driver is written in C, and the standard has a massive official suite of unit tests.

Re: Rewrite Bun in Rust has been merged

#655

Post by docmars »

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.

Re: Rewrite Bun in Rust has been merged

#656

Post by cortesoft »

jaccola wrote: post #373
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,…

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.

Re: Rewrite Bun in Rust has been merged

#657

Post by solid_fuel »

bhaak wrote: post #335
losvedir wrote: post #276

Wow. This is going to be interesting to follow. There's absolutely no way any of this code was reviewed, but maybe we're in a post-human world now where you can trust the models to write and review the code. This is like Gastown but on a higher profile project. Will be fascinating to see how this project is able to add new features going forward (or even _if_ it will be able to). Does anyone know how exactly Bun is u…

It passed all the tests. If you can't trust your test suite to catch an automatic language translation you shouldn't trust it at all. :)

The entire underlying system has been replaced. The test suite is written around the current fuzzy edges and past problem areas, not every single behavior of the existing platform.

"If you can't trust your test suite to catch a hardware floating point arithmetic bug, you shouldn't trust it at all."

"If you can't trust your test suite to catch a JVM bug, you shouldn't trust it at all."

"If you can't trust your test suite to catch a recurring memory error, you shouldn't trust it at all."

Re: Rewrite Bun in Rust has been merged

#658

Post by gofreddygo »

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,…

Its like that hackathon winner project that everyone knows wasn't ideated or built there. True to the law, not to the spirit.

Re: Rewrite Bun in Rust has been merged

#659

Post by Pay08 »

giancarlostoro wrote: post #626
brandly wrote: post #595

Earlier quoted context omitted.

Aren't the Rust unsafes a reflection of the Zig it was ported from? However now that you're working with Rust, you're in a position to continue improving and eliminating the unsafes.

Plus I seem to recall the Rust community solved this issue by making tooling that proofs if unsafe code is truly unsafe, I remember one of the concurrent frameworks got scanned and people freaked out, the creator was about to abandon ship entirely as a result, don't recall what fully came of it. Anyway my overall point being, if there's already tooling to find the truly unsafe / bad code, it might make fixing it simp…

You're likely thinking of Miri, a sanitiser. It's not a proof solver, but it screams to high heaven about this code nonetheless.

https://github.com/oven-sh/bun/issues/30719

Re: Rewrite Bun in Rust has been merged

#660

Post by nicce »

steve_adams_86 wrote: post #597
nicce wrote: post #512

Earlier quoted context omitted.

Odd take. Bun was not option for me because or Zig. There was no security. Issue tracker has 3000 issues about segfaults. Now I might actually reconsider.

> There was no security >1M lines of un-reviewed code are secure?

Comment was more like pick your poison. Eventually it gets reviewed if they are serious. Old version had no future for serious production on anytime soon. This might get there.
Post reply on HN