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

531–540 of 560 posts

Re: Rewriting Bun in Rust

#531

Post by frizlab »

pjmlp wrote: post #527
frizlab wrote: post #151

Earlier quoted context omitted.

My personal memory and concurrent-safe option is Swift. And I agree, choosing a non-memory safe language for a new project is close to irresponsible today…

Sometimes we have no option, given the industry standards that expect C or C++. Khronos, Open Group, NVidia, Microsoft, Sony, Nintendo... aren't going to change their APIs and SDKs, just because of social media discussions on the merits of C, C++ vs other safer alternatives. I agree we should minimise their use, however not everyone accepts a dual language approach, nor there are alternatives in such domains, even if…

Obviously my comment of irresponsibility was “given that there is a choice.”

Though that’s one nice thing about Swift: it has a very good interop’ with C now, and a “starting to get pretty good” interop’ with C++. So that can help, sometimes. (Obviously, I reiterate, I understand there are situations where the choice is just not possible, and enhancing C and C++ is indeed a good thing.)

Re: Rewriting Bun in Rust

#532

Post by insanitybit »

endospore wrote: post #516
insanitybit wrote: post #515

Earlier quoted context omitted.

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

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.

Re: Rewriting Bun in Rust

#533

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

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 looking for is "unsoundness".

> callers may never actually trigger a bad invariant in an unsafe block.

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.

> potential, grep'able bugs

We are indeed going in circles but I have to ask: you still don't understand that? Grep works for violated lints, unsafe blocks and all things explicitly exist in the code. Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools. They also have thousands of those. It's unfair to say the unsoundness is freshly introduced by the port, but Rust also doesn't help in this way where no unsafety is encapsulated and calling anything can be a wild ride.

Re: Rewriting Bun in Rust

#534

Post by pjmlp »

frizlab wrote: post #531
pjmlp wrote: post #527

Earlier quoted context omitted.

Sometimes we have no option, given the industry standards that expect C or C++. Khronos, Open Group, NVidia, Microsoft, Sony, Nintendo... aren't going to change their APIs and SDKs, just because of social media discussions on the merits of C, C++ vs other safer alternatives. I agree we should minimise their use, however not everyone accepts a dual language approach, nor there are alternatives in such domains, even if…

Obviously my comment of irresponsibility was “given that there is a choice.” Though that’s one nice thing about Swift: it has a very good interop’ with C now, and a “starting to get pretty good” interop’ with C++. So that can help, sometimes. (Obviously, I reiterate, I understand there are situations where the choice is just not possible, and enhancing C and C++ is indeed a good thing.)

The nice thing about Swift, or Java/Kotlin on Android, is the platform owner attitude, either adopt it, or go elsewhere, that is the only way safety improvements are pushed into mainstream.

Re: Rewriting Bun in Rust

#536

Post by endospore »

insanitybit wrote: post #532
endospore wrote: post #516

Earlier quoted context omitted.

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

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.

Re: Rewriting Bun in Rust

#537

Post by josephg »

yukIttEft wrote: post #267
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++.

Is it though. There are so many situations where something is guaranteed to be safe but there is no way to express that in the Rust typesystem, so the only thing you can do is to wrap everything in Arcs and Mutexes, which introduces allocations, pointerchasing and locks

I said rust is just as fast as C++. Not safe rust. Use unsafe where it’s appropriate, obviously.

Re: Rewriting Bun in Rust

#538

Post by kanwisher »

pron wrote: post #478
pron wrote: post #431

Sounds to me like his choice of Zig was made in haste, as was his choice of Rust. If you find yourself changing a project's primary language more than once a decade (more like 15 years, but let's say a decade), the problem isn't the language but your technical decision process, and that's what you should look into first. Some of the world's more important software - from browsers to the JVM - mix high-level languages…

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

Re: Rewriting Bun in Rust

#539

Post by tapirl »

NetMageSCW wrote: post #499
tapirl wrote: post #119

Earlier quoted context omitted.

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.

Performance alone doesn't always imply verbosity, but combining it with other goals—such as increased security and more power std APIs—often does.

Re: Rewriting Bun in Rust

#540

Post by leecommamichael »

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

Speaking as someone who has also given courses at university teaching a programming language (Swift,) the students also do not know how fast computers are and that when their brand new super-computer lags and hitches for full seconds while coding it's pretty much "working as expected" to them. I haven't written Rust in a few years, but I remember it being remarkably similar to Swift both in API design ergonomics and compiler quality. I am open to this having changed, and I can appreciate @stymaar's frustration if it has done so drastically.
Post reply on HN