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

You're not seriously out here posting raw numbers without considering the base rate are you

You're not seriously posting about base rates without any form of agreeable evidence around such base rates?

I think the open to close ratio needs to be provided in any such comparison. It would arguably give a better indication of which project is doing a better job at addressing incoming user issues.

Yeah, well, my not-yet-written language has zero segfault issues raised, so it’s clearly superior to both Zig and Rust. I really need to get around to writing it because obviously it’s a much better design.

It's a bad metric, but also Zig didn't migrate all of their issues from GitHub. Run the same count on GitHub and you'll see the full picture

Without base rate you're comparing #X in a city vs #Y in a continent and drawing conclusions from that.

It's not even wrong.

You’re literally agreeing that the parent’s argument is bad. I was just applying his logic, and I didn't draw any conclusions.

No. I just think you're taking judge by number of segfaults out of context. That said, I wrote this before the edit.

To make a better comparison, you have to add up Zig's issues on GitHub that weren't brought over and abandoned.

That would be Zig's 700 or so Codeberg issues + the 2,700 or so GitHub issues.

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

some may argue for ghostty but yeah :)

If TigerBeetle is the Zig flagship then Zig is untenable for almost any team, because Tiger Style is untenable for almost any team. No, I think that Tiger Style makes Zig mostly unimportant.

On the other hand, as a corporate backer for Zig, TigerBeetle is definitely a big deal.

But in terms of exemplary and imitable projects in the ecosystem I would think something like Ghostty is the safer label for "flagship".

TigerBeetle is interesting because even though something like TigerStyle is unusual for a database, it is very much at home for embedded systems.

In fact we could summarize TigerBeetle as "the financial database developed like embedded software". Determinism is a cornerstone of critical software like in avionics, and naturally, dynamic allocation is forbidden, as in TigerStyle.

So even though it is not obvious, TigerBeetle represents one of Zig biggest strengths: embedded systems.

or libghostty

TigerBeetle has a unique static memory allocation strategy at launch time. It’s a strategy that sidesteps a lot of memory management issues but only works for very specific use cases.

Their success with this strategy isn’t portable to most other projects. I think they really need more traditional flagship projects that generalize to typical memory management use cases. The way the conversation keeps coming back to TigerBeetle as a success story isn’t helpful to anyone trying to evaluate the memory management angle.

I would say the exact opposite, actually - Zig is a language specifically suited for TigerBeetle's all-at-once approach to memory management, and the approach more commonly used in Rust (allocate wherever and whenever) is non-idiomatic in Zig.

> only works for very specific use cases.

It's not clear to me what you mean by this.

The funny thing is that Rust works perfectly fine with statically preallocated memory. It's not even against its idioms - most code will work with zero changes. In a way, the borrow checker is the perfect tool for this situation, since nothing owns any memory and everything is borrowed from the static allocation.

There's definitely one code change that's needed - you need to override the Allocator being used by standard library containers (or, live without standard library containers) and by any third-party dependencies you have. That feature is not even stable, let alone idiomatic.

Using the allocator interface is only required if you allocate, which in this context you explicitly don't. If you want to use static preallocated memory in Rust, you'd have to use #[no_std] and only have access to the core part of the standard library. On the plus side, this is a very well supported and stable configuration, the core library is still pretty rich, and there's plenty of no_std libraries to choose from in the ecosystem.

I used "most" in the pedantic sense of "just a little bit over 50% if you count individual lines and not whole libraries". Most code doesn't operate on Box, Vec, String etc. directly, and is happy with & and &mut to underlying data. And even when it does, it's usually used for giving static lifetime to data, which is a non-issue here because all your preallocated memory has static lifetime already.

> It's not clear to me what you mean by this.

TigerBeetle calculates all the memory it needs at startup. It allocates that much memory once. It does not allocate memory dynamically.

This only works for very specific use cases, like a fixed server size where you know exactly how much memory you want to allocate to a process.

It’s not portable to general purpose computing, where it’s expected that apps aren’t allocating the maximum amount of memory they might use at startup. Their memory usage grows and shrinks as you open and close files or as your documents get longer.

> and the approach more commonly used in Rust (allocate wherever and whenever) is non-idiomatic in Zig

Allocating memory as needed isn’t a Rust-specific idiom. Most programming involves dynamic memory allocation.

I don’t think the Zig developers would go as far as saying Zig isn’t a good fit for dynamic memory allocation. If it was that simple this entire debacle could have been written off as “Bun requires dynamic memory allocation by nature, therefore Zig isn’t a good fit”. That’s not what Andrew Kelley is trying to say though.

