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

511–520 of 560 posts

Re: Rewriting Bun in Rust

#511

Post by pdimitar »

henry_bone wrote: post #506
pdimitar wrote: post #504

Earlier quoted context omitted.

Of all the things I expected to read today on HN, "I chose a programming language that appeals to my political leanings" was certainly not one of them.

With the use of quotes there, you've put those words in my mouth. I didn't say that. What I am trying to express with the statement you refer to is that zig appeals to me on an aesthetic level. It suits my tastes. I mentioned liberty because I appreciate that zig allows me to have complete control of memory allocations, and gives me quite a deal of control over the metal. I like this and I like that I don't have to a…

With respect, it's difficult to interpret "libertarian sensiblities" as something else than "political leanings". Now "liberal" is a much more general -- I wouldn't necessarily call that political -- but what you said had a strong political connotation, hence my comment.

Your explanation lands otherwise. I can't relate to "I don't have to appease a borrow checker" though. That reads like a deliberately uncharitable read of what Rust's compiler is doing. That being said, it's definitely not for everyone.

I tried Zig. Loved it. But then after a few weekends I said to myself: "Wait a bit. I've been down this path before with C and C++. I know exactly where it ends." -- and bailed.

To me these days low-level programming is basically: either go all the way, or don't go at all. Sadly Rust is not like, going really all the way, but it's IMO the closest we got. And before somebody starts enumerating obscure languages that barely have a community: I include multi-axial evaluation here i.e. PL features, stdlib, ecosystem, richness of education (Rust has _a lot_ of good books and courses), and others I am surely forgetting at the moment.

Zig is great. But I'll not take marginal improvements anymore. Not in my personal life and not in my work. I'll get big ones, or not get them.

Since we are explaining philosophies, now without political undertones: that's mine.

Re: Rewriting Bun in Rust

#512

Post by deterministic »

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…

I am seeing the complete opposite. 200k senior engineers can now do large scale projects way beyond what they could do just a year ago. My company is now able to implement stuff that we used to only dream about. Having 200k senior engineers who master AI coding is a true super power.

Re: Rewriting Bun in Rust

#513

Post by endospore »

insanitybit wrote: post #498
endospore wrote: post #495

Earlier quoted context omitted.

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

Yes you are. Either that or you are too distracted to read or you wouldn't be repeating

> ~2X potential

at this point. That's what I've found in 10 minutes. And they are actual bugs that I've take extra time to (statistically) verify. Please worship me as the new machine god if you think I've found all the bugs with a glance.

And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.

Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.

Re: Rewriting Bun in Rust

#514

Post by deterministic »

jackdoe wrote: post #356
Sammi wrote: post #298

Earlier quoted context omitted.

"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, ther…

Sorry, but I don't think you understand how many different skills are involved in building software that large companies can actually rely on.

Writing code is only one part of the job. I use Claude Code every day and I love it. It has made me much more productive. But I still have to guide it carefully, review every change, and fix the bugs and poor design decisions it introduces.

Personally, I'm looking forward to retirement. I expect there will be no shortage of consulting work helping companies clean up the AI-generated mess generated by inexperienced developers and overconfident middle manager with zero software development experience :)

Re: Rewriting Bun in Rust

#515

Post by insanitybit »

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

Yes you are. Either that or you are too distracted to read or you wouldn't be repeating > ~2X potential at this point. That's what I've found in 10 minutes. And they are actual bugs that I've take extra time to (statistically) verify. Please worship me as the new machine god if you think I've found all the bugs with a glance. And I'm not going to debunk each of your false claims, when you are doing that at the expens…

> And they are actual bugs that I've take extra time to (statistically) verify.

I'm confused. You said that you've just grepped and found some undefined behavior. What do you mean that you've statistically verified them?

> And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.

My false claims? Like that pointer aliasing is undefined behavior in both languages? lol okay?

> Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.

I'm taking all of your claims at face value, I haven't said that you have to provide evidence of them. I'm not saying that your claims are false, I'm saying that I can grant them and still disagree with you.

I don't know what to tell you. Even if you said that those 2x bugs were 100% verified, I'd still say that this is a win because you can grep for these bugs now. That is obviously better to me.

Re: Rewriting Bun in Rust

#516

Post by endospore »

insanitybit wrote: post #515
endospore wrote: post #513

Earlier quoted context omitted.

Yes you are. Either that or you are too distracted to read or you wouldn't be repeating > ~2X potential at this point. That's what I've found in 10 minutes. And they are actual bugs that I've take extra time to (statistically) verify. Please worship me as the new machine god if you think I've found all the bugs with a glance. And I'm not going to debunk each of your false claims, when you are doing that at the expens…

