I can see where you're coming from, but I do think there's a fair amount of meat here. I've never used Zig, but I initially thought of it as pretty similar to other modern languages like Go and Rust, and I liked their allocator approach, but the post gives compelling statistics (Bun has almost EIGHT times as many crash issues as Deno over a similar number of tickets) on Zig's memory safety approach and its issues that also line up with my experience. I used Bun for a small data-collection project, and I liked its performance, but I ran into a lot of issues with it segfaulting (even when just passing a command line argument that was added in the most recent version!). I think that does a good job of motivating OP's argument and how Zig's language semantics directly contribute to these issues.
> the post gives compelling statistics (Bun has almost EIGHT times as many crash issues as Deno over a similar number of tickets) on Zig's memory safety approach and its issues that also line up with my experience.
That's because Zig defers a bunch of checks to runtime that Rust will force you to deal with before it will let you compile at all.
That is a tradeoff. Developer velocity vs memory safety.
Given that Bun seems to be beating Deno on most metrics, it seems like that was the correct choice for Bun.
A segfault is not the program performing a runtime check and doing a controlled shutdown. A segfault is the OS detecting the program doing something it's not allowed to and killing it.