> This only works for very specific use cases, like a fixed server size where you know exactly how much memory you want to allocate to a process.

So, like, the JVM with its "initial heap size" setting? After reserving that space from the OS on startup, pieces of the space are then handed out by the JVM's internal allocator, where and when needed.

If initial heap size and max heap size are the same, that initial one is the only malloc() call that ever happens. Not as common for desktop software, but a common best practice when deploying JVM applications to servers.

(I think we're perhaps tripping over two different meanings of "allocate" - you can "allocate" in the sense of calling malloc(), and you can "allocate" a piece of that reserved memory to a particular scope/function/object without actually calling malloc.)

> Allocating memory as needed isn’t a Rust-specific idiom.

I never said that.

There isn't such thing as "The JVM", there is a standard with several implementations, which one with their own approach to memory management.

You might be mixing it with the reference implementation for the standard, OpenJDK, and even then, it depends pretty much on which set of configuration parameters are given.

It works really well for a ton of use cases (e.g. any data acquisition task, which is mostly what I use C for...)

Do they really not have any kind of sub-block dynamic allocator?

Does the program handle character data? It is indeed a rare server app which never handles strings.

TigerBeetle is hardly a product to drive Zig adoption.

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 wouldn’t write Zig off yet. The faster compilation time is a giant moat. Depending on how LLM usage evolves it could be what ends up mattering.

I'm not writing Zig off myself. I would prefer if it succeeded. But the outlook is: not good, in my eyes.

Pre-2022, Zig was doing decently, but not particularly well. It didn't have Rust level of enthusiasts and ambassadors (love them or hate them, they did succeed in driving considerable Rust adoption), it didn't have a major corpo backing it, it had too much API instability to be truly relied on. Picking a stupid fight with Bun/Anthropic and doubling down on it isn't helping with any of that.

I also don't think compilation time makes for a good moat for agentic AI coding? Like, sure, less time wasted = better. But LLMs don't perceive time as humans do. They don't have the human "40 minutes of compile time = a hard forced context switch" quirk. The state of an LLM agent is as "stale" after a 40 minute build as it is after a 40 second build - no attention penalty for getting distracted.

There is a hard "wall clock time" iteration speed penalty, but I expect LLM coding to be more agentic, not less. In which case a single sub-agent stalling might not matter much? The orchestrator AI would just keep doing other things, and come back to the stalled sub-agent when it's ready. Once again: long stalls hurt the worst if they route through human attention. The less human attention there is in the system the cheaper they are.

A day or two ago someone posted about abandoning Haskell because compilation times had become a bottleneck with Agents. FWIW

HN discussion: https://news.ycombinator.com/item?id=48859673

1 minute skim of that surfaces aviaviavi's comment on moving to Python not Rust:

  Main factors were (roughly in order):
  - None of us are experts in Rust, and we're all solid at Python.
  - Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way).
  - Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will work

also, the fact that you can compile to any target from any target

I write a lot of Rust and work on some large-ish code bases. I’ve also done Zig work and work in other languages with fast compile times.

I don’t think this is a huge moat any more. Structuring Rust codebases in a modular way to keep incremental compile times down is common. The biggest complaint about it is from people who simply don’t like the structure and want to put everything into one big package, but that’s a stylistic choice.

You write Better C and the first thing I think about is D-lang.

you write D-lang and all I can think of is too much nonsense you have to tell a team (an LLM?) to avoid the temptation to use.

Fall into it. I am rewriting all my projects in D-lang. It is really that good. Particularly when compared to Zig and Rust.

A typical comment on Hackernews nowadays:

I used to think that there's a a room for better C -> Some unrelated complains about Rust and Go -> C has footguns, but they don't matter that much because I choose to not write my code myself anymore -> Therefore there's no room for better C.

