6 ms·
This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state. Whether it be kernel exception, pointer exception
by reactordev 11mo ago
This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state. Whether it be kernel exception, pointer exception, or Rust's panic! - these things exist.
The reason why you see so many GitHub issues about it is because that's where the development is. Deno is great. Bun is great. These two things can both be great and we don't have to choose sides. Deno has it's use case. Bun has it's. Deno want's to be secure and require permissions. Bun just wants to make clean, simple, projects. This fight between Rust vs The World is getting old. Rust isn't any "safer" when Deno can panic too.
- skipants 11mo agoI agree. Pointing at Github issues is a strange metric to me. If we want to use that as a canary then you shouldn't use Deno (2.4k open issues) or Bun (4.5k open issues) at all.
- satvikpendem 11mo agoDon't make a false equivalence, how many times does one get a panic from Deno versus a segmentation fault in Bun? It's not a similar number, and it's simply wrong to say that both are just as unsafe when that's plainly untrue.
- ricardobeat 11mo agoAnecodtally? Zero segfaults with bun since I started using it back in beta.
- satvikpendem 11mo agoI'm talking statistically in terms of number of issues that reference segmentation faults in the Bun vs Deno GitHub repositories. Anecdata doesn't mean much.
- reactordev 11mo agoThe only time I got a segfault in Bun is when I used bun:ffi to wrap glfw and wgpu-native so I can threejs on the desktop. Ironically, the segfault was in wgpu. Which is Rust. But to be fair it was because the glfw surface had dirty flags for OpenGL and didn’t have the Vulkan extensions. So anyone would have faulted.
- hu3 11mo agoI use Bun in production. Well, one of my clients. We have yet to witness a segfault. Admitedly it's a bunch of micro services and not many requests/s (around 5k AVG).
- diarrhea 11mo ago> This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state. There are degrees to this though. A panic + unwind in Rust is clean and _safe_, thus preferable to segfaults. Java and Go are another similar example. Only in the latter can races on multi-word data structures lead to "arbitrary memory corruption" [1]. Even in those GC languages there's degrees to memory safety. 1: https://go.dev/ref/mem https://go.dev/ref/mem
- drannex 11mo agoI'll take a small panic and unwind any day over a total burnout crash. Matters in code and life.
- ignoramous 11mo ago> A panic + unwind in Rust is clean and _safe_, thus preferable to segfaults Curious about safety here: Are kernel / cross-thread resources (ex: a mutex/futex/fd) released on unwind (assuming the stack being unwound acquired those)?
- diarrhea 11mo agoGood question. For fds their Drop implementation closes them, yes. Rust Mutexes will be poisoned on panic (not unlocked). Not sure about futexes.
- reactordev 11mo agoBut if Rust panic’s, the entire process is dead, so everything gets reclaimed on exit by the kernel. Total annihilation. All modern OS’s behave this way. When your process starts and is assigned an address, you get an area. It can balloon but it starts somewhere. When the process ends, that area is reclaimed.
- diarrhea 11mo agoThe OS is my GC. It's why I segfault liberally.