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

491–500 of 560 posts

Re: Rewriting Bun in Rust

#491

Post by Barrin92 »

pohl wrote: post #415
Barrin92 wrote: post #129

the thing I don't understand about this, given that the goal was a line-by-line transpilation, and the author had already transpiled it once from Go to Zig, why not write an actual transpiler? A problem is as complex as the smallest program required to solve it, and having an LLM, which doesn't produce deterministic output churn through almost 200 grand when you only need to write a deterministic program maybe 5% of…

This is a frequently mentioned criticism. Is there a good argument about why that approach could have been done in the same amount of time? Seems like larger scope and more uncertainty to me.

>Is there a good argument about why that approach could have been done in the same amount of time?

as I said because it's a much smaller codebase. This is a million lines of code project. A literal Zig to Rust translation that is mostly syntactic is not going to be more than 10-20k LOC for a transpiler. That's two orders of magnitude less work.

Re: Rewriting Bun in Rust

#492

Post by zamadatix »

steveklabnik wrote: post #467
zamadatix wrote: post #370

Earlier quoted context omitted.

I'm not sure individual examples is the right way to go about this. A correlation isn't a guarantee for every instance and it's easy to concoct individual examples which tell any story you'd like them to. To properly answer this you'd need to compare a large number of identical implementations written idiomatically in several languages and see if there is a correlation. If I were to throw my 2 cents in I'd say "a ver…

Sure, I did not think that one example is a full survey of all possibilities. I think that it's quite intuitive that this feels right: > it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction Which is why I chose an example of the exact opposite: a language not known for bloat, taking way more code to pro…

I'm not saying it's not as good as a scientific survey, I'm saying it results in no information at all about the strength of correlation one way or the other.

E.g. one could seek to find a 6' preteen and 6' adult to construct a counterexample to the idea height is in some way correlated with age. Doing so gives just as little evidence of what the strength of correlation is as seeking to find a 5'9" preteen and a 6' adult to show the correlation is positive or seeking to find a 6'1" preteen and a 6'0 adult to show the opposite. I.e. it doesn't follow one can filter the search as they please and then assert that's what the correlation of the unfiltered searches should be assumed to look like. In all 3 cases of positively correlated, negatively correlated, and not correlated we'd expect to be able to construct an example which says whatever we want to say - that isn't the same thing as sampling what the actual correlation usually is.

Re: Rewriting Bun in Rust

#493

Post by insanitybit »

endospore wrote: post #490
insanitybit wrote: post #486

Earlier quoted context omitted.

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…

Our standards are different. I don't see any of that as a regression. You're pointing out potential problems that can be resolved, and specifically can be resolved because rust makes those problems grep'able.

From my perspective.

1. 128 known bugs were fixed.

2. 237 potential bugs were made grep'able.

That is a massive win to me.

Re: Rewriting Bun in Rust

#494

Post by whytevuhuni »

steveklabnik wrote: post #489
whytevuhuni wrote: post #487

Earlier quoted context omitted.

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.

> If you don't use panics, you don't get the machinery.

I'm not using panics, and yet I'm getting the machinery. That is where my frustration is coming from.

Re: Rewriting Bun in Rust

#495

Post by endospore »

insanitybit wrote: post #493
endospore wrote: post #490

Earlier quoted context omitted.

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…

Our standards are different. I don't see any of that as a regression. You're pointing out potential problems that can be resolved, and specifically can be resolved because rust makes those problems grep'able. From my perspective. 1. 128 known bugs were fixed. 2. 237 potential bugs were made grep'able. That is a massive win to me.

> made grep'able

That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port. That's what I meant by new problems were created and unique to unsafe Rust in my previous comments, if that wasn't clear enough.

Again I'm not sure if you are intentionally ignoring the context. Please clarify that.

Re: Rewriting Bun in Rust

#496

Post by ksec »

netdur wrote: post #382
ksec wrote: post #292

Earlier quoted context omitted.

I hope Zig won't do a hostile reply to this blog post. But some thoughts on Zig's future where a lot of these problems could be fixed or migrated by better tooling and compiler checking. But a lot of people have been saying this for sometime, Rust and LLM is a great match. A lot of friction of the language were smoothed out by LLM assisted programming.

Zig and Rust solve different problems, Bun got burned by its indiscipline, and Zig’s response was sadly to flood HN with “how to use Zig” articles

I don't want to say I knew it but it did happen. Slightly disappointed.

Re: Rewriting Bun in Rust

#497

Post by NetMageSCW »

zamadatix wrote: post #366
Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

On the other side of the scale, this codebase started in Zig from 5 years ago while the Zig of today is still very much pre-1.0 - still in the middle of things like finishing up moving to a self hosted compiler. Things like binary size, performance, or some of the oddities around drift in the language (like the custom macros vs now built-in language features) in this rewrite are not really as bad as they'd seem if th…

“better safety than Zig while losing compatibility with C” doesn’t seem as compelling a story to me.

Re: Rewriting Bun in Rust

#498

Post by insanitybit »

endospore wrote: post #495
insanitybit wrote: post #493

Earlier quoted context omitted.

Our standards are different. I don't see any of that as a regression. You're pointing out potential problems that can be resolved, and specifically can be resolved because rust makes those problems grep'able. From my perspective. 1. 128 known bugs were fixed. 2. 237 potential bugs were made grep'able. That is a massive win to me.

> made grep'able That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port. That's what I meant by new problems were created and unique to unsafe Rust in my previous comments, if that wasn't clear enough. Again I'm not sure if you are intent…

> They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port.

I'm not sure that this is true - who says that the same invariants weren't broken on the Zig side? (Aliased pointers are UB either way, for example). Also, "unsafe invariant broken" does not strictly mean that there's a reachable bug. It should be cleaned up though, obviously. But in theory, callers may never actually trigger a bad invariant in an unsafe block.

Regardless, even assuming that these are genuinely new bugs, it doesn't change my point. Going from ~X known bugs to ~2X potential, grep'able bugs, is a win to me. Sounds like it isn't to you. Great.

> Again I'm not sure if you are intentionally ignoring the context. Please clarify that.

I'm obviously not intentionally ignoring anything, if you think I am then you can stop responding.

Re: Rewriting Bun in Rust

#499

Post by NetMageSCW »

tapirl wrote: post #119
YuechenLi wrote: post #29

>Combined with the Rust rewrite, ICU changes, and identical code folding, Bun's binary size shrinks by ~20% on Linux & Windows. People who are surprised by this probably has not seen what Zig code actually looks like. Zig's explicitness and lack of abstraction have a real cost that it is basically one of the most verbose programming languages I've ever seen, it's somehow even more verbose than Go. Basic features of m…

Zig is indeed verbose in some aspects, but not overall. For example, its `try error-union` syntax eliminates a lot of boilerplate code. The main reason why Zig is verbose in some aspects is the main goal of Zig is program performance. It is a worthy tradeoff.

That goal doesn’t imply verbosity is necessary- just a style thing which is contrary to its goal of being a better C, given verbosity is the opposite of most C.

Re: Rewriting Bun in Rust

#500

Post by N1H1L »

afry1 wrote: post #429
padjo wrote: post #421

It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this…

Technology does not exist in a vacuum, nor does anything that is engineered. It's not this abstract stuff detached from the world. PEOPLE make stuff, people use stuff, and people are ultimately the ones who are going to pick and choose which stuff gets made, used, adapted, enhanced, and carried into the future. AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that. As…

> AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.

This is a very weird issue to be mad about, and can be extended to multiple technologies - if you think about it, from computers to cellphones.

Post reply on HN