It's a language that attempts to solve more of the biggest issues with low level programming than any other current low-level programming language. Of course, there is nowhere near a universal consensus on what the biggest issues are, but here's what they are to me in order of importance (and I'm not alone):
1. Language complexity/lack of expressivity. You want code, as much as possible, to clearly express the algorithm at the level of detail needed at the language's domain, no more and no less. The level of detail in low-level languages is different from high-level languages because, for example, you want to see exactly where and when memory is allocated/freed. Both C and C++ fail at this for opposite reasons. C is often not expressive enough to express an algorithm clearly (at least not without the use of macros), and C++ is often too implicit, hiding important details that are then easy to miss [1]. These problems may affect program correctness.
2. Lack of spatial memory safety, which is the cause of the #2 and #6 most dangerous software weaknesses (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html). Unlike spatial memory safety, Zig doesn't guarantee the lack of temporal memory safety. This would have been very nice to have, but it isn't as important and not worth compromising on the other top points.
3. Slow build times, which may also affect correctness by slowing down the test cycle.
I don't find Zig similar to C or C++ at all (certainly not as similar as Rust is to C++). If anything, Zig's risk is in being a more revolutionary step than an evolutionary one.
---
[1]: In the late eighties/early nineties (when I first learned C++), when we thought it might be a good idea for a language to be both low-level and high-level, C++'s notion of "zero-cost abstractions" seemed very interesting and even promising (I don't recall them being given that name then, but the problem - or advantage - was right there at the beginning; e.g. whether a call uses static or dynamic dispatch is an algorithmic detail that may be of interest in low-level programming, as well as whether a destructor is called, possibly through dynamic dispatch). Now that notion feels an outdated vestige of a bygone era. I'm aware there are still C++ programmers who still believe in writing high level applications in low-level languages and still believe in zero cost abstractions, but I think the industry has clearly been going the other way, and there's no indication it may be changing direction or may have any reason to do so.
> "zero-cost abstractions"
I believe that in modern times, this term refers to stuff like: transparent conversion to a low-level representation (e.g. a bit-packed integer) from a high-level, statically checked datatype - e.g. a tagged union with exhaustive pattern matching, aka ADT. This is also something C++ etc lack.
We did not though that due to C++, we already though that with languages like PL/I, Mesa, Cedar, Modula-2, Object Pascal, Ada, among others.
Given their level of adoption, those languages represented what their creators thought, not necessarily what the industry thought.
Same applies to Zig, which without something comparable to how UNIX, OS X, Windows SDK, iOS, Docker, among others have forced industry adoption of specific languages, Zig will have as much industry adoption as those languages, just another D or C3.
Maybe Oracle could make it unavoidable on JVM, instead of keeping to use C and C++ on the runtime.
I don't claim Zig represents what the industry thinks. The sharply declining use of low-level languages for high-level applications, however, shows that that idea is certainly unpopular these days. It could still be the case that more people will favour the C++/Rust style of zero cost abstractions even for low-level programming. I make no prediction there.
As for HotSpot, we're not going to make a bet on a language with an uncertain future, and that goes for both Zig and Rust. What is more likely to happen (and is happening already) is gradually reducing the use of low-level languages in the JVM in favour of Java itself. We've already replaced a lot of IO code in C/C++ with Java, and the implementation of reflection has already largely moved from C++ to Java.
Which is exactly the direction I see going forward, finally getting mainstream mindshare closer to how Xerox PARC languages were bootstraped, languages like Zig come about 30 years too late.
Rust is already shipping in production for Windows, Android, Amazon and Azure infrastructure, and the Azure official language for new low level systems code, hardly questionable its adoption in the industry at scale.
Naturally someone might prove me wrong by releasing that one framework or product that makes writing Zig code unavoidable.
> hardly questionable its adoption in the industry at scale.
Really? It's heavily marketed, yet after 10+ years it's struggling to achieve even a 2% market penetration. I mean, I don't think anyone sees it as the next Fortran, C, C++, Java, Python, JS, TS, C#, Ruby, or PHP, but even Go's adoption is much higher. The numbers still look more "let's give it a shot" than "this is the future", and at its rather advanced age, that looks questionable to me. Successful technological products, even programming languages, are usually adopted much more quickly.
> Naturally someone might prove me wrong by releasing that one framework or product that makes writing Zig code unavoidable.
I have no idea if Zig will ever become successful. I mean, if Rust is struggling so badly despite the head start and hype, I don't think the chances are great. It's just that as someone who still does quite a bit of low-level programming every now and again, I find Zig a truly innovative and interesting language. I wouldn't bet on it, or on Rust for that matter, from a pure, disinterested, market numbers or historical trends point of view.
I've seen rust enter every major c++ codebase I've worked on in the last few years. The major thing slowing adoption is the lack of good interop with c++, and general dirth of greenfield projects that can afford to ignore existing c++ ecosystem of internal libraries. Hiring for rust skills is also a challenge. But still adoption presses on. I see a hockey stick curve still approaching.
Yes really, I gave you the examples from industry giants.
Amazon, Microsoft and Google have no reason to drop Rust and replace ongoing efforts with Zig.
Nor Apple is going to drop Swift for Zig.
Vercel tooling is powered by Rust, as yet another example. Which is quite relevant given how many SaaS products only support Next.js on their SDKs.
Anyone using a recent Volvo car is also running Rust code on some canbus units, by the way.
I don't know what you're saying about Zig. I have no predictions about that language's success, I just think its design is very interesting.
Those examples of Rust use by industry giants are a red flag for its adoption, because they look nothing like adoption by those very same companies of languages that ended up popular. Obviously, non-zero usage is something, but the rate and extent of adoption for what is now a fairly old language is exceptionally low compared to languages that ended up making it.
Such an unusually low adoption rate means that it will take another two decades for Rust to pick up even 50% of the low-level space (assuming some positive second derivative). It could be less if the rate suddenly picks up, but it could also be never if other competition enters the game in all that time. Nobody needs to drop Rust for competitors to have a chance because only a small minority is picking up Rust in the first place. On paper, Rust seemed to have better chances than Go in its market segment, but it's doing worse.
Rust is now at the age Java was when JDK 6 came out, and it has maybe 1-2% of the market and 5-10% of the low-level segment. That is not where Rust's believers expected or hoped it would be at this age. Could it somehow succeed in a way that's different from all successful languages before it? That's certainly a possibility, but I don't see any indication for why anyone should bet on that unusual thing happening.