C has an enormous weight to it. If you've been carrying it for decades, you are likely somewhere between being so used to carrying it it's hard to notice the burden, and being so at ease with carrying it that it's not actually a burden. Imo, Zig doesn't have /a/ killer feature. Instead it has hundreds of small design choices made with the insight of decades of programing language evolution, along with a few clever ideas on its own.

I would say it's well on the way to becoming the best language for giving you control as a programmer over the computer. Compared to say Rust focusing on safety first, execution speed second, ergonomics third; Or Go on maintainable systems at large corp scale.

To list some specific examples:

   - No headers.
   - No complex build and linkage systems.
   - Fast compilation (and no explosion of compile time as headers import headers.)
   - A small and distinct set of fundamental types, with true enums, unions, and arbitrary size integers.
   - Code formatting, which is a feature that feels kind of invisible, but means arbitrary code you look at will be formatted in a familiar way.  A subtle but powerful difference.
   - It doesn't try to remove undefined behavior.  Instead it does a really good job of catching you hitting it when building in a development version.  Imo, often code wrote simply will have undefined behavior that is meaningless because it will never be called with that behavior.  It's fine to code that way in C until you accidentally hit it and have a hell of a time figuring out why something isn't working.

A few big benefits off the top of my head:

* A concurrency mechanism that's very easy to use, because it doesn't have the function coloring problem of async/await.

* Extra assistance with memory safety, via its "release-safe" mode. Not a silver bullet, but it does help!

* Good tooling; zig cc can cross-compile from any major OS to any major OS.

* Comptime, a pretty brilliant system that does what generics does for other languages, with a fraction of the complexity.

std.ArrayList

std.HashMap

std.ArrayHashMap

std.MultiArrayList

std.heap.ArenaAllocator

defer/errdefer, try, catch

Debug mode: stack traces, safety checks, segfault handler, error return tracing, valgrind integration, undefined bytes set to 0xAA, GeneralPurposeAllocator finds leaks, double frees, and use-after-frees

Comptime instead of macros

Unit testing

The killer feature of Zig is polish - not yet in implementation(teething issues still abound if one tries to take it into production) but definitely in design. It goes down the list of every language wart or make-do tooling situation in C and addresses it with a reasonably specified and generalized feature, without making the language much bigger(if it is at all - it's not a big language spec). It actively works on some really grody systems-level problems with building binaries that most languages will address with "compiles to C" and C itself addresses with "fight the build system" - Zig aims to be a one-stop shop that clarifies this process. And it integrates C code compilation into its build system, so existing projects can be migrated.

Among all the other suggestions, I appreciate the refinement to the type system that zig has over c. Like bools and ints are distinct types, built in slice types to associate a pointer and length, arrays have a length, well-defined integer sizes (i32 for example), optional, errors, etc. it’s little things like that which make a language much easier to use in the long run.

From what I hear 1. No headers (you can use headers to import C functions. None needed for other zig functions). 2. defer 3. Comptime