> And they are actual bugs that I've take extra time to (statistically) verify. I'm confused. You said that you've just grepped and found some undefined behavior. What do you mean that you've statistically verified them? > And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism. My false claims? Like that pointe…

Instead of "possible" undefined behaviors, potential bugs, the samples I've randomly picked are all actual undefined behaviors, real bugs. Hence statistically.

> pointer aliasing is undefined behavior in both languages

That included and also basically every other claim in that comment. I'd be happy to learn otherwise if you have concrete evidence.

[Edit: erased information that can help people find the bugs without prior knowledge]

> I haven't said that you have to provide evidence of them

Sure, but if I'm going to it would be a lot easier to convince everyone how bad it is (just like I did in private message groups). I can't take the risk that "everyone" also includes Jarred though.

> you can grep for these bugs now

You can grep for the greppable new bugs. I raised them as an argument because these issues are glaring. What about the ungreppable ones? More than half (again, randomly sampled) unsafe usage in the 10,413 unsafe blocks in current Bun looks iffy to me. I just haven't taken the time to verify them because many requires reasoning across the code base (see? the exact problem Rust ought to prevent). From a Rust point of view it's a huge failure.

All these while considering that the Bun agents (no people at this point I'm afraid) don't even know how to grep for the easy ones.

Re: Rewriting Bun in Rust

#517

Post by vrighter »

stymaar wrote: post #273
leecommamichael wrote: post #113

Earlier quoted context omitted.

> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any add…

> The rust compiler is very slow. It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it. > The best w…

it is insanely slow. I regularly need to wait for minutes just for the final crate to compile when compiling some tui program from scratch

Re: Rewriting Bun in Rust

#518

Post by vlovich123 »

Rohansi wrote: post #510
vlovich123 wrote: post #501

Earlier quoted context omitted.

Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger. Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on. C…

> only work on Windows with Visual Studio Really shouldn't be a dealbreaker when 95% of your users will be using Windows (to play games), so your most tested platform should be Windows. > when you started it under a debugger Hot reload isn't a replacement for scripting IMO. It will never be as good. Even hot reload in Rust would have more limitations than an actual scripting language.

Sure, that doesn't take away from the experience of Rust being better than C++ even if you probably still want a scripting language too.

In total Microsoft only holds ~12% of the total video game market share across PC and console in terms of owning the platform (i.e. Xbox + Windows). I think you're overestimating how many game developers get to use reverse debugging for gaming. In practice given the limitations for Visual Studio's implementation, I highly suspect that number is very rarely used anyway.

Re: Rewriting Bun in Rust

#519

Post by psychoslave »

egorfine wrote: post #474
psychoslave wrote: post #358

Earlier quoted context omitted.

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

Then why use someone else's established brand for your toy project?

If this is still speaking about the Postgres rewrite in Rust, then naming it something like pgrust[1] makes sense for ease of discovery for anyone aware of these technologies.

[1] https://github.com/malisper/pgrust I guess

Re: Rewriting Bun in Rust

#520

Post by comex »

baq wrote: post #301
comex wrote: post #222

Earlier quoted context omitted.

The forbidding of circular dependencies is exactly what makes it hard to achieve parallelism! It means you have to draw nice clean module boundaries and split your compilation units there. Clean boundaries sound nice, except… what if the module is getting large? Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors? In C, usually…

The industry accepted way of handling circular dependencies is to not have them and heavily lint against them in languages which permit them in compilation or runtime.

You’re thinking at the wrong scale. Rust allows circular dependencies just fine, within modules in a crate. And it’s extremely common for modules within a crate to have at least some circular dependencies - type X has some method (trait impl of inherent impl) that mentions type Y, and type Y has some method that mentions type X. In fact, I would be surprised if you could name me a single medium-size-or-larger popular crate that doesn’t have at least one cyclic reference between modules! Though, sometimes those cycles are not essential and could be avoided by splitting up modules. But sometimes they are. Either way, in C or C++ those modules would probably be their own compilation units.

That said, you also run into related parallelism blockers without cycles. For example, the orphan rules force most trait impls for a type to be in the same crate as the type definition. Also, a module which has no source-level cycles will often have cycles after monomorphization. In this case, Rust doesn’t prevent you from splitting the code into crates like it does with source-level cycles, but you do lose most of the actual codegen parallelization unless you can switch from generics to trait objects.

Post reply on HN