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

361–370 of 560 posts

Re: Rewriting Bun in Rust

#361

Post by zamadatix »

pier25 wrote: post #190
alexjurkiewicz wrote: post #166

Earlier quoted context omitted.

Paying customers get LTS. Are any paying customers asking for a Zig branch LTS? Or are you expecting open source maintainers to do free work for no particular reason?

Java, Node, and .NET have LTS versions all of which are free to use. > Or are you expecting open source maintainers to do free work for no particular reason? Free work? Last I heard Anthropic had acquired Bun.

Getting to an LTS release train of bun is probably a good idea, assuming they are still interested in external adoption rates. They shipped 1.0 a little under 3 years ago and the acquisition has had ~6 months to get settled. Looking at an LTS release would enable a lot of the more slower moving places to look at bun within being worried about getting caught up in the velocity.

I don't know it makes sense to try to make the an LTS version of where the Zig version left off, particularly if they know they are shipping a different solution & codebase to tackle the bulk of their security and memory bugs. Let this settle a few more months with the intent of releasing an LTS of it by the end of the year, if there really is demand for it. All of the benefits of having an LTS version like Java, Node, and .NET without needing to jump to a pre-port version of the codebase which was never targeted to be a good version to LTS in the first place.

A final Zig-based LTS would have made great sense if LTS releases had already been in the picture though.

Re: Rewriting Bun in Rust

#362

Post by khuey »

flohofwoe wrote: post #280
kibwen wrote: post #164

Earlier quoted context omitted.

> There are so many language features that there's memes about it. Like many memes, these are misleading. Rust is a solidly medium-sized language; smaller than Python, certainly, though with a perilously steeper learning curve than Python.

Rust-the-language may be medium-sized. Rust-the-stdlib though? The Rust stdlib has a lot of essential low-level types needed for adding a 'semantic layer' on top of the language so that the language user can exactly 'express intent' (types that arguably should be language features instead). Just look at all those detailed methods needed to make RefCell work, and what does 'into_inner' or 'undo_leak' even mean? https:…

> what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust

That "the pointer" is a single concept in C is the root cause of absurd numbers of bugs over the history of C.

The questions of how long the memory a pointer points to lives, what threads it is safe to access from, and how it is allocated and destroyed all still exist in C. Those answers are just implicit rather than explicit like they are in Rust. It's not like Python/etc where you don't have to worry about these things.

Re: Rewriting Bun in Rust

#363

Post by KronisLV »

KronisLV wrote: post #249
zamalek wrote: post #138

Earlier quoted context omitted.

Game engines are typically in two languages, one for the engine itself and one for scripting. That even goes for Unity: in Unity, C# is a significantly more powerful than average scripting language (for lack of a better term), but the engine itself is still C++. That's not to say that you couldn't write a commercial game engine with something like C# that stands shoulder-to-shoulder with unity and unreal, but it does…

> That's not to say that you couldn't write a commercial game engine with something like C# that stands shoulder-to-shoulder with unity and unreal, but it doesn't seem like anyone has attempted to do so. Stride should mostly fit the bill: https://github.com/stride3d/stride Their homepage: https://www.stride3d.net/ Even the physics engine they use is in C#: https://github.com/bepu/bepuphysics2 Not a very popular game…

> It’s up there with Stride

Edit: I mean that it's up there with Flax: https://flaxengine.com/ whoops

Stride, Flax and jMonkeyEngine are all pretty cool, not just Godot and O3DE!

Re: Rewriting Bun in Rust

#364

Post by hkalbasi »

lionkor wrote: post #241
josephg wrote: post #204

Earlier quoted context omitted.

> I can understand when you need the absolute best performance and you decide to drop to down to C++ Rust is just as fast as C++.

It depends just how fast you need it. C++ is much easier to get to zero abstraction code. In Rust you are constantly fighting the stdlib and other libraries, and you have to litter your hot code with unsafe blocks to get it to stop adding a branch to nearly every object access, be it for bounds checks or over/underflow checks. C++ does a much better job at giving you a zero abstraction API, and you can always drop do…

> over/underflow checks.

Integer overflows are not checked in release builds by default, since they are not related to memory safety.

On the other hand, rust emits noalias everywhere, which helps in autovectorization.

Re: Rewriting Bun in Rust

#365

Post by user43928 »

duhhhhh1212 wrote: post #202
simonw wrote: post #180

Earlier quoted context omitted.

Have you seen the "rewrite by outsourcing to India" thing work?

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 shared libraries some teams located in India work on. If the library I need to use is full of obvious bugs where I wonder how any competent engineer could have shipped this to production, and then I see that the work has been moved to India, how am I supposed to feel about this?

Do we really need to sugarcoat this?

Re: Rewriting Bun in Rust

#366

Post by zamadatix »

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 this was a port from a more complete language.

That said, I think the parts around wanting to properly have memory safety guarantees rather than try hard & patch as issues are found is a more serious concern for Zig as those speak more to the design goals than the current implementation. "better safety than C while maintaining C compatibility" may not be a very compelling reason to chose Zig if other languages are able to do that portion better anyways, even ones without a GC.

Re: Rewriting Bun in Rust

#367

Post by rvz »

simianwords wrote: post #237
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…

Its not even that, its one of the most overdone jokes as your link suggests.

In your "opinion". So are you going to stop people from making "overdone" jokes on this site or others using variations of it from now on? Or is it only mine?

My link suggests that is it just a joke and it is fine if you do not get it.

Re: Rewriting Bun in Rust

#368

Post by xiaoyu2006 »

didibus wrote: post #80

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…

Ownership is a very limiting coding constraint, and bypassing methods, when ultimately needed (e.g. cell), cannot be engineered to be ergonomical.

Re: Rewriting Bun in Rust

#369

Post by muragekibicho »

stymaar wrote: post #323
MobiusHorizons wrote: post #296

Earlier quoted context omitted.

Why do you think it is not slow? As far as I know the only language that compiles slower is C++, and even then the compilation speeds between c++ and rust seem to be comparable. I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. That makes rust pretty slow in my book. I get that it doesn’t bother everyone, but that doesn’t change the facts.

> Why do you think it is not slow? The average cargo check for the projects I've worked on, usually finish in less than 1 second, with `cargo build` completing in a single digit second (often below 2s), it's not slow by any means. > I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. Sure, but the difference between type checking is 10ms and type checking in 500ms is barely noticeable f…

Compiling my C code with gcc happens in a single eye blink. Changing the format to .cpp and compiling with g++ takes 5 eye blinks. I've never used rust and I can't imagine blinking more than 6 times while waiting for my code to compile.

Re: Rewriting Bun in Rust

#370

Post by zamadatix »

steveklabnik wrote: post #51
benced wrote: post #35

Earlier quoted context omitted.

Not a compiler expert - shouldn't language verbosity and binary size be, at best, very loosely related?

I don't think you can draw the conclusion that source length and binary size are correlated. For example, in Rust: #[derive(Copy, Clone)] enum Expr { Int(i32), Add(i32, i32), Neg(i32), } fn eval(expr: Expr) -> i32 { match expr { Expr::Int(x) => x, Expr::Add(a, b) => a + b, Expr::Neg(x) => -x, } } Rust's enums can carry data. You can write the same thing in C, but because it does not have the enum feature, you have to…

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 very weak correlation" is probably right. Not because verbose languages HAVE to result in more bloated code but because 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 never does seem to actually compile away fully in large projects, even though it often largely does).

Post reply on HN