Rust generally has large ecosystem, Not only Zig is early, it going to take some time for ecosystem form arround the language and become actually useful for broder audiance. Zig might be useful some folks even that this stage. So use whatever right for your situation.
Rust still has an long uphill battle being taken seriously on many domains where C and C++ rule.
Game development devkits and middleware, HPC and HFT, language runtimes of most mainstream languages, LLVM and GCC that itself depends on,...
Only in the last few years it grew enough for the likes of Amazon, Google, Microsoft, Vercel, Clouflare, NVIDIA,...
Still the domains above only have some snowflake projects in Rust.
Any language that comes afterwards, with being a better C, something that was already possible with Modula-2 or Object Pascal, really needs to have a big killer application for adoption.
The most interesting killer application for Zig is perhaps Ghostty and its library libghostty, which will probably be fairly easy to integrate with C apps since Zig is close enough to C.
There’s also Tigerbeetle, but unlike libghostty its use of Zig doesn’t have much chance of being viral.
I think libraries that can be used by many other languages is Zigs chance to wide adoption. And this ties nicely with Zigs fantastic build system, which may become increasingly popular for C based projects, especially where cross compilation is important.
I find it frustrating when people talk about memory safety as “a spectrum.” Yes, there are safer patterns in unsafe languages, but at the end of the day, not having memory safety as a category of bug _period_ is such a nice baseline level to work from!
If you hit a weird state in your program and it can _never_ be caused by memory corruption, you rule out a big bug space and no longer need to check the entire scope of your program. It’s similar to Rust’s unsafe blocks — it doesn’t really matter if they’re “more unsafe” than Zig because in Zig the scope of the unsafe is your entire program! Local reasoning is a huge part of what you buy into and I could never give that up if I didn’t have to.
I don’t think it’s about being a spectrum. It’s about having different paths to the same goal. GC is one well-proven path. Rust / Borrow checker is another path, with other benefits and limitations. Zig is well on its way to a third path with potentially the same level of safety and different benefits and limitations.
Zig will depend on having tests with good coverage, and you should probably use fuzzing. But if you care about safety and stability, why would you not write tests? Memory bugs are not the only class of safety and stability issues we should care about. So I don’t think we should be dismissive of an approach that takes a more holistic approach to those, while also providing really solid memory safety.
I am sure we will see solid static analysis tools for Zig which can weed out a lot of stuff before runtime as well. The developers of the language seem very interested in that approach but need to focus on other things first.
> Zig is well on its way to a third path with potentially the same level of safety
No. Zig says it wants to get to where Fil-C is, for a specific release mode that most people won't use, and it doesn't have even an outline of how that would work.
That's nowhere close to the "same level of safety" as (safe) Rust or Java has. We're going to see all the same bugs and all the same excuses as before.
The logic is the same as arguing that people still die while wearing seatbelts, or cut their hands while having protective gloves, thus they are worthless.
It's a false economy. Mediocre isn't good enough. The fact that mediocre is better than nothing isn't relevant when so very much better was easy.
We're talking about thermionic valves versus transistors in terms of how dramatically worse this option is than actually doing the Right Thing™.
The valve computers weren't relegated to a few specialist tasks, or seen as a particular trade-off that's no longer applicable for some applications, they were just swept aside, because they were obsolete. The memory unsafe languages, likewise, should just go away.
Yes, unfortunately just like those valve computers, progress only comes at the expense of a complete change of generation, where there aren't enough people propagating outdated concepts.
The never-ending discussion of LLM-generated code in binary terms is tiring. It’s either all completely useless slop (which is the author’s stance), or it’s infallible and should be maximized at all costs. Yes there is slop, but there is also good or even great code produced by those making use of LLMs. I understand why a maintainer of a large project like Zig may outright reject LLMs for sheer practicality matters, just to stay on top of the wave of slop generated contributions. But it makes very little sense when a consumer of code, such as the author, takes a black and white stance on if LLM generated code is accepted by the language. If anything, it feels like an intellectual crutch. No need to understand technical nuances when you can fallback on dogmatic zeal.
duplicate from 11 hours ago: https://news.ycombinator.com/item?id=48790302
A more direct title is: ai-hating-author abandons ai-loving-rust for ai-hating-zig.
Rust generally has large ecosystem, Not only Zig is early, it going to take some time for ecosystem form arround the language and become actually useful for broder audiance. Zig might be useful some folks even that this stage. So use whatever right for your situation.
Rust still has an long uphill battle being taken seriously on many domains where C and C++ rule.
Game development devkits and middleware, HPC and HFT, language runtimes of most mainstream languages, LLVM and GCC that itself depends on,...
Only in the last few years it grew enough for the likes of Amazon, Google, Microsoft, Vercel, Clouflare, NVIDIA,...
Still the domains above only have some snowflake projects in Rust.
Any language that comes afterwards, with being a better C, something that was already possible with Modula-2 or Object Pascal, really needs to have a big killer application for adoption.
That could have been bun, not any longer.
The most interesting killer application for Zig is perhaps Ghostty and its library libghostty, which will probably be fairly easy to integrate with C apps since Zig is close enough to C.
There’s also Tigerbeetle, but unlike libghostty its use of Zig doesn’t have much chance of being viral.
I think libraries that can be used by many other languages is Zigs chance to wide adoption. And this ties nicely with Zigs fantastic build system, which may become increasingly popular for C based projects, especially where cross compilation is important.
Hardly something to make FAANGs adopt Zig, and make it unavoidable for everyone else.
I find it frustrating when people talk about memory safety as “a spectrum.” Yes, there are safer patterns in unsafe languages, but at the end of the day, not having memory safety as a category of bug _period_ is such a nice baseline level to work from!
If you hit a weird state in your program and it can _never_ be caused by memory corruption, you rule out a big bug space and no longer need to check the entire scope of your program. It’s similar to Rust’s unsafe blocks — it doesn’t really matter if they’re “more unsafe” than Zig because in Zig the scope of the unsafe is your entire program! Local reasoning is a huge part of what you buy into and I could never give that up if I didn’t have to.
I don’t think it’s about being a spectrum. It’s about having different paths to the same goal. GC is one well-proven path. Rust / Borrow checker is another path, with other benefits and limitations. Zig is well on its way to a third path with potentially the same level of safety and different benefits and limitations.
Zig will depend on having tests with good coverage, and you should probably use fuzzing. But if you care about safety and stability, why would you not write tests? Memory bugs are not the only class of safety and stability issues we should care about. So I don’t think we should be dismissive of an approach that takes a more holistic approach to those, while also providing really solid memory safety.
I am sure we will see solid static analysis tools for Zig which can weed out a lot of stuff before runtime as well. The developers of the language seem very interested in that approach but need to focus on other things first.
> Zig is well on its way to a third path with potentially the same level of safety
No. Zig says it wants to get to where Fil-C is, for a specific release mode that most people won't use, and it doesn't have even an outline of how that would work.
That's nowhere close to the "same level of safety" as (safe) Rust or Java has. We're going to see all the same bugs and all the same excuses as before.
The logic is the same as arguing that people still die while wearing seatbelts, or cut their hands while having protective gloves, thus they are worthless.
It's a false economy. Mediocre isn't good enough. The fact that mediocre is better than nothing isn't relevant when so very much better was easy.
We're talking about thermionic valves versus transistors in terms of how dramatically worse this option is than actually doing the Right Thing™.
The valve computers weren't relegated to a few specialist tasks, or seen as a particular trade-off that's no longer applicable for some applications, they were just swept aside, because they were obsolete. The memory unsafe languages, likewise, should just go away.
Yes, unfortunately just like those valve computers, progress only comes at the expense of a complete change of generation, where there aren't enough people propagating outdated concepts.
The never-ending discussion of LLM-generated code in binary terms is tiring. It’s either all completely useless slop (which is the author’s stance), or it’s infallible and should be maximized at all costs. Yes there is slop, but there is also good or even great code produced by those making use of LLMs. I understand why a maintainer of a large project like Zig may outright reject LLMs for sheer practicality matters, just to stay on top of the wave of slop generated contributions. But it makes very little sense when a consumer of code, such as the author, takes a black and white stance on if LLM generated code is accepted by the language. If anything, it feels like an intellectual crutch. No need to understand technical nuances when you can fallback on dogmatic zeal.