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

711–720 of 822 posts

Re: Rewrite Bun in Rust has been merged

#711

Post by bschwindHN »

cogman10 wrote: post #214
nefasti wrote: post #106

Earlier quoted context omitted.

The "idiomatic Rust" thing rubs me the wrong way. If someone writes Rust that compiles and works, that's Rust. full stop. Telling people it doesn't count until it's "idiomatic" is just gatekeeping. It quietly says you're not a real Rust dev until you've put in years and absorbed all the unwritten rules, which shuts out exactly the people who are still learning. Everyone writes "non-idiomatic" code when they start. Th…

I get the feeling, and shooting for idiomatic on a rewrite is definitely wrong. That being said, "idiomatic" is more just saying "clean and familiar". It's using the right language features in the right places. For example, you could write something like this fn add_double(a: f64, b: f64) -> f64 { return a + b; } fn add_float(a: f32, b: f32) -> f32 { return a + b; } But that's not idiomatic. Idiomatic would look some…

Pedantic:

    fn add>(a: T, b: T) -> T {
      a + b
    }

Re: Rewrite Bun in Rust has been merged

#712

Post by xienze »

sunrunner wrote: post #402
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,…

Ignoring things like whether the Rust that was output could be deemed qualitatively good, whether the resulting line count is appropriate, how much the codebase was ready or primed for this kind of exercise going in, and so on, is it fair to say that a 622 line artefact created up front is a relatively small cost for a potential increase in consistency or quality of output when the output is ~1M LoC? It seems like th…

> I'd also be interested generally in how much tacit knowledge was needed to come up with these rules and how much iteration on this file was needed, for example how many of the rules here came from a failure case hit as part of iterating on the translation.

I think that's the point the original poster was making. There's basically zero chance this file was just spit out by memory in an afternoon. It was obviously the result of a LOT of pre-planning and back and forth checking over the artifacts that Claude was incorrectly generating for one reason or another. So yeah, an extremely iterative process.

With rules as fine-grained as these, there was almost certainly many instances where hundreds of files are generated -> one particular file doesn't translate correctly -> add a rule for -> regenerate everything again -> crap, that rule broke a different file because -> add a rule for , another for -> regenerate everything again[0] -> repeat. The token costs must have been out of this world.

0: now I'm sure people will say "why would you regenerate a file that generated correctly once? Just mark it off the list and move on." Well, when essentially 99.9999% of your codebase is generated artifacts, the tiny fraction that is actually human-understandable is now the spec, the source of truth for everything. It HAS to be able to essentially redo the entire process if you expect any level of maintainability going forward.

Re: Rewrite Bun in Rust has been merged

#713

Post by msdz »

shimman wrote: post #642
oskarkk wrote: post #549

Earlier quoted context omitted.

> a technology that already deeply struggles to find customers As far as I know it's the opposite, Anthropic struggles to satisfy demand, they have tons of paying customers and their customer base is growing fast.

Wow as far as you know? That settles it then! Just ignore this: https://www.flyingpenguin.com/wheres-ed-anthropic-told-court...

So the takeaway here is that they scaled to just over $5bn instead of $6.6bn in revenue in just a few years…? Still sounds like plenty demand exists?

Re: Rewrite Bun in Rust has been merged

#714

Post by bmitc »

shimman wrote: post #384
_aavaa_ wrote: post #302

Earlier quoted context omitted.

1. Rewrite from zig to rust in as close to zig as you can. 2. Turn into idiomatic rust.

1. Get hired into a company where you have a solid bet on making multi-century lasting generational wealth (>$50,000,000). 2. Every waking moment do everything in your power to boost the company that might give you the ability to define the direction of technology for the rest of your life. 3. Use the only thing you have (bun) to help push you in this direction and do things to help boost LLM marketing (a technology…

This is exactly the case here.

The author of Bun is a Thiel Fellow, so he's already been trained in The Way.

People are trying to wash away the recklessness of this rewrite by applying engineering principles the author their self didn't apply. It's like trying to make sense of a certain president's words. There is a lot of missing analysis both before this rewrite, during it, and after that is missing. And given that Zig and Rust can interoperate with each other via C, it makes a wholesale rewrite even more bizarre.

Re: Rewrite Bun in Rust has been merged

#715

Post by noodletheworld »

manlymuppet wrote: post #628
therepanic wrote: post #246

About 9 days ago, Jarred wrote that it was far from certain that this would merge and that it was an overreaction. Ironic.

That doesn't mean he was lying. Just that things changed. It was uncertain then, and not so uncertain now.

> 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 would say it is reasonably clear they had already committed to rewriting at that point.

The possibility that that particular code might be thrown out was potentially true, but also totally unrelated to the previous statement.

At the end of the day, whatever, but this feels a heck of a lot like “ah, we didn't mean for this to be public yet” rather than “this is just a random experiment”.

AI companies love AI stories.

It is an AI company.

:p

[1] - https://news.ycombinator.com/item?id=48016880

Re: Rewrite Bun in Rust has been merged

#717

Post by ozozozd »

pl-nerd-9000 wrote: post #556

I just skimmed through the porting guide and based on the number of unsafe blocks, this looks like a fairly straight-forward mechanical translation. If that is the case, why didn't they just "vibe-code" a Zig->Rust translator and a small Rust/TS/JS/whatever script to orchestrate things. You don't even need pretty printing support because rustfmt exists. You'll save on a bunch of tokens, probably a lot of time/enegy,…

No time for common sense solutions! Tokens gotta go somewhere!

Re: Rewrite Bun in Rust has been merged

#718

Post by inamorty »

drzaiusx11 wrote: post #633
antonvs wrote: post #614

Earlier quoted context omitted.

How would you have achieved this “machine translation” without an LLM? It seems to me it would have been highly likely to be more expensive and more resource intensive - if realistically possible at all, short of implementing a general Zig to Rust translator first.

Even before the advent of LLMs, I have personally (and largely successfully) translated several production systems from one language to another. I've learned it's best to start with a mechanical translation, literally bug for bug, leaving shit exactly as I found it (just in another language.) I've done Perl to Java, Java to Kotlin, Python to Ruby, Ruby to Java, C to Swift, you name it. It's only when you change behav…

"Load bearing bugs"

Re: Rewrite Bun in Rust has been merged

#720

Post by BoorishBears »

famouswaffles wrote: post #623
BoorishBears wrote: post #616

Earlier quoted context omitted.

You're getting the responses you earned by intentionally being flippant as possible. If you had presented your point more thoughtfully, maybe I'd have spoon fed the point of my response, which 100% relates to what you said: your model of time compression is describing the speed of creating code. But Bun is more than lines of code and serves as core infrastructure for lots of other projects. It's a terrible look in te…

There's no reason to think there was an 'initial denial'. That's the point. Everyone here is saying there was denial because all of this happened in 9 days, and again, that's a silly assertion to make when humans did not create or review the code. Someone can have a swift turn in opinion when an incredible amount of change happens in a short time. The LoC comment I made was simply to serve as an illustration to how f…

Maybe it might be easier to understand if I was a really terrible engineer.

AI gives me 750k LoC PR that's mostly broken and unuseable on Monday.

AI then fixing it by adding another 250k LoC, is not going to convince me, a competent maintainer of a major Js runtime with years of contributions, plenty of downstream dependents, and an understanding of the AI zeitgeist... to merge it all in by the next Wednesday

Post reply on HN