Live data from Hacker News

Rewrite Bun in Rust has been merged

github.com

161–170 of 822 posts

Re: Rewrite Bun in Rust has been merged

#161
post #132
post #17

Why didn't they ask Claude to remove all of the `unsafe` at the same time??

"at the same time" is a recipe for failure with coding agents.

It's also a recipe for failure for ports in general. Same goes for the "not idiomatic Rust" comments above — that would be nonsense.

You want to port it as faithfully as possible to the original, porting it bug-for-bug, quirk-for-quirk. Then, over time, after the port has been proven to be as identical to the original as possible, you can gradually fix those kinds of internals.

That's why TypeScript's tsgo native port is so good.

Re: Rewrite Bun in Rust has been merged

#162
post #118

We should be greatful for this. This is the one public case study on how large-scale llm-driven code generation actually works out. With node and deno there are reasonable alternatives for everyone who don't want to use bun anymore.

It’s not a public study though. We’re not going to get trust worthy numbers about labor or token cost.

Re: Rewrite Bun in Rust has been merged

#163
Regardless the outcome, this is such a disrespectful move towards the huge amount of contributors who invested time and effort to learn the project and make it better. I hope the zig/dev community forks the project and continues the development. I'd rather use the fork than this project that has sacrificed its contributors for marketing purposes.

Re: Rewrite Bun in Rust has been merged

#165
post #147
post #146

I will move the handful of my projects that use Bun to something else. I don't trust governance that permits this kind of reckless change.

Same, just gonna stick with node. On the other hand, the trial by fire will be interesting to see... long term I can only imagine the kinks will surely work themselves out

Wait till you hear about https://github.com/nodejs/node/pull/61478

Re: Rewrite Bun in Rust has been merged

#167

Regardless the outcome, this is such a disrespectful move towards the huge amount of contributors who invested time and effort to learn the project and make it better. I hope the zig/dev community forks the project and continues the development. I'd rather use the fork than this project that has sacrificed its contributors for marketing purposes.

How is that different (in this sense) to any "slower" rewrites or other significant changes?

Re: Rewrite Bun in Rust has been merged

#168

Regardless the outcome, this is such a disrespectful move towards the huge amount of contributors who invested time and effort to learn the project and make it better. I hope the zig/dev community forks the project and continues the development. I'd rather use the fork than this project that has sacrificed its contributors for marketing purposes.

> this is such a disrespectful move towards the huge amount of contributors who invested time and effort to learn the project and make it better.

What? How?

You contribute to projects run by others with the understanding that others run the project, is this not the default assumption others have too when contributing to FOSS?

Is it disrespectful if my proposed feature was merged, but then later was removed because the maintainer just didn't want the feature anymore? In my mind, pretty clear it wouldn't, I'm only a contributor after all, not the maintainer or the person running the project.

Re: Rewrite Bun in Rust has been merged

#169
post #161
post #132

Earlier quoted context omitted.

"at the same time" is a recipe for failure with coding agents.

It's also a recipe for failure for ports in general. Same goes for the "not idiomatic Rust" comments above — that would be nonsense. You want to port it as faithfully as possible to the original, porting it bug-for-bug, quirk-for-quirk. Then, over time, after the port has been proven to be as identical to the original as possible, you can gradually fix those kinds of internals. That's why TypeScript's tsgo native por…

tsgo will inherit many benefits from go, even if it is never fully "idiomatic".

This is in direct contrast to this port, which requires significant re-architecting (or made "idiomatic", if you wish) in rust to achieve any of the benefits of the language. You can't re-architect one step at a time.

Re: Rewrite Bun in Rust has been merged

#170
post #135
post #76

Still writing the blog post about this. Will share more details. For where this is coming from, skim the bugfixes in the Bun v1.3.14 and earlier release notes. Rust won’t catch all of these - leaks from holding references too long and anything that re-enters across the JS boundary are still on us. But a large % of that list is use-after-free, double-free, and forgot-to-free-on-error-path, which become compile errors…

You, nine days ago[0]: > 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. Maybe... it wasn't such an overreaction? [0]: https://news.ycombinator.com/item?id=48019226

You're not alone in voicing this, another (now dead) comment did it earlier too with a bit more of an emotional response (https://news.ycombinator.com/item?id=48134229).

Still, do you folks never do something to see how you feel about something, then chose to go one way or another? I'm not sure why it's so hard to see that it was an overreaction at the time, because it was an experiment, then at one point it stopped being an experiment and now they've chosen to actually run with it?

Is this not a common occurrence for other people? Personally I change my mind all the time, especially based on new evidence, which usually experiments like this surface, I'm not sure I understand the whole "You said X some days ago" outrage that seems to cause people's reaction here.

Post reply on HN