> Just search "segfault" on the Zig issue tracker and you'll see why people are starting to be skeptical of the future utility of such a language in the face of something like Rust.

Zig has 110 open "segfault" issues [1] versus Rust's 175 open "segfault" issues [2]. So, by your logic, Rust is also bad.

edit: I was just trying to point out that the parent's "just search segfault" argument is lazy. Also, Zig is still in beta.

[1] https://codeberg.org/ziglang/zig/issues?state=open&type=all&...

[2] https://github.com/rust-lang/rust/issues?q=is%3Aissue%20stat...

I program C for my day-job.

I see Rust encroaching in proposed transitions. It may even happen. That said, it is a poor match for it compared to something like Zig (or Odin). It's hard to make the new Rust code use existing allocator abstractions (so now you have two systems doling out memory, how do you reliably free composite objects with memory from both? How do they share?) and you increasingly have to either abandon any actual benefits of the borrow-checker, or invest increasingly heavily into sufficiently fat bindings to wrap your existing C/C++ in a way where the borrow-checker can assist you. That's before we consider the complexity of the language - I'd doubt a seasoned C programmer has much trouble deciphering Zig or Odin FFI bindings, but in the case of Rust? Yes, there is real friction.

Also if you really value predictable- and higher performance, being in more in control of memory allocations and cleanup is preferable. This is the direction both Zig and Odin cater to.

If you asked me what solves the most issues without adding too many new liabilities, I'd say Zig (or Odin). It would simply be much, much easier to transition a C codebase to either, and either would bring a much improved stdlib with pluggable allocators capable of leak-detection etc.

> So they decided to start with just a transliteration and go from there.

Huge problem with this is that typically safe, idiomatic Rust looks nothing like unsafe Rust.

> the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C

I don't think anyone who actually uses zig thinks "it doesn't offer enough over C". Removing #define alone would have been worth it.

I would say the flagship Zig project is TigerBeetle, not Bun.

I used to think there's a good niche for "better C" - and that Zig was the one language angling for that. A language that can be used in the same contexts as C, to do the same things as C code, in very much the same way, but with some modern features, some stronger guarantees and some helpful syntactic sugar? A welcome thing for embedded development.

On the other end, Rust to me felt like "better C++" - outside the embedded niche, aimed at complex multithreaded code that has to combine high performance with not catching on fire because someone fucked up concurrency once again.

But the main issue I had with Rust - that it's frankly a bitch to write, nearing Go levels of awful, only worthwhile if its paradigm is buying you a lot - is diminished if it's an LLM that's doing the bulk of the line to line writing.

And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it.

So, the niche for Zig does seem to be shrinking. The window for it to establish itself might be genuinely closing now. Which is a shame, because I like the idea of having "better C" a lot. But all of this drama sure isn't helping it gain traction.

> I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.

You hit the nail on the head there. Zig is 10 years old now and it’s pretty clear that the industry isn’t biting, compared to the behemoth that is Rust. Between Rust, C, and C++ there is very little room for another language with a woefully incomplete library ecosystem to establish itself.

A true competitor would need to offer genuine extra value, such as dependent types or other formal verification features, to carve out a niche.

Yeah, I mean … as a C++ dev I have those same existential “what’s the point” questions about Zig.