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

Rewriting Bun in Rust

bun.com

Post reply on HN
Print view View original

371–380 of 560 posts

Re: Rewriting Bun in Rust

#371

Post by rvz »

cognitiveinline wrote: post #268
rvz wrote: post #193

Earlier quoted context omitted.

> As steveklabnik noted above, Hacker News does not have a meme-y culture. For this one, yes it does. Go search this one up yourself. [0] Literally everyone in the comments in [0] and even the author of this post acknowledges the joke except for you two. It. Is. A. Joke. Calm down. > Just because you made a joke doesn't mean it's inherently immune to criticism No one is arguing that. It's OK that you won't admit that…

Everyone is calm. Many are just tired of you not taking a hint.

Except for those who did not get the joke and felt offended / embarrassed that they didn't and it shows in their replies to me.

It is not my fault if two people missed the joke and that is OK.

Re: Rewriting Bun in Rust

#372

Post by khuey »

egorfine wrote: post #324
malisper wrote: post #130

Earlier quoted context omitted.

I can confirm a naive rewrite won't make things faster. I've been working on rewriting Postgres in Rust. I rewrote things function by function similar to how Jarred did. Even though the new Rust code mapped closely with the previous C code, it was 8x slower. This was due to myriad of reasons. For example naively converting a C union into a Rust enum can be slower because Rust stores a tag with the enum, while C union…

I find it curious that people who take other's people product and rewrite in their favorite programming language still name their own creation the name of the original one. Like, you have now created your own new database engine that happens to be compatible with Postgres. Wouldn't you take an absolute pride in giving it your own name? Why call it "Postgres rewrite in "?

If they did the opposite and called it Mygres or whatever people would give them shit for that too.

Re: Rewriting Bun in Rust

#373

Post by matt_kantor »

Gigachad wrote: post #182
sashank_1509 wrote: post #125

I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow. Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify…

I'm not so pessimistic. There is an infinite amount of work that could be done. No one would have entertained the idea of rewriting a project in Rust before this. It hasn't replaced anyone's actual job and they still had to hire a high paid employee to pull it off. I suspect rather than hire less people we will just produce more code changes.

> No one would have entertained the idea of rewriting a project in Rust before this.

I largely agree with your comment, but is this sentence typo'd or something? "Rewrite it in Rust" happens so often that it's become a meme (and that was so before the rise of agentic coding).

Maybe you meant to say that nobody would have entertained the idea of rewriting this project in Rust?

Re: Rewriting Bun in Rust

#374

Post by ACCount37 »

sisve wrote: post #248
jamesfinlayson wrote: post #192

Earlier quoted context omitted.

Gosh, I don't think any game engines have particularly good test suites at all. GoldSource and Source are the only ones that I have any real experience with and neither seems to have anything (Source may have a handful of things but nothing approaching baseline let alone comprehensive). I have no idea how game devs handle big refactors other than lots of manual testing.

> Gosh, I don't think any game engines have particularly good test suites at all. What? I do understand that a CRUD app with little to no logic do not focus on test. But any kind of engine.. i can not understand that it's not a priority? In general I'm not a big fan of unit test on simple websites, they do not give any real value compared to effort But I remember working on a complex codename. It was extremely import…

Mostly, because a lot of game engines are ancient relics, tracing their lineage all the way back to Quake 1.

The development practices are not exactly up to date, and game development is in no hurry to change. It doesn't help that software development wages there are not at all competitive - game development selects for passion, not skill. People who want to build robust modern codebases and people who want to build AAA games are different people. So there aren't many game devs who want to push for better test coverage.

But it's also because game engines are dealing with many, many things that are hard to test for.

You know how messy it is to test a website for "does this layout look right" or "can you navigate from A to B"? Now multiply that by complex 3D geometry. A lot of what game engines do is dealing with complex 3D geometry, where the primary verification is "does it look right" and "does this interaction feel right". Which is why game development traditionally has wide human QA, and slim unit testing.

Only now do we have software that can sort of, semi-reliably, automate testing for "does it look right".

Re: Rewriting Bun in Rust

#375

Post by ultimaweapon »

MindSpunk wrote: post #172
giancarlostoro wrote: post #50

Earlier quoted context omitted.

I've done rewrites like this, maybe it wasn't Zig to Rust, but I have been able to rewrite sizable projects, from C# to Rust before. I incorporated a similar strategy, have Claude Opus review the codebase, write a spec, then have Claude implement it, while reviewing the spec, and using the codebase as fallback and gospel over the spec. That said, it's not the entire story here as I said, there was a lot of thought pu…

Curious why you'd move from C# to Rust. C# has you covered mostly for memory safety so I would guess performance or lots of shared memory across threads?

Not the author but I also moved from C# to Rust. In the first place I did not consider Rust for C# works like REST API but after I proficient with Rust I no longer want to work with C# for the following reasons:

1. Microsoft don't want to open source .NET Core debugger. 2. I tired of keeping upgrade .NET on my projects. 3. Result type in Rust make me more productive than exception in .NET. 4. async/await in Rust is lightweight and a better than .NET. 5. Thread-safety in Rust is a compiler error instead of figure out by checking the docs if type is thread-safe. 6. Community libraries in Rust has a great quality and docs.

Re: Rewriting Bun in Rust

#376

Post by zamadatix »

WhyNotHugo wrote: post #176

> around $165,000 at API pricing This is the bit I was really curious about. Definitely not something within reach for us mortals.

On the bright side, that price would continue to drop rapidly even if the models themselves never improved anymore. I'd be very surprised if we didn't actually end up with ~100x cost reduction of this task in the next 10 years between hardware improvements, model perf/$ improvements, and commoditization/conpetition.

For now though it is a bit disappointing trying something like this is relegated to project proposals at work rather than my personal hacking.

Re: Rewriting Bun in Rust

#378

Post by 14113 »

steveklabnik wrote: post #188
aw1621107 wrote: post #158

Earlier quoted context omitted.

You can further reduce the difference by passing Expr by pointer in the C version. At that point I think the only difference in the assembly is the order in which the cases are handed.

Ah yeah, honestly both should probably be passed by pointer anyway. But that makes me wonder about the actual differences here and why... maybe something fun to dig into.

Passing by pointer (in C) reduced the difference a lot, but swapping the order of Add and Int in the Rust enum was enough to reduce the different to:

  cmp ecx, 1
  je .LBB0_3
vs

  cmp ecx, 2
  jne .LBB0_2
LBB0_3 and LBBO_2 were the same in both outputs (up to alpha renaming).

Oddly, both sources seemed to be quite sensitive to match switch and enum reordering, resulting in very different generated code. Possibly something to look into further.

Re: Rewriting Bun in Rust

#379

Post by rvz »

steveklabnik wrote: post #6
rvz wrote: post #4

As expected [0] [1], this was a clear advertisement / marketing opportunity of Anthropic's Fable model on rewriting Bun (which powers Claude Code) from Zig into Rust. Something that would have taken hundreds of developers now took 1 developer with Fable. Now Claude, rewrite Claude Code from TypeScript to Rust. Make absolutely zero mistakes. [0] https://news.ycombinator.com/item?id=48073893 [1] https://news.ycombinato…

EDIT: the parent has effectively deleted their original comment > There are a lot of ways to do a terrible job of this. For example, prompting Claude "Rewrite Bun in Rust. Don't make any mistakes." and then praying it would work is not what I did.

> EDIT: the parent has effectively deleted their original comment

Not really and we both know that is not true.

The last line of the comment was the joke. [0] It is clear that you didn't get it and many others did. That is OK.

Heavens forbid anyone here is allowed to make any jokes on this site.

[0] https://news.ycombinator.com/item?id=48839063

Re: Rewriting Bun in Rust

#380

Post by khurs »

user43928 wrote: post #365
duhhhhh1212 wrote: post #202

Earlier quoted context omitted.

What a weird thing to say. The phrase “outsourcing to India” being used as shorthand for “you don’t need top engineers.” The nationality stereotypes are mean and degrading.

Many of the large enterprises we work for did move software engineering work from HCOL locations in Europe or the US to India, often with disastrous results. On Teams, channels related to AI are flooded with daily support requests from supposed engineers from India who clearly are not competent enough to set up GitHub Copilot or properly report issues they encounter during the setup. And don't get me started on the s…

India has amazing software engineers and less competent ones.

USA has amazing software engineers and less competent ones.

Europe has amazing software engineers and less competent ones.

etc

You get what you pay for, pay top end in India and they will be same as top end in Bay Area (and many in Bay Area/USA are migrants...)

Post reply on HN