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

551–560 of 560 posts

Re: Rewriting Bun in Rust

#551

Post by seanjaii »

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

It would be prudent for you to do a little click through of someone’s profile before you make a comment like this next time

Re: Rewriting Bun in Rust

#552

Post by lionkor »

josephg wrote: post #548
lionkor wrote: post #542

Earlier quoted context omitted.

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.

Exactly, yes. I know it's possible, of course it's possible, its just not trivial like it is in C++.

Most developers I have met don't know how to use a profiler, so not sure any of this discussion matters at all anyway, but I feel like it's important to note when the default in Rust is safe, whereas the default in C++ is fast (and more or less unsafe)

Re: Rewriting Bun in Rust

#553

Post by insanitybit »

endospore wrote: post #549
insanitybit wrote: post #544

Earlier quoted context omitted.

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

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

What context? I just said afterwards that aliasing is not one of those cases.

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

Nope and your post wouldn't justify the statement. Not all UB leads to a reachable bug. The blog post doesn't say otherwise, and in fact it indicates exactly this (that UB can compile "correctly" one day and "incorrectly" the next). Check the errata on the post.

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

No, I'm right other than l-unsound. Saying "but safe code that references unsafe code" doesn't change that.

> It's as hard as rewriting the codebase from ground up without reference

Not necessarily. At least multiple cases I've seen in the rewrite would be a matter of just moving `unsafe` from one spot to another and then placing the assertions at the caller.

This conversation is increasingly dumb. I've made my point repeatedly - moving to Rust means memory unsafety violations can be grepped for and that's not up for debate. You can say that that's not sufficient as a win for the project, I really am ambivalent.

Re: Rewriting Bun in Rust

#554

Post by endospore »

insanitybit wrote: post #553
endospore wrote: post #549

Earlier quoted context omitted.

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

> Not these in particular. You are again ignoring the context. What context? I just said afterwards that aliasing is not one of those cases. > Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions: Nope and your post wouldn't justify the statement. Not all UB leads to a reachable bug. The blog post doesn't say otherwise, and in fact it indicates exactly this (that UB c…

> increasingly dumb

That's untrue. It has already been maximally dumb since your first comment with the various logical fallacies you managed to carry out in a single sentence. The only reason I'm still making my replies is that you are making so many false claims that may mislead someone else.

https://doc.rust-lang.org/nomicon/working-with-unsafe.html

I'm not even trying to prove any point since the beginning. Can't do that when you have a different definition of bug from others.

Please if you are going to reply to this ever again try stop making any claims. Otherwise I'm afraid that it will continue into infinity.

Re: Rewriting Bun in Rust

#555

Post by insanitybit »

endospore wrote: post #554
insanitybit wrote: post #553

Earlier quoted context omitted.

> Not these in particular. You are again ignoring the context. What context? I just said afterwards that aliasing is not one of those cases. > Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions: Nope and your post wouldn't justify the statement. Not all UB leads to a reachable bug. The blog post doesn't say otherwise, and in fact it indicates exactly this (that UB c…

> increasingly dumb That's untrue. It has already been maximally dumb since your first comment with the various logical fallacies you managed to carry out in a single sentence. The only reason I'm still making my replies is that you are making so many false claims that may mislead someone else. https://doc.rust-lang.org/nomicon/working-with-unsafe.html I'm not even trying to prove any point since the beginning. Can't…

My claim is that you can grep for memory safety bugs in rust and you can't in zig, therefor trading memory unsafe zig bugs for memory unsafe rust bugs is a good trade. This has been my claim, it continues to be my claim. Linking to the nomicon won't change anything just like linking to the other blog post changed nothing (and you literally misunderstood the other blog post, and I even pointed you to the errata of that post).

Re: Rewriting Bun in Rust

#556

Post by josephg »

lionkor wrote: post #552
josephg wrote: post #548

Earlier quoted context omitted.

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.

Exactly, yes. I know it's possible, of course it's possible, its just not trivial like it is in C++. Most developers I have met don't know how to use a profiler, so not sure any of this discussion matters at all anyway, but I feel like it's important to note when the default in Rust is safe, whereas the default in C++ is fast (and more or less unsafe)

Eh, that argument cuts both ways. Lots of the defaults in C++ are bad. Like, most people don’t know how compiling all your code in a single code unit will improve performance. Or how to do it. In rust it’s a single flag in cargo.toml which is widely talked about. Rust has a much better, faster standard library than C++. Any code which makes heavy use of - for example - sorting in C++ and rust will favour rust because it uses a better algorithm by default.

Rust had the opportunity to iterate on C++’s default choices and improve on them in many cases. I’m not convinced that naive C++ is particularly efficient.

(That said, lots of rust beginners make heavy use of Box and clone() and write inefficient programs that way. It’s hard to actually measure average, beginner code.)

Re: Rewriting Bun in Rust

#557

Post by sitzkrieg »

whytevuhuni wrote: post #494
steveklabnik wrote: post #489

Earlier quoted context omitted.

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.

i was on travel, you addressed my point well. i wish i was on arm, its the exception for me

Re: Rewriting Bun in Rust

#558

Post by afiori »

josephg wrote: post #523
afiori wrote: post #333

Earlier quoted context omitted.

I agree with your point, but for completeness: > How is not having to mark your unsafe code as unsafe a good thing? The problem with unsafe code in Rust is that IIRC nobody actually figured out yet the "rules" of unsafe i.e. which invariants you can stretch and which can cause UB. My (not super up to date) understanding is that this is an active area of research and progress is being made and also that in practice th…

I don’t know what you’re referring to. Unsafe seems pretty well defined for 99% of use cases. Unsafe blocks allow you to dereference raw pointers and call unsafe functions. Thats about it. Remarkably, even in codebases which need a lot of unsafe (eg the kernel), almost all code is safe code.

What I mean is that unsafe code allows you to eg break std invariants (set invalid length to Vec, unlock a locked mutex, etc.) in ways that can be UB, which of these are UB and which can be used "safely" is sort of unknown.

For better or worse they are much more well understood in C as they are front and center of the language semantics

Re: Rewriting Bun in Rust

#559

Post by atonse »

KronisLV wrote: post #287
atonse wrote: post #160

Earlier quoted context omitted.

I’ve wondered the same. Especially because codex is written in rust. Why not just port Claude code over. But my guess is that maybe it doesn’t have as robust a test suite? This might embolden them to do it…

> But my guess is that maybe it doesn’t have as robust a test suite? Not sure about what's going on over there, but over the last year Claude Code has gotten way better, I sure hope that they're working on a good enough test suite to avoid a crapload of regressions (and pave way for more refactoring, should they need it).

Things improved tremendously the first month after they acquired Bun. People like Jared (bun creator) worked relentlessly on the performance bottlenecks, and posted details on X as he worked through them. I remember just launching claude code used to take multiple seconds, and within a month it went down to instant.

Re: Rewriting Bun in Rust

#560

Post by jason_s »

kelnos wrote: post #297
stymaar wrote: post #273

Earlier quoted context omitted.

> 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 depends on what you're comparing it to. It is indeed very slow when compared to a C compiler, or a zig compiler, or even a Java compiler. C++ can be comparable, or slower, or faster, depending on the C++ features used. Sure, maybe rustc's performance compares favorably to how tsc used to be, but that's not the benchmark most Rust developers (such as myself, for more than 10 years now) care about. > a “crate” are j…

Confused here. Are you talking about the execution speed of the compiler's output, or the compilation time itself? Java's compiler is extremely fast, compared to a C compiler. (I haven't used Rust or Zig so I don't have any experience with those.)
Post reply on HN