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

351–360 of 560 posts

Re: Rewriting Bun in Rust

#351

Post by karmasimida »

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…

It is possible because they hired the original author of Bun to do this.

It won't be possible to HIRE anyone doing this job confidently, they won't even know if they f*ked up.

I am not too worried anyway, one person with no context, with or without AI, can't do this job. Just like with all the AIs you have, giving you 10 millions, you still can't build a AAA game, it is that simple.

Re: Rewriting Bun in Rust

#352

Post by hvb2 »

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…

> In general I'm not a big fan of unit test on simple websites, they do not give any real value compared to effort

And then your site gets more traction, features are added, things are refactored.

And now you're looking at what used to be a simple site, still with no tests.

It's a habit, that pays off long term. You don't do it for yourself, you do it for who changes the code next. Might be you, or not. Even when you do it yourself, you can't hold all the requirements in you brain, you write those up in tests

Re: Rewriting Bun in Rust

#353

Post by hiq »

ozgrakkurt wrote: post #274
hdjrudni wrote: post #259

Earlier quoted context omitted.

It's only 4% unsafe and most of it is single-line pointers that came from C++ > At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I don't know much about Rust but I imagine this is safer than 100% 'unsafe' code in Zig or…

4% of 100k is 4k. 4k lines of unsafe rust is more likely to be unmanageable compared to 4k lines of zig or c dependency on a 100k line rust codebase. Not sure if they have 100k or a million lines of code

I'm honestly surprised, almost disappointed, that Claude couldn't reduce this 4% to way less.

Re: Rewriting Bun in Rust

#355

Post by msdz »

stymaar wrote: post #340
iainmerrick wrote: post #329

Earlier quoted context omitted.

Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow. The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-c…

> But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow. And yet I'm waiting for TSC every day while almost never thinking about rustc… > The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. It will be very nice, but I don't expect it to be a game cha…

> tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal.

For our small codebases, maybe. The tsc-in-Go announcement had VS Code compilation go from >120 seconds to ten.

Re: Rewriting Bun in Rust

#356

Post by jackdoe »

Sammi wrote: post #298
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…

"In economics, the Jevons paradox is said to occur when technological improvements that increase the efficiency of a resource's use lead to a rise, rather than a fall, in total consumption of that resource. Greater efficiency reduces the amount of the resource needed per application, lowering its effective cost; if demand is sufficiently price elastic, this induces demand, frequently resulting in a net increase of to…

the elastic demand will be consumed by ai

jevon's paradox just says people will consume more software as software gets cheaper, which is likely true, not that there will be more high paid jobs for programmers.

as programmers are not the resource, the program is the resource, programmers were the means of production of said resource.

stated differently: in a world where you dont need programmers to make programs, there is infinity of programs, and no jobs for programmers.

Re: Rewriting Bun in Rust

#357

Post by awson »

I just glanced at it, but in "Rust supports cross-language link-time optimization between C/C++ and Rust" it's not Rust but LLVM.

Any languages with LLVM backends get cross-language LTO for free.

Have they ever tried Zig Bun with LTO?

Re: Rewriting Bun in Rust

#358

Post by psychoslave »

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 "?

Maybe not everyone is utterly obsessed with vanity and its delusion?

Re: Rewriting Bun in Rust

#359

Post by iainmerrick »

msdz wrote: post #355
stymaar wrote: post #340

Earlier quoted context omitted.

> But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow. And yet I'm waiting for TSC every day while almost never thinking about rustc… > The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. It will be very nice, but I don't expect it to be a game cha…

> tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal. For our small codebases, maybe. The tsc-in-Go announcement had VS Code compilation go from >120 seconds to ten .

"Compiling" is vague here; for TS I think you need to distinguish bundling from type-checking.

If you're talking about bundling the entire app, 120 seconds down to 10 seconds is a great saving, but other bundlers can do it much faster already. Most people don't bother using TSC to bundle their code. I can understand why Microsoft might insist on using it, but it's not typical.

For type-checking the entire app, I would see that as akin to running all the unit tests. 120 -> 10 seconds is excellent, but not something that should be a constant bottleneck in your development workflow.

I can definitely see that 10x improvement being crucial on large teams (and/or LLM swarms) where the speed of the CI queue becomes a bottleneck.

Re: Rewriting Bun in Rust

#360

Post by stymaar »

msdz wrote: post #355
stymaar wrote: post #340

Earlier quoted context omitted.

> But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow. And yet I'm waiting for TSC every day while almost never thinking about rustc… > The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. It will be very nice, but I don't expect it to be a game cha…

> tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal. For our small codebases, maybe. The tsc-in-Go announcement had VS Code compilation go from >120 seconds to ten .

Exactly: tsc was “slow enough to be painful” in the context of the 2.5Mloc codebase of VScode.

But it's not too slow for most people.

Likewise, Rust may be slow enough to be painful for some big projects that need to often rebuild from-scratch in release mode, but that niche is definitely much smaller than the size of the “rust compiles too slowly” crowd on HN.

I gave Rust classes in university a few years back, and literally none of my students complained about slow build times. At this point it's much more of an internet meme than an actual pain point for most devs.

Post reply on HN