> I can’t think of any other language in my 45 years long career that surprised more than Zig. I can easily say that Zig is not only a new programming language, but it’s a totally new way to write programs, in my opinion. To say it’s merely a language to replace C or C++, it’s a huge understatement.
I don't understand how the things presented in this article are surprising. Zig has several nice features shared by many modern programming languages?
> One may wonder how the compiler discovers the variable type. The type in this case is *inferred* by the initialization.
That the author feels the need to emphasize this means either that they haven't paid attention to modern languages for a very long time, or this article is for people who haven't paid attention to modern languages for a very long time.
Type inference has left academy and proliferated into mainstream languages for so many years that I almost forgot that it's a worth mentioning feature.
> One is Zig’s robustness. In the case of the shift operation no wrong behavior is allowed and the situation is caught at execution time, as has been shown.
Panicking at runtime is better than just silently overflowing, but I don't know if it's the best example to show the 'robustness' of a language...
> Type inference has left academy and proliferated into mainstream languages for so many years that I almost forgot that it's a worth mentioning feature.
I'm not even sure I'd call this type inference (other people definitely do call it type inference) given that it's only working in one direction. Even Java (var) and C23 (auto), the two languages the author calls out, have that. It's much less convenient than something like Hindley-Milner.
And it's not caught in ReleaseFast builds ... which is not at all unique to Zig (although Zig does do many innovative things to catch errors in debug builds).
> Type inference has left academy and proliferated into mainstream languages for so many years that I almost forgot that it's a worth mentioning feature.
It’s not common in lower level languages without garbage collectors or languages focused on compilation speed.
The only popular language I can think of is C (prior to C23). If you want to include Fortran and Ada, that would be three, but these are all very old languages. All modern system languages have type deduction for variable declarations.
I meant for focused on compilation speed to apply only to lower level languages. And when I say lower level I don’t really include D because it has a garbage collector (I know it’s optional but much of the standard library uses it I believe).
That a language has a garbage collector is completely orthogonal to whether it has type inference ... what the heck does it matter what "much of the standard library uses" to this issue? It's pure sophism. Even C now has type inference. The plain fact is that the claim is wrong.
I feel like the article didn't really hit on the big ones: comptime functions, no hidden control flow, elegant defaults, safe buffers, etc.
What Zig really does is make systems programming more accessible. Rust is great, but its guarantees of memory safety come with a learning curve that demands mastering lifetimes and generics and macros and a complex trait system. Zig is in that class of programming languages like C, C++, and Rust, and unlike Golang, C#, Java, Python, JS, etc that have built-in garbage collection.
The explicit control flow allows you as a developer to avoid some optimizations done in Rust (or common in 3rd party libraries) that can bloat binary sizes. This means there's no target too small for the language, including embedded systems. It also means it's a good choice if you want to create a system that maximizes performance by, for example, preventing heap allocations altogether.
The built-in C/C++ compiler and language features for interacting with C code easily also ensures that devs have access to a mature ecosystem despite the language being young.
My experience with Zig so far has been pleasurable. The main downside to the language has been the churn between minor versions (language is still pre-1.0 so makes perfect sense, but still). That being said, I like Zig's new approach to explicit async I/O that parallels how the language treats Allocators. It feels like the correct way to do it and allows developers again the flexibility to control how async and concurrency is handled (can choose single-threaded event loop or multi-threaded pool quite easily).
Zig's generics cause bloat just like any other language with generics--explicit flow control has nothing to do with it.
Zig is a good language. So are Rust, D, Nim, and a bunch of others. People tend to think that the ones they know about are better than all the rest because they don't know about the rest and are implicitly or explicitly comparing their language to C.
Zig's generics can potentially, but not necessarily, because Zig's generics are explicitly controlled through comptime functions, which give the developer a ton of control of how the generic code is unrolled. They're also frequently less used in general than Rust generics.
Of course both Zig and Rust are good languages. But my experience, and I believe your experience will be too if you try to compile programs of similar complexity using standard practices of each language, is that Zig compiles much more compactly in .ReleaseSmall mode than Rust does even with optimization flags, which makes it more ideal for embedded systems, in my opinion. I learned this on my own by implementing the same library in both languages using standard default practices of each.
Of course, at the desktop runtime level, binary size is frequently irrelevant as a concern. I just feel that since Zig makes writing "magic" code more difficult while Rust encourages things like macros, it is much easier to be mindful of things that do impact binary size (and perhaps performance).
Rust has macros that allow for arbitrary compile-time generated code, just like Zig. Most Rust-compiled programs are a bit bloated because libstd is statically linked and not rebuilt from scratch with a project-specific trimmed feature set, which leads to potentially unwanted code being included for e.g. recoverable panics, backtraces, UTF-8 string handling etc. A set of new RFC's is being worked on that may at some point allow libstd to be rebuilt from scratch within Stable Rust projects, with well-defined, stable, subsetted features.
> This means there's no target too small for the language, including embedded systems. It also means it's a good choice if you want to create a system that maximizes performance by, for example, preventing heap allocations altogether.
I don't think there's is any significant different here between zig, C and Rust for bare-metal code size. I can get the compiler to generate the same tiny machine code in any of these languages.
That's not been my experience with Rust. On average produces binaries at least 4x bigger than the Zig I've compiled (and yes, I've set all the build optimization flags for binary size). I know it's probably theoretically possible to achieve similar results with Rust, it's just you have to be much more careful about things like monomorphization of generics, inlining, macro expansion, implicit memory allocation, etc that happen under the hood. Even Rust's standard library is quite hefty.
C, yes, you can compile C quite small very easily. Zig is like a simpler C, in my mind.
The Rust standard library in its default config should not be used if you care about code size (std is compiled with panic/fmt and backtrace machinery on by default). no_std has no visible deps besides memcpy/memset, and is comparable to bare metal C.
I understand this, but that is a pain that you don't get with Zig. The no_std constraint is painful to deal with as a dev even with no dependencies and also means that if you're working on a target that needs small binaries, that the crates.io ecosystem is largely unavailable to you (necessitating filtering by https://crates.io/categories/no-std and typically further testing for compilation size beyond that).
Zig on the other hand does lazy evaluation and tree shaking so you can include a few features of the std library without a big concern.
This. Is Zig an interesting language? Yes sure. But “a totally new way to write programs”? No, I don’t see a single feature that is not found in any other programming languages.
I don't understand how the things presented in this article are surprising. Zig has several nice features shared by many modern programming languages?