Zig has taken an aggressive stance on many things. For instance, it has no default allocator, no compiler warnings, variable shadowing is a compile error, no function overloading, no operator overloading, etc. And all of these decisions have pages and pages of discussion and justification.
But hey, let's keep talking about the one that is the most trivial.
Think about this. You tell your supervisors to check out zig. They ask why it doesn't work with the small program and compiler options they copied from the website. How would you explain that to them? Are you going to try to convince them that ignoring a character is a problem and that the time they spent wondering why it doesn't work is justified?
It's kind of funny to me though that there's an actual language out there where you can do use-after-free and all sorts of other C-level stuff but can't use tabs.
If you haven't heard of it: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Highlight:
> Wanna know one [programming language] that doesn’t [have this problem]? Java. I know right? How often do you get to say, “Yeah, Java is the one that really does this right.”? But there you go. In their defense, they are actively trying to correct this oversight by moving to futures and async IO. It’s like a race to the bottom.
Zig isn't avoiding it; it's impossible to avoid. Zig is just inferring the async-ness of the function automatically without you needing to write a keyword for it.
Anyway, here's a nitpick. In this release they've removed varargs, and now this is how a printf call looks like in zig:
std.debug.warn("{}+{} is {}\n", .{1, 1, 1 + 1});
In the previous release (0.5.0) one didn't need the .{}, but instead integer literals needed explicit casts, because the vararg implementation was limited:
std.debug.warn("{}+{} is {}\n", i32(1), i32(1), i32(1 + 1));
printf("%d+%d is %d\n", 1, 1, 1 + 1);
PS. I'm also surprised to find out that zig seems to take 2.6 seconds to compile the above example.
I think the real gotchas are that { is escaped as {{ and } as }} instead of \{ and \} (though it does follow from the old %%) and you must either include , .{} or rewrite the function call to something significantly different to do unformatted print.
Unfortunately it is still very much the 0.x the name implies. Taking the above example defining 2 u129 or larger and trying to multiply them results in an error while compiling about it not being supported yet. Packed struct items that cross word boundaries result in a broken struct that contains a size larger than the data (which breaks pretty much all code that tries to use it due to size/type checking). Also due to comptime being as big of an idea as it is not everything works quite yet like const example: f64 = std.math.sin(4) * std.math.sin(2) being a compile time error since sin isn't defined for comptime floats yet.
Like I said it's definitely fun to play with but it's still quite a few releases away from "is this a compiler bug or did the documentation skim over something I'm just supposed to know" no longer being a problem so if that's not your cup of tea best to just watch the release notes over the next year or two.
My experience is mostly in Go and Java and I've dabbled in C a couple of times, but I found Zig the language quite easy to understand.
Things I like the most about Zig (for now, I haven't tried everything): * error handling * optionals * tagged unions * meta programming * zig fmt
The API documentation of the std lib is still sparse though, I find it's best to search directly in the code to understand how to use it.
Looking forward to try the async functionality.