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

How is the Bun rewrite in Rust going?

lockwood.dev

Post reply on HN
Print view View original

221–230 of 412 posts

Re: How is the Bun rewrite in Rust going?

#221

Post by insanitybit »

tomlockwood wrote: post #187
simonw wrote: post #183

Earlier quoted context omitted.

No, it's a raw count. I get that there's a baseline of unsafe that's necessary, but I was under the impression that some of those unsafes were in places where they could be replaced by more idiomatic Rust at a later date.

I don't think that's true. I think a fair chunk of them are places where Bun is handed a pointer by WebKit or something similar. I believe they write about this a little.

I think there's a reasonable expectation that unsafe could still be reduced by having shared, safer abstractions - that would lead to fewer `unsafe` results because the `unsafe` would be contained. I'm surprised that this isn't a higher priority target for them.

Re: How is the Bun rewrite in Rust going?

#222

Post by wrs »

mikeocool wrote: post #110
losvedir wrote: post #32

I'm not sure Anthropic even cares about "releasing" the next version. The rust one has been in use in Claude Code for more than a month now, used by millions of people, and that's as far as they probably really worry about it. They bought Bun for Claude Code and I doubt the open source project matters to them otherwise.

If that is really what they are concerned with, they probably could have just had Claude Code rewrite Claude Code in rust? That likely would be far more efficient than changing the language of your typescript runtime that ships to run your react-based CLI app. I imagine the $800k or whatever this has cost is coming out of Anthropic's marketing budget, so they can make a big splash about it.

If you look at the reasons for rewriting Bun [0], they weren’t about efficiency and they don’t apply to Claude Code. It’s already written in a memory-safe language, and doesn’t have to interface to a library with a tricky set of invariants.

[0] https://bun.com/blog/bun-in-rust

Re: How is the Bun rewrite in Rust going?

#223

Post by achenet »

wesselbindt wrote: post #219
Jarred wrote: post #148

Bun’s Rust rewrite shipped in Claude Code over a month ago and barely anyone noticed. Claude Code is widely used. The Rust rewrite is going well overall. In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likel…

In Dutch there's a saying, "wij van wc eend adviseren wc eend", and it fits perfectly.

Frenchman here, I Google Translated that and it says

"We at WC Duck recommend WC Duck"... I'm left scratching my head, if you'd care to spell out what the saying means for non-Dutch I'd appreciate it :)

Re: How is the Bun rewrite in Rust going?

#224

Post by JackSlateur »

leobuskin wrote: post #93
nickcw wrote: post #86

Maybe it would have made more sense for Anthropic to rewrite Claude Code in rust, and cut out the middle man (bun)?

Nope, they want shared artifact(s) between web and desktop (not sure what do they have in mobile apps) clients (Chat/Cowork/Code/CC-cli), so TS is the way to go. It’s a reasonable choice made by engineers.

Pretty sure rust can run on browsers;

Re: How is the Bun rewrite in Rust going?

#225

Post by busterarm »

swiftcoder wrote: post #201
busterarm wrote: post #168

Earlier quoted context omitted.

I've been in this industry for a few decades at this point and I was around when this meme was started. It was purely about maxing your compensation because changing jobs nets you more than promotions & raises. I've never met an engineer in my life who truly earned a promotion every year and very few every two. Very few companies have org charts that even support that or have that many levels. This logic/advice only…

> It was purely about maxing your compensation because changing jobs nets you more than promotions & raises. You don't view it as a problem that companies consistently compensate new hires higher than they are their experienced employees? Hell, I would have been perfectly happy to never change employers in my entire career to date, if my salary had anywhere near kept pace with my peers who were job-hopping.

> You don't view it as a problem that companies consistently compensate new hires higher than they are their experienced employees?

It depends on the current employee and the incoming employee. They are not interchangeable cogs. Also not everyone consistently provides good value over their tenure -- a lot tend to work hard early and then for various reasons taper off. It's not necessarily their fault, but companies definitely are aware of this.

Personally I tend to value growth of my skillset over growth of income and that has largely informed my movement. I move when there's no longer interesting work if the compensation is at least fair. I've never been about comparing myself to others -- especially when most of my peers' left the industry after 5-10 years.

Re: How is the Bun rewrite in Rust going?

#226

Post by [deleted] »

sigbottle wrote: post #96
benjiro29 wrote: post #41

I really do not understand how software developer think anymore. Using a LLM to translate a project in a short time, is by itself incredible. Just like one-shot whatever office clone. But what makes software is not the fast creation of a "product" but that actual development of its features. Figuring out how everything needs to work together, fixing the bugs, and the o so boring UI work. I have used LLMs to create st…

The more technical you get, the more subsitutable you become - or at least, people think of it in that way, because the whole idea is "It's not me, or the people, it's the raw technical prowess that earns its keep in this place". But it seems like we're finally starting to accept that "accidentals" like network effects, ownership, accountability, etc. are important. Of course, that's why many of us fled to technical…

[deleted]

Re: How is the Bun rewrite in Rust going?

#227

Post by wesselbindt »

achenet wrote: post #223
wesselbindt wrote: post #219

Earlier quoted context omitted.

In Dutch there's a saying, "wij van wc eend adviseren wc eend", and it fits perfectly.

Frenchman here, I Google Translated that and it says "We at WC Duck recommend WC Duck"... I'm left scratching my head, if you'd care to spell out what the saying means for non-Dutch I'd appreciate it :)

It was a commercial slogan for a toilet cleaning agent. An English equivalent would be "mr clean recommends you use mr clean". Today, it is used to point out when someone tells you they themselves delivered good work. Anytime you'd use the meme of Obama giving himself a medal, you could use this phrase.

Re: How is the Bun rewrite in Rust going?

#228

Post by skeledrew »

TazeTSchnitzel wrote: post #217
skeledrew wrote: post #150

Earlier quoted context omitted.

> one that an unsupervised LLM rewrite is probably not even going to attempt. Why not? A complete test suite exists, so it just boils down to "reimplement this code to reduce the number of 'unsafe' references, while keeping the tests passing" (the last part isn't even needed since Claude loves to run tests and linters anyway).

An LLM definitely can do that work, but LLMs have a tendency to follow the path of least resistance unless you force them to do things properly and carefully supervise them.

> LLMs have a tendency to follow the path of least resistance

That's a really strong motivation for the Rust port. It's literally impossible to take a path not leading to an unacceptable outcome because the Rust compiler fails the compile if code no longer marked "unsafe" is still actually unsafe, and the tests fail if the implementation is incorrect. The compiler actively helps to force the LLM to do things properly.

Re: How is the Bun rewrite in Rust going?

#229

Post by dminik »

chmod775 wrote: post #81
muglug wrote: post #47

Earlier quoted context omitted.

A major rewrite in another language is also unusual for this project. It took TypeScript a year to go from announcing tsgo to releasing TypeScript 7.0. That work was done in parallel; here the work is being done serially — and it’s likely to take much less than a year for a new release.

> It took TypeScript a year to go from announcing tsgo to releasing TypeScript 7.0. These are not comparable at all. The bun "rewrite" really is more of a translation of a software that is mainly dogfooded, created with an at best loose regard for a wider ecosystem. TypeScript 7.0. by comparison is not just a translation from one language to another. It's a true rewrite that at the same time has to consider a massive…

It's funny, but a large reason for why Go was chosen was explicitly because it has semantics close to TypeScript and that made it automatable:

https://github.com/microsoft/typescript-go/discussions/411#d...

> But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping.

So basically the opposite of what you're saying.

Post reply on HN