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

481–490 of 560 posts

Re: Rewriting Bun in Rust

#481

Post by insanitybit »

endospore wrote: post #456
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…

Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust. And no, since they don't know they don't know about it, there are no signs of fixes around these real issues. They had posted something about the unsafe usage, but lol most of the UBs are casually swep…

As opposed to the known problems caused by using Zig?

Re: Rewriting Bun in Rust

#482

Post by endospore »

insanitybit wrote: post #481
endospore wrote: post #456

Earlier quoted context omitted.

Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust. And no, since they don't know they don't know about it, there are no signs of fixes around these real issues. They had posted something about the unsafe usage, but lol most of the UBs are casually swep…

As opposed to the known problems caused by using Zig?

Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.

Re: Rewriting Bun in Rust

#483

Post by vaidhy »

karatchov wrote: post #413
solid_fuel wrote: post #205

Earlier quoted context omitted.

Ehh, I think this take needs a grain of salt. There's a few significant facts here: - They had an existing functional Zig implementation - They had an existing test suite for the Zip implementation - They had a separate JavaScript compliance test suite with ~ 1 million tests - The person overseeing the rewrite was responsible for a huge portion of the existing codebase and was very familiar with the existing architec…

You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job ! and btw, if it can write code, it can write tests and test suite Ai has come a long way, 2 years ago, t…

I am also very curious what the actual cost of this is, esp. if you are not an Anthropic employee and have to pay the API cost.

Re: Rewriting Bun in Rust

#484

Post by j16sdiz »

tclancy wrote: post #212
piskov wrote: post #121

Earlier quoted context omitted.

Unless you hire smart people from EU and what have you (especially ex-USSR) Which takes us to a point of future US dev salaries if this thing with agents gets better more and more

Sure, but can we not work out how to make humans more efficient for less money? There are obvious optimizations there that none of us would like to be part of.

Less money? Cost of living is much lower in EU

Re: Rewriting Bun in Rust

#486

Post by insanitybit »

endospore wrote: post #482
insanitybit wrote: post #481

Earlier quoted context omitted.

As opposed to the known problems caused by using Zig?

Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.

So there were 128 known problems fixed and you've found 237 potential bugs that were greppable. And you think that's a regression?

Re: Rewriting Bun in Rust

#487

Post by whytevuhuni »

steveklabnik wrote: post #465
whytevuhuni wrote: post #252

Earlier quoted context omitted.

I tried to use Rust for a tiny microcontroller (GD32VF103, 128KB flash). First of all, I was amazed by how much I could do with Rust ( safe Rust, even), and how well it was interfacing with my handwritten RISC-V assembly. I will definitely use Rust again for the next such project. But, every time my functions would get over a certain size, suddenly some optimizations stopped working, and Rust was trying to put the wh…

I don't disagree that I think that the Rust project could do more to make this kind of development easier, and it is true that it doesn't come for free. That doesn't change the point that if you want to, you can do it, it is not a fundamental language limitation.

It is a fundamental language limitation, unless you want to claim that the core library (or rather what's left when using no_std) is not part of the language.

The problem comes from a combination of three things:

1. Rust's standard library (including core) likes to panic a lot, e.g. for code that is genuinely unreachable (and this is fine)

2. Rust/LLVM cannot always optimize unreachable code away (and this is also fine)

3. The presence of at least one panic causes Rust to also include the error string format machinery, which is HUGE (and this is completely unavoidable)

Because of #2, there is no way to prevent this for larger code. I can define my own panic handler, but I can't prevent panic!() calls from inside core from constructing the format message using core::fmt before they call my panic handler.

And so any non-trivial code sometimes just randomly becomes 3x larger, and I can no longer fit it on my MCU, despite never actually printing or caring about any panic messages.

Re: Rewriting Bun in Rust

#488

Post by pjmlp »

IshKebab wrote: post #476
pjmlp wrote: post #457

Earlier quoted context omitted.

Yeah but compiling full Unreal from scratch already requires going down the path of forking it for own purposes. Same applies to most commercial libraries, where code is usually provided for debugging purposes, not for building everything from scratch. Also incremental linking on Rust, or hot code reloading is still not something that works out of the box. How beefy is that machine to achieve 2m20? I started using C+…

> How beefy is that machine to achieve 2m20? Ryzen 9 3950X (16 core). I think it was top of the line 5 or 6 years ago but it only cost me about £300 second hand for the whole PC (with 128 GB RAM - before the RAMpocalypse!) Definitely not a crazy machine. > I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD Yeah, I mean early C++ was quite a lot simpler than modern C++23! Of course it's goi…

Yes, but no one needs to use C++23 to the full extent to stress test the compiler in -O3, or go crazy with compile time execution.

While I could comfortably still develop C++ in a Asus 1215B netbook with 8 GB and SSD, thanks to all the native libraries I could install, and make use via pkgconfig, the same could not be said to play around with Rust on the same netbook.

This matters, because not everyone can afford top of the line desktops, especially in 2nd and 3rd level countries, which then plays a role in language adoption.

Some even make do with what they can run on tablets.

Re: Rewriting Bun in Rust

#489

Post by steveklabnik »

whytevuhuni wrote: post #487
steveklabnik wrote: post #465

Earlier quoted context omitted.

I don't disagree that I think that the Rust project could do more to make this kind of development easier, and it is true that it doesn't come for free. That doesn't change the point that if you want to, you can do it, it is not a fundamental language limitation.

It is a fundamental language limitation, unless you want to claim that the core library (or rather what's left when using no_std) is not part of the language. The problem comes from a combination of three things: 1. Rust's standard library (including core) likes to panic a lot, e.g. for code that is genuinely unreachable (and this is fine) 2. Rust/LLVM cannot always optimize unreachable code away (and this is also fi…

I think we just disagree about what "fundamental" means. If you don't use panics, you don't get the machinery. This means it's not fundamental.

What you're talking about is the ease of which you can not include the panic machinery. I agree that it is not always easy to keep out, and that I would like if it were to be made easier.

But people are doing real, commercial projects on MCUs your size and smaller.

Re: Rewriting Bun in Rust

#490

Post by endospore »

insanitybit wrote: post #486
endospore wrote: post #482

Earlier quoted context omitted.

Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.

So there were 128 known problems fixed and you've found 237 potential bugs that were greppable . And you think that's a regression?

Can't assume good faith in you at this point but I'll explain it.

- They've written two articles, one by claude doing the migration another by the human behind it, neither acknowledge these problems. Nor does the incorrect SAFETY comments in code.

- I only spent ten minutes and found two code patterns that are wrong with little exceptions. Also randomly checked a few samples and there was no exception. This basically means that failure patterns not explicitly picked and disallowed will repeat themselves over and over. Try imagine the more subtle ones hiding in this huge codebase.

- Trivial to find != Trivial to fix. 107 of the problems (one of the categories) are borrow issue and requires large refactoring (rearrange and rethink whole modules of code) to be removed completely.

So yes, huge regression by my standards. And I'm not questioning Rust the language. I'm questioning Claude, Jarred the person, their dev & marketing practice and the Bun project.

Btw these categories are separate from the (still unfixed) category of problems I mentioned 54 days ago in the comments before.

Post reply on HN