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.

Someone could know what memory safety is and still be persuaded (or reminded) by an argument that it's not okay to adopt a non-memory-safe language due to all the security issues. The author did cite evidence from the Chromium project, which to me elevates it above a mere rant.

my point with memory safety is that it is not a single well defined concept

so if you wanna talk about it you at least gotta say which definition you're using