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

541–550 of 560 posts

Re: Rewriting Bun in Rust

#541

Post by pron »

kanwisher wrote: post #538
pron wrote: post #478

Earlier quoted context omitted.

I should add that in the 30 years I've been a professional software developer, I've worked on and advised many projects. They all ran into serious challenges at one point or another. Not of those projects that was held in high technical regard changed their language (except for things like JS -> TS or when the project planned to change languages, starting with one suitable for prototyping and expecting to switch if a…

likely you never were on a project that had tens of millions of users, you hit different classes of problems and you have to scale to new runtime or language often

(BTW, when I wrote "Not one of those projects ... changed their language", I meant after less than a decade, as a continuation to the previous comment)

First, technically respected products like the ones you describe either 1. plan or expect to switch in advance (e.g. they start with, say, Python/Ruby, expect that if they grow they'll switch to, say, Java) or 2. they improve their chosen language runtime (e.g. Facebook with PHP/Hack or Shopify with Ruby). Projects that switch a language without expecting to always show a pattern of bad decisions (clearly, if they thought their chosen language will carry them through growth and then they're convinced that it won't, that means that they don't know to judge languages' merits).

Second, this is clearly not the situation here, is it? There is absolutely no new information that Bun learnt in the past year that they didn't have five years ago, and certainly this has nothing to do with growing workloads on some service. They say they believe the language they have chosen lacks the features needed for the very core of the domain, which is dealing with JS objects. As someone working on the HotSpot JVM, I can tell you this is not true, but fine - that's what they believe. What could have taken them five years to come to that conclusion? Again, this happens to be a domain close to my own, only much simpler, and I seriously doubt they made some novel discoveries in the past year. And if it's taken them five years to acknowledge what they now think are fundamental limitations with the language they had chosen, how can they be so confident they've made a right choice now after a few weeks? It looks like they chose Zig on a whim and then chose Rust on a whim, and neither of these choices is the source of their problems and neither is the solution to them.

Re: Rewriting Bun in Rust

#542

Post by lionkor »

josephg wrote: post #445
hkalbasi wrote: post #364

Earlier quoted context omitted.

> 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.

Yep. And array bounds checks have a miniscule performance impact at runtime because they're so friendly to branch prediction.

It depends what kind of hot loop you have.

Re: Rewriting Bun in Rust

#543

Post by insanitybit »

endospore wrote: post #536
insanitybit wrote: post #532

Earlier quoted context omitted.

This is going in circles. I think my point has been made. You can grep for every memory safety violation in Rust, that is a win. Pointer aliasing is apparently not UB in Zig, that's cool, assuming that's what you are referring to - but I just can't stress enough how little this matters to my point.

Oh it's so nice of you when I've spent the bottom half of my comment explaining how you cannot grep for most of them in this BAD codebase. Please READ . Including the one I've added at slightly higher layers of replies.

You can grep for every memory safety violation in rust.

Re: Rewriting Bun in Rust

#544

Post by insanitybit »

endospore wrote: post #533
insanitybit wrote: post #498

Earlier quoted context omitted.

> 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.…

There wasn't a reply button on your latest reply so I'm posting here instead. Also because I now have more time to clarify what's exactly wrong about the claims. > who says that the same invariants weren't broken on the Zig side There are no such invariants in Zig. > "unsafe invariant broken" does not strictly mean that there's a reachable bug. Broken invariant literally means you are reaching it. The word you are lo…

> There are no such invariants in Zig.

Zig does have invariants. It doesn't have an aliasing invariant like rust though, but it does have its own invariants, naturally. Zig is a memory unsafe language.

> Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".

A reachable bug means one that can be triggered. Undefined behavior does not mean a bug can be triggered.

> There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.

Can be, yes.

> Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools

This is only possible if unsafe is used. `unsafe` is grep'able, hence all memory safety bugs are grep'able. That's the whole point of rust.

Re: Rewriting Bun in Rust

#545

Post by benced »

AlotOfReading wrote: post #195
benced wrote: post #150

Earlier quoted context omitted.

The scary thing is the zig project prohibits LLM contributions - the world is going to move faster than them.

I would be pissed if my programming language changed as quickly as Claude code does. Languages need to move slowly and carefully, and zig is on the faster end of language development regardless.

I would be mad if the syntax was constantly changing but I want the internal implementation to be moving as fast as possible while retaining success. I think that rate is higher than what humans alone can do.

Re: Rewriting Bun in Rust

#546

Post by AlotOfReading »

benced wrote: post #545
AlotOfReading wrote: post #195

Earlier quoted context omitted.

I would be pissed if my programming language changed as quickly as Claude code does. Languages need to move slowly and carefully, and zig is on the faster end of language development regardless.

I would be mad if the syntax was constantly changing but I want the internal implementation to be moving as fast as possible while retaining success. I think that rate is higher than what humans alone can do.

That's a monkey's paw desire because nowhere is Hyrum's law more true than programming languages. Alternatively you just end up with something like C++ where no one understands the whole thing.

Re: Rewriting Bun in Rust

#547

Post by owebmaster »

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.

"weird" is a euphemism.

Re: Rewriting Bun in Rust

#548

Post by josephg »

lionkor wrote: post #542
josephg wrote: post #445

Earlier quoted context omitted.

Yep. And array bounds checks have a miniscule performance impact at runtime because they're so friendly to branch prediction.

It depends what kind of hot loop you have.

If you have a hot loop where it matters, you can put an assert outside the loop which lets llvm remove the bounds checks. Or use unsafe { get_unchecked() } to remove the bounds check entirely.

Re: Rewriting Bun in Rust

#549

Post by endospore »

insanitybit wrote: post #544
endospore wrote: post #533

Earlier quoted context omitted.

There wasn't a reply button on your latest reply so I'm posting here instead. Also because I now have more time to clarify what's exactly wrong about the claims. > who says that the same invariants weren't broken on the Zig side There are no such invariants in Zig. > "unsafe invariant broken" does not strictly mean that there's a reachable bug. Broken invariant literally means you are reaching it. The word you are lo…

> There are no such invariants in Zig. Zig does have invariants. It doesn't have an aliasing invariant like rust though, but it does have its own invariants, naturally. Zig is a memory unsafe language. > Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness". A reachable bug means one that can be triggered. Undefined behavior does not mean a bug can be triggered. > There's…

> Zig does have invariants

Not these in particular. You are again ignoring the context.

> Undefined behavior does not mean a bug can be triggered.

Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:

https://predr.ag/blog/falsehoods-programmers-believe-about-u...

> `unsafe` is grep'able, hence all memory safety bugs are grep'able.

Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".

No. Even assuming everything is done idiomatically, memory safety bugs can still originate from unsafe blocks and all the safe functions in the same module. So we want the module containing unsafe to be small and closed. Otoh with this code base unsafe lives in every module.

Making them encapsulated is the whole point of Rust, in this code nothing is encapsulated so no, they missed the whole point of it.

Aaand it's not like you can just remove the unsafe blocks one by one trivially. It's as hard as rewriting the codebase from ground up without reference (unlike the current migration) as every referenced object in the call graph needs to be reordered. Well partly because the original code sucks I assume.

Re: Rewriting Bun in Rust

#550

Post by stymaar »

DoesntMatter22 wrote: post #508
stymaar wrote: post #360

Earlier quoted context omitted.

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…

Small apps in college are much different than huge apps in the real world

Most people complaining about Rust being slow have never worked on anything close to a production app written in Rust.

By the way, for most apps, rhe difference from an app we'd write in class is not as nearly as big as you'd expect: most of the code lies within dependencies anyway, and you need roughly the same amount of them in both cases.

Of course there are exceptions, apps that are tens of millions of LoCs exist, but it's not the majority.

(And they tend to be naturally split in multiple crates, which is the default workaround if a rust project takes too much time to compile).

Post reply on HN