Direct C++ interop is doable, by embedding Clang into Zig and using its AST, but this is significantly more work and it needs to be done in the Zig compiler. As a Zig user, going through C is about as good as you can do, probably.

fn stackExample() void {

    var some_cpp_type: c.SomeCppType = undefined;
    c.some_cpp_type_ctor(&some_cpp_type);
    defer c.some_cpp_type_dtor(&some_cpp_type);

    // ...

}

So while most systems will be using Vulkan, macOS will be using metal.

Zig is a better C. No abstractions. Close to bare metal.

Rust is a better C++. Abstractions to simplify application level programming.

I don’t think comptime as just some macro system. It is closer to a reflection system. I use comptime to access types. You can create specialized paths depending on type.

Also imo generics are “first class” in zig. Comptime is first class and thus generics are too.

Is everything first class, then?

This anything implements with macros are not first class

But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block.

> If I see a defer

The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function. That's non-local reasoning, which is what Zig professes to abhor.

And in fact defer is worse than destructors here, because a destructor runs the exact same code every time, whereas defer allows arbitrary code, so you need to review every single usage. And you also need to remember not to forget to use it in the first place (which is the classic footgun with defer), so in addition to vetting everywhere you use it, you also need to vet everywhere you might have forgotten to use it.

Why bring up destructors, I was talking about exceptions. Destructors and exceptions are orthogonal concepts, one can be implemented independently of the other. I'm specifically referring to try-catch blocks like those in java.

Compare this:

  try { foo(); }
  catch { bar(); } 

  defer bar();
  foo();

> The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function.

What? You don't need to read the entire function, you only to scan or check for defers scoped in a block, or in some cases, just the top of a function or block. Wanting to just read the end of a function is unreliable anyway with the existence of early returns (which defer fixes by the way).

You could have made a more compelling (but not necessarily a valid) case by citing zig's try-catch, which makes me think that you are just arguing in abstract without actually having tried writing code that uses defer, or any zig code for that matter.

This is why Zig was smart to have first party support for C libs.

In fact the fact Zig pointer types are more precise, it allows imported C libs to be more correct than the original C.

Okay maybe theorically, but in the real world I would like to have the filename on a "file not found", an address on a "connection timeout", a retry count on a "too many failures", etc.

I’d like my parser library to be able to give me the exact file, line and column number an error occurred. But I’d also like to use the library in a “just give me an error if something failed, I don’t really care why” mode.

How useful is a file not found error type without data (the filename) when the program is looking for 50 files? Not very.

How useful is a generic error type with '{filename} not found' as generic string data packed in? Quite.

I feel what is missing is how each feature is so cool compared to other languages.

As a language nerd zig syntax is just so cool. It doesn’t feel the need to adhere to any conventions and seems to solve the problems in the most direct and simple way.

An example of this declaring a label and referring to a label. By moving the colon to either end it makes labels instantly understood which form it is.

And then there is the runtime promises such as no hidden control flow. There are no magical @decorators or destructors. Instead we have explicit control flow like defer.

Finally there is comptime. No need to learn another macro syntax. It’s just more zig during compilation

https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html

Zig's big feature imo is just the relative absence of warts in the core language. I really don't know how to communicate that in an article. You kind of just have to build something in it.

That's been my exact experience too. I was surprised how fast I felt confident in writing zig code. I only started using it a month ago, and already I've made it to 5000 lines in a custom tcl interpreter. It just gets out of the way of me expressing the code I want to write, which is an incredible feeling. Want to focus on fitting data structures on L1 cache? Go ahead. Want to automatically generate lookup tables from an enum? 20 lines of understandable comptime. Want to use tagged pointers? Using "align(128)" ensures your pointers are aligned so you can pack enough bits in.

There's a certain beauty in only having to know 1~2 loops/iteration concepts compared to 4~5 in modern multi paradigm languages(various forms of loops, multiple shapes of LINQ, the functional stuff etc).

Skipping other minor changes.

However I do agree C# is adding too much stuff, the team seems trying to justify their existence.

My experience with Golang so far is biased because i only recently looked at golang, for the past decade i have been working mostly in java and c#, so most of those newly added features in golang is stuff i'm already deeply familiar with conceptually.

Check back in on Zig after another decade.

Programming with it is magical, and its a huge drag to go back to languages without it. Just so much better than common OOP that depends only on the type of one special argument (self, this etc).

Common Lisp has had it forever, and Dylan transferred that to a language with more conventional syntax -- but is very near to dead now, certainly hasn't snowballed.

On the other hand Julia does it very well and seems to be gaining a lot of traction as a very high performance but very expressive and safe language.

Julia is phenomenally great for solo/small projects, but as soon as you have complex dependencies that _you_ can't update - all the overloading makes it an absolute nightmare to debug.

The tooling makes it easy to tell which version of a method you're using, though that's rarely an issue in practice. And the fact that methods are open to extension makes it really easy to fix occasional upstream bugs where the equivalent has to wait for a library maintainer in Python.

500kloc Julia over 4 years, so not a huge codebase, but not trivial either.

What Ada (and Rust) calls generics is very different -- it is like template functions in C++.

In those languages the version of the function that is selected is based on the declared type of the arguments.

In CLOS, Dylan, Julia the version of the function that is selected is based on the runtime type of the actual arguments.

Here's an example in Dylan that you can't do in Ada / Rust / C++ / Java.

    define method fib(n) fib(n-1) + fib(n-2) end;
    define method fib(n == 0) 0 end;
    define method fib(n == 1) 1 end;

The Julia version is slightly more complex.

    fib(n) = fib(Val(n))
    fib(::Val{n}) where {n} = fib(n-1) + fib(n-2)
    fib(::Val{0}) = 0
    fib(::Val{1}) = 1
    
    println(fib(30))

This of course is just a function with a single argument, but you can do the same thing across multiple arguments.

    define method ack(m, n) ack(m-1, ack(m, n-1)) end;
    define method ack(m == 0, n) n+1 end;
    define method ack(m, n == 0) ack(m-1, 1) end;

As you can see from my comment history, I am quite aware of CLOS, Lisp variants and Dylan.

>Programming with it is magical, and its a huge drag to go back to languages without it. Just so much better than common OOP that depends only on the type of one special argument (self, this etc).

Can you give one or two examples? And why is programming with it magical?

Because methods aren't "inside" objects, but just look like functions taking (references to) structs, you can add your own methods to someone else's types.

It's really hard to give a concise example that doesn't look artificial, because it's really a feature for large code bases.

Here's a tutorial example for Julia

https://scientificcoder.com/the-art-of-multiple-dispatch

The need for this jumped out at me during Writergate. People had alot of trouble understanding exactly how all the pieces fit together, and there was no good place to document that. The documentation (or the code people went to to understand it) was always on an implementation. Having an interface would have given Zig a place to hang the Reader/Writer documentation and allowed a quick way for people to understand the expectations it places on implementations without further complications.

For Zig, I don't even want it to automatically handle the vtable like other languages...I'm comfortable with the way people implement different kinds of dynamic dispatch now. All I want is a type-level construct that describes what fields/functions a struct has and nothing else. No effect on runtime data or automatic upcasting or anything. Just a way to say "if this looks like this, it can be considered this type."

I expect the argument is that it's unnecessary. Technically, it is. But Zig's biggest weakness compared to other languages is that all the abstractions have to be in the programmer's head rather than encoded in the program. This greatly hampers people's ability to jump into a new codebase and help themselves. IMO this is all that's needed to remedy that without complicating everything.

You can see how much organizational power this has by looking at the docs for Go's standard library. Ignore how Go's runtime does all the work for you...think more about how it helps make the _intent_ behind the code clear.

Initially slower but then faster after full compilation