Zig is too uninteresting to eclipse anything. It's the same problem as D's -betterC option. It's not better-enough to motivate switching away from C in places where C is still used, and it's far too stripped down & basic to attract the majority that's gone to C++, Rust, Go, ObjC, or Swift (or even "full" D). It doesn't offer much to justify switching costs. If C++11 had never happened then maybe Zig would attract the C++ crowd, but today?
Zig also seems far too opinionated & even self-contradictory. Like no hidden control flow means that you can't have operator overloading because apparently the + operator is invisible to people or something. And if it could be overridden it could call a function (gasp!) or throw an exception (double gasp!), followed immediately by a big section about how the + operator internally is hidden control flow and can throw an exception (overflow checking).
It then also constantly claims itself as being small & simple, but it has compile-time reflection & evaluation for templated functions - which is widely considered the main complexity of C++. I think Zig is better overall having this feature, I love constexpr & friends in C++, but compile-time code generation & evaluation over generic types is also not "simple" nor "small".
As someone who knows C and not Zig, Zig is very interesting. It has incremental compilation, in-place binary patching, the ability to use code before declaration in a file, compile-time code execution, and extremely low compile times. Rust itself doesn't have most of those.
Also, as Python illustrated, a language doesn't have to be interesting to be popular.
As Python also illustrated, a language can be opinionated and popular. I'm growing more and more convinced that useful languages have to be opinionated - opinions have to be somewhere, and if they're not in the language (where the entire community is forced to use them), then they'll have to be in individual code-bases, where you'll get a bunch of fragmentation (which I think was one of the things that killed Lisp).
Now, Zig is very imperfect - no hidden control flow/operator overloading, no REPL, and a weak type system, most notably - but it's better than C in almost every way, easier to learn than Rust, and way more conceptually scalable than FORTH (which has a more "beautiful" design).
> Also, as Python illustrated, a language doesn't have to be interesting to be popular.
Python was very interesting, or rather, Python is the thing in its interesting group that survived. Highly flexible scripting language with a "batteries included" library set is a very compelling sales pitch, even today. It was Perl but readable, and in this case simply being "readable" was interesting enough to cause it to win out (and also Perl's internal drama)
> As Python also illustrated, a language can be opinionated and popular.
Python's "style guide" is opinionated, but Python the language itself isn't that opinionated. Missing ++ & -- are about the only contentious "opinionated" aspects to it. You can fiddle with basically everything else however you want, though, and the language made adjustments to make that even more possible (eg, replacing the print keyword with the overridable print() function).
Critically Python's standard library didn't really get any special treatment from the language. When a language lets the standard library or builtins do things that you can't, that's when it gets really questionable.
"Perl but readable" and "batteries included" are true but leave out some equally important things: The explicit reference / dereference business in Perl makes handling nested data structures pretty annoying and strongly guides programmers to avoid those, which has a lot of compounding effects to structure of prgorams. Also Python embraced multiplatform early on, and had eg excellent Windows support, whereas Perl was always Unix first. Also the culture is important. Python was always beginner-friendly whereas Perl people were less likely to suffer fools gladly.
> It has incremental compilation, in-place binary patching, the ability to use code before declaration in a file, compile-time code execution, and extremely low compile times. Rust itself doesn't have most of those.
Rust has all of those except in place binary patching and fast compile times.
Rust's "compile-time code execution" is a horrendously complex joke, and it's compile times are so atrociously long that the lack of those two things you mentioned is even worse than in a language like C (with somewhat-sane compilation speed).
> Incremental compilation, edit-and-continue are available in Visual C and C++.
In a particular toolchain not available cross-platform - not comparable to Zig having it available in the reference implementation, which is open-source and cross-platform.
> REPLs do exist for C and C++.
Hacky, nonstandard ones with limitations and altered semantics that aren't included in any of the major IDE's. Not remotely comparable to what's provided with SLIME.
> It's the same problem as D's -betterC option. It's not better-enough to motivate switching away from C in places where C is still used, and it's far too stripped down & basic to attract the majority that's gone to C++, Rust, Go, ObjC, or Swift (or even "full" D).
I've been interested in D since the early days (back when it had two competing standard libraries) - I think you're kind of misrepresenting why D never caught on - it wasn't that people weren't interested in a better C++ - it's that D was unsuitable for a lot of scenarios C++ was used because they decided to include GC in the language and it needed to have a runtime that supports it. This put D more in the C# alternative camp than C++ alternative, it was harder to port (I don't know if D still has a working iOS or Android ports, it didn't have them a few years ago when I last checked). And as a C# alternative it's strait out worse across the board (C# has quite string native interop so D doesn't really win much, tooling ecosystem and support is levels above).
If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction. The problem is that's a huge undertaking and I don't see who would be motivated to fund such a thing.
Rust exists because it solves a real problem and places like this BT stack seem like perfect use case due to security aspects - but the security aspect also adds a lot of complexity and there are domains that really don't care about it - they just want sane modules, modern package management and fast compile times.
Go has it's own niche in the application/network programming.
Seems like modern system languages get purpose built and general purpose ones are higher up the stack.
> If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction.
This happened recently (in D timeframe) and is still a hack that basically creates a different language that's a subset of D - which is the dirtiest way to fix an initial design mistake. If D came out as betterc from the go I guarantee you the adoption would have been much better - this way you're stuck with legacy decisions of a language that was never really that popular to begin with (unlike C - C++ story).
Also back when it launched LLVM wasn't really a thing (GCC was probably the closest thing to having a portable backend but it wasn't nearly as clear cut especially with the licensing and all that anti-extensibility attitude), and D having it's own custom backend was also an issue.
I applaud the effort but at this point I think it will never get mainstream popularity like Rust. I'm sure it's useful to people but it had it's time in the spotlight, I don't see how they get the momentum shift.
> It's not better-enough to motivate switching away from C in places where C is still used
I suspect zig will eventually fill this niche. Proper arrays and strings and better compile time execution support while still being a small, simple, explicit language are quite significant improvements on C.
But why wouldn't I use Rust in those scenarios, which gives me even more safety & compile-time bug checking? Zig isn't actually a small or simple language, after all, that's just marketing bullshit. Manual, mostly unassisted memory management isn't simple, and compile time evaluation & reflection isn't small. It keeps making claims about being simpler because it doesn't have macros or metaprogramming, but that's incredibly deceptive at best since it does have compile-time code generation (aka, metaprogramming). It's how Zig's printf function works! https://ziglang.org/documentation/0.7.1/#Case-Study-printf-i...
And as a bonus Rust includes a package manager today, instead of a coming eventually promise. So I'm not seeing why I'd ever go with Zig over Rust if I was migrating off of C today?
> Zig isn't actually a small or simple language, after all, that's just marketing bullshit. Manual, mostly unassisted memory management isn't simple, and compile time evaluation & reflection isn't small. It keeps making claims about being simpler because it doesn't have macros or metaprogramming, but that's incredibly deceptive at best since it does have compile-time code generation (aka, metaprogramming).
As VP of marketing bullshit I recommend you double check your source of information as we never claimed that Zig has no metaprogramming, in fact comptime is mentioned on the front page of the official Zig website and the codesample on the right of it shows comptime metaprogramming too.
That said, is you need something stable today, then Rust is undoubtedly the better choice.
It think zig makes quite a bit of sense for micro-controllers where you need really precise control of things, avoid lots of bugs simply by having all memory statically allocated, and you need to do a lot of unsafe bit twiddling anyway to interact with hardware.
Zig won't dis-allow any correct programs, zig would compile faster, and zig does appear to be simpler even though in principle you could come across specific zig programs that aren't simple due to doing crazy metaprogramming.
If I imagine a world where Zig is 1.0, and has the same tooling/ecosystem as Rust, and I want to make a single player game from scratch, I would probably pick Zig over Rust, and Zig over C or C++.
I think Zig is really interesting and has a lot of great ideas, some of which I hope Rust takes inspiration from. They've also done some difficult engineering work to make parts of the development experience feel amazing, like bundling clang and libc implementations for a variety of platforms so that cross-compiling works out-of-the-box. The Zig cross-compiling story is the best I've ever seen of any language, bar none.
That being said, I do think Rust's memory safety story is a game-changer for systems programming. We seem to be in a programming language boom, with lots of new and interesting languages being developed. I hope some of them iterate on the concepts that Rust has developed so we can do even better in the future! I don't think anyone involved in Rust would claim that it's the best we can do, or it solves every problem perfectly.
Why would you need operator overloading in a low-level language? It's not like you are gonna write Jupyter notebooks with it. Zig is not meant to replace MATLAB, Python or Julia. I would use it instead to build the backbone of such a data science platform.
> Why would you need operator overloading in a low-level language?
Have you ever heard of matrices and vectors? You need them in a lot of DSP (digital signal processing) applications, like audio and video filters, or in 3D graphics. Being able to write
because the * operator is side-effect free by convention, while a method like vector_mult() might or might not be mutating (i.e., it could work like the *= assignment operator).
I use operator overloading in C++ all the time, you seem to be looking at it from a data science perspective, but other fields use math also, such as gamedev.
I would have imagined that in game dev you prototype first with a high level language and then you would write the math code. How much of game dev is actually math code, aside from critical components like rendering, physics, etc.?
I share your view partially. As you said, code generation is difficult and it can get messy pretty fast, but this is the beauty of Zig, you have these features tightly packed, there is a capped number of ways for doing things. In Zig you learn how to use the wand properly, instead of being distracted by trying different sizes and colors of wands. While many languages focus on the breadth of ways of doing things, Zig is all about the depth of a small set.
Sounds a lot like Go. For me, that was a huge problem with Go.
I can only speak for Go, not Zig at all, but not giving me the "wand colors" meant that when i still needed colors to solve my problems, i had to invent them myself. .. okay this analogy breaks down there, but yea. The need for basic things like iterators, enums, and sometimes even generics didn't go away in Go. They didn't stop being extremely useful patterns or abstractions. They're just missing.
So what do you do with something that is still useful, possibly needed, but missing? You reinvent it. Very basic behavior like Iterators, Maps, etc become separated by piles of functions spread out all over the page. Yea, it's all simple - no complex features, but also no way to express that logic tightly, quick to reason about. Go wears down your scroll wheel in my experience (~5 years).
Would i have the same complaints about Zig? Your comment leaves me feeling like i would.
> So what do you do with something that is still useful, possibly needed, but missing? You reinvent it.
Yup, see for example java.lang.Comparable which is basically just the standard library going "yeah the language screwed up, here's your operator overloading"
Back then the main draw of Python was supposed to be the "one way of doing things" - Python originally started as a teaching language.
And look at Python today - there's what, five different "standard" ways of packaging libraries? (And why is "packaging libraries" even a thing?) Instead of "batteries included" we get at least four different ways of doing every common task: the stdlib Python 2 way, the stdlib Python 3 way, the "standard" community third-party synchronous library and the "standard" community async one.
This is just how it always is. Every language starts with the goal of being small, easy to understand and beautifully composeable.
The cruft builds over time because people eventually want it and because none of it ever really goes away due to backwards compatibility.
I think it's best to make peace with this fact, learn to live with the cruft and accept existing languages rather than switching your entire stack every three years trying to chase an unobtainable dragon.
Zig also seems far too opinionated & even self-contradictory. Like no hidden control flow means that you can't have operator overloading because apparently the + operator is invisible to people or something. And if it could be overridden it could call a function (gasp!) or throw an exception (double gasp!), followed immediately by a big section about how the + operator internally is hidden control flow and can throw an exception (overflow checking).
It then also constantly claims itself as being small & simple, but it has compile-time reflection & evaluation for templated functions - which is widely considered the main complexity of C++. I think Zig is better overall having this feature, I love constexpr & friends in C++, but compile-time code generation & evaluation over generic types is also not "simple" nor "small".