What makes go so awful to write? My impression was that Rust was hard, at least until you understand the borrow checker, and go was pretty easy. (This is my impression from outside, that is, I don't actually use either language.)

Not OP, but normally people complain because its boring, but these days, have an LLM generate all the template coding, the json mappings or whatever people dont like. Personally, with all the compromised NPM and PiP packages, when i PoC / vibe code something, i tend to use Golang very few external packages (native sqlite) and thats it. Also really nice to be able to package up the App and all related files into 1 binary.

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

'plow through it's?? An LLM can definitedly fall into these traps!

Happened to me a few months ago, I couldn't believe that an LLM would generate a use-after-free in not-so-complex code but it did.. Newer LLM seems better now but buyer beware!

You still need an expert human to drive an LLM. And even then, with C, you need to be very careful. LLM’s generate lots of code. Code that has no obvious errors in it. The kind humans aren’t good at picking up on their own. You need other tooling in place to support human experts to prevent this kind of stuff as you would in a non-LLM contribution.

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

Warts and ancient quirks, I can kind of see, but in what way have LLMs solved the footguns?

Mostly, by having enough diligence and attention to avoid a lot of the common ones.

By now, if we're pitting a top of the line coding LLM against a B-tier programmer throwing something together in a hurry, I would expect the latter to shot more foot, and not by a narrow margin. Even those who know better don't always do better - for a human, "fucks given" is a painfully finite resource.

"Rust - that it's frankly a bitch to write, nearing Go levels of awful"

Go, awful? That's wild. I find Go to be maybe the most pleasant language I've ever used. It's just delightful for its niche (web services, system tools, things of that nature), I've never seen anything better.

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

AFAIK zig is not trying to be "better C++" (that is Rust), zig is more like "better C". a ergonomic low level lang with very little abstractions. zig explicitly doesn't want to be better C++ or rust

Oh, I get that.

That’s what I’m saying. I hear “Better C” and my initial reaction is “what’s the point”. Like, why would you aim for “Worse C++”?

I mean, compile times. That’s fair.

Even those aren't that bad, when using C++20 modules, coupled with binary libraries.

Granted we "aren't modules" yet, unless being on latest compilers with msbuild/cmake/ninja tooling.

Perhaps theoretically, with good practice, but at my job it’s fucking brutal.

But to your larger point I would much rather work on improving that than let it drive me back to C fetishism.

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

> it’s pretty clear that the industry isn’t biting

Zig isn't finished yet (they still have not released a v1.0). They're still iterating on the language itself and want the flexibility to make backwards-incompatible changes while they do so.

So in a sense, they have not yet asked anybody in mainstream industry to "bite." After v1.0, when there's an understanding of stability and ongoing language support, industry adoption or lack thereof might become a relevant metric for measuring the project's health. But right now that's not relevant at all.

I hear you, but Zig is also 10 years old now. While the authors may not want to signal they're ready, people make assumptions based on age regardless.

Either users think (a) it's actually ready after a decade, since many langs/libs are conservative with jumping to v1.0, or (b) they'll think it's [a toy/a side project/run by perfectionists] that's not ready for production, and might never be.

This isn't exactly fair for those who want to just take tir

This. I talked about Zig to my company CTO for embedded systems, he told me he was happy that someone mentioned it as he finds it promising and not much talked about, especially compared to Rust.

He then told me that it is, as you said, unfinished, and that he can't reasonably recommend it for embedded projects that are often long term and demand stability. C, a 1970 language is still king for a reason! So he is keeping Zig on his watchlist for when it becomes more mature.

Python was invented two years before Java and didn’t move the needle until the mid 2010s.

You are the typical mark for hype cycles. Get a clue will you.

Python was being used as a teaching language at flagship universities in the mid 2000s.

Amazing! So was Scheme.

> Python ... didn’t move the needle until the mid 2010s.

Nope. I was on a Python project in 2006 and earned a paycheck doing so.

I was getting paid doing django in 2005-2006

The industry isn't biting @ Zig because it's unstable, notoriously difficult to integrate new changes into an existing codebase and because the compiler is a bitch to develop with (hard error on unused variables with no way to turn it off).

Go has that same problem/feature

Yes, sadly.

Not sure that last one rings true. There are entire languages with no allowed unused variables (some without prepending a _ to the names) that people love to develop with.

In the industry, how often is it that a tool/language is picked up for the ease of developing that tool, vs ease of using that tool?

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

believe it or not it is generally easy to do this with zig with few modifications (WIP), and the team has said publically that they will be making this sort of thing a supported operation once the IR stabilizes post-1.0.

https://github.com/ityonemo/clr/

There is also the fact of newer "closer to C" alternatives like C3[1] and Zen C[2], or more intriguing C family alternatives such as Odin[3], Jai[4], or Vlang[5].

Zig is kind of trapped. It can't go "head to head" with heavy weights like Rust, who specialize in safety, are more mature (post 1.0), and have lots of corporate support. Then there are the other C alternatives, who each offer something it doesn't have.

It appears the only way for it to maintain its position, is through heavy hype and marketing, but the whole Bun ordeal and extensive beta issues are subtracting from any such attempts.

[1]: https://c3-lang.org/

[2]: https://github.com/zenc-lang/zenc

[3]: https://learnxinyminutes.com/odin

[4]: https://www.youtube.com/watch?v=IdpD5QIVOKQ

[5]: https://codefreelance.net/apps/vlang.html

This is just a dumb take, hardly any language is immediately popular. Python, Ruby, etc. were still pretty niche 10 years in. Pretty much every popular language is 15+ years old.

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.

If you literally want one and only one allocator instead of the Rust's built-in one, that's been supported for years[1]. Almost 8 years, to be precise. It's very easy to implement and works with the entire standard library and all its abstractions, and almost every 3rd party library will support it out of the box too (except the ones that go out of their way not to support it for some reason). Borrow checking and all the other safety features are still fully supported.

Now, mixing different allocators is a different beast, and much less supported. But it sounds like you are very much not interested in this use case, right?

[1] https://doc.rust-lang.org/std/alloc/index.html

If you allow, I’m curious: If you felt familiar with the language just as much as with C/Zig/Odin, would you prefer Rust for a completely greenfield project that requires no C interop (or none more detailed than say providing a general ABI)?

I like my PCs like I like my cars--rust free.

I like my datacenters like I like my railway infrastructure - covered in enough protective layer of rust that it will never suffer structural damage even when running for years under extremely heavy load.

In that case I recommend using C language. I heard Zig is a good alternative.

Why do you recommend the living definition of not having any protections whatsoever for protection?

Why do you make up nonsense and believe it?

Is it nonsense to say C doesn't have any protections?

Sure thing :)

Just my opinion. It really depends. For systems- kind of software (low-level, DBs, file systems (also user-space)) no, I wouldn’t - if you manage memory with arenas and/or can plug in an allocator to tell you if you leaked memory (provided the codepath is triggered), I mostly get what I want with less mental overhead. Also, I very often want to interface with C libraries.

For games, again, I wouldn’t. I again strongly suspect I would and could organize my use of memory better.

I suspect Rust is best when you don’t want to interface with C code (except through bindings others wrote) and you’re maybe more doing applications development where C++ has also stood strong. I completely see how, theoretically, Rust can make a great language for an office suite, browser and so on.

That’s actually also when I tried Rust for a personal project. I wrote a desktop application and while I spoke to C code, I only did so through bindings others had written.

It was/is fine :) I still got a segfault bug though hehe.

Basically I liked Ocaml so I have huge appreciation for all that Rust tries to bring into the mainstream on that front. I am just not thinking that the borrow-checker makes it well placed to interop with C. It becomes much better for relatively isolated applications work.

C++ programmer here. I've looked at transitioning some of my code to Rust; not particularly out of a dissatisfaction with C++ but more just out of curiosity. I've always ended up deciding against it though, I feel like its safety features just come at too high of a price for the kind of work I do. If I was writing something that needs to be super secure like a web server or something I think it would make a lot of sense, but for most of the things I do memory corruption is relatively easy to avoid with good patterns and a crash just kills a local application. YMMV but I think the "safety" of Rust gets a little overhyped.. most the bugs I run into are not memory safety bugs.

The safety aspects do get very hyped. It's better to consider the language strict about correctness; memory safety falls out of that, but so does other stuff, like less logic bugs.

Thing is, this is from someone that likes Rust, but for various reasons has to reach out to C++ when going outside my daily use of managed languages, while C++ will never be as safer as Rust, there are many tools to get us half way there.

The big problem is that many projects keep ignoring those tools, the way Zig sorts out reporting use after free errors, the same solution exists for C and C++ for about 30 years now.

Is there a reason you cannot specify your allocator of choice in Rust? AFAIK, the abstraction exists to do just that.

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

> Removing #define alone would have been worth it.

If you reach out to any project manager and pitch the idea to rewrite a whole app from scratch because you want to get rid of #define, first you will be laught out of the room and second they will reach out to HR to get a PIP going because whatever the hiring bar they used to hire a developer you clearly are not meeting it.

nice strawman. we're obviously talking about greenfield developmen, and then, probably not in corposlop environments.

> 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

I promise you, hand on heart, that literally no one on the Zig core team is wasting their time on thoughts like this.

> and their flagship project has now abandoned it.

Quoting Andrew:

> So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.

I advise you to take this paragraph at face value. Again, I promise you that it is the truth.