[Cloudef]

As someone who used C as main language, I've switched to zig. It's the only language that tries to be "better C", and not another C++. Comptime being like Nim where it's not entirely own language is also plus. I'd say it excels at general purpose system programming, and especially if you need to work with memory in detailed way (rust makes this very annoying and hard).

[DeathArrow]

What advantages does Zig have over C?

[lionkor]

- comptime, so writing compile time evaluating code, without introducing its own meta language like macros or templates.

- very solid build system (the build config file(s) are written in zig so you dont have to learn another language for the build system (looking at you, makefile)) that has crosscompilation builtin (with one compiler flag)

- language level errors, like, errors as first class citizens. forces you to handle errors, but without much mental or syntactic overhead (you can re-throw them with `try myfunction()`), also results in a unified interface

- no implicit conversions

- looks high-level (modern sytnax that is easy(ish) to parse) but as low level (or lower) than C, no abstractions that hide details you need to know about when programming (similar to C)

- C interop, so you can just add zig source files to a C project and compile it all with the zig toolchain. Zig can also parse c headers and source files and convert them, so you can include c headers and just start calling functions from there. For example, using SDL is as simple as pointing the toolchain to the SDL headers and .so file, and the sdl headers will be translated to zig on the fly so you can start with SDL.SDL_CreateWindow right away.

[GuestHNUser]

Just to name one: compile time code execution. It eliminates the need for a separate macro language and provides Zig zero cost generic types.

Not to mention memory leak detection, crazy fast compilation times, slices and a built in C compiler so your code can seamlessly integrate with an existing C code base (seriously no wrapper needed).

Zig is really really awesome. The only thing holding it back from mass adoption right now is that it's not finished yet, and that shows in the minimal documentation. That said, if you're comfortable tinkering, it's completely capable of production uses (and is already used in production in various companies).

[kunos]

> crazy fast compilation times

This is just not true and it's the reason #1 I am not using Zig. To give you some numbers, ZLS is a reasonably sized project (around 62k LOC of Zig) and on my very beefy machine it takes 14 seconds to build in debug mode and 78 seconds to build in release mode.

Because of the "single compilation unit" approach that Zig uses this means you are paying for that very same time regardless of where you modify your program.. so basically clean rebuild time is equal to simple modification time.

As a comparison my >100k LOC game in Rust takes less than 10s to build in release mode for modifications that happen not too far down the crate hierarchy.

So yeah, be for whatever reason you want (LLVM, no incremental builds and so on) as for today Zig is not even close to having "crazy fast compilation times".

[kristoff_it]

True, current compilation times with Zig are not yet optimal. We're getting there though. As our own custom backends become complete enough we will be able to enable incremental compilation and the aim is for instant rebuilds of arbitrarily large projects.

Here people can read more: https://kristoff.it/blog/zig-new-relationship-llvm/

Since that post was written we completed the transition to self-hosted and the x86_64 backend is getting close to passing all behavior tests.

[packetlost]

Namespaces.

Real enums, modules, etc.

A compile-time execution system (effectively replaces the preprocessor/macro system).

Syntax that is easier to `grep -r` for without complex regex.

Tests are a first-class citizen.

Safer type system.

Really, just a bunch of things that should've been added to C 20 years ago.

[throwawaymaths]

Zig is very pedantic about how you're using your pointers and arrays, which c desperately needed.

[ngrilly]

It’s difficult and even probably impossible to just “add” those things to C, while keeping everything else as it is.

[packetlost]

Yeah, I know...

[kristoff_it]

https://ziglang.org/learn/overview/

[iraqmtpizza]

I thought Go tried to be better C

[pjmlp]

It kind of is, for anyone without bias against languages that have a GC.

However they could at least support some kind of enumerations, one of the things they definitly aren't a better C.

[binary132]

Go is about as much like C as Java is.

[flohofwoe]

Why should there only be one "better C"? Go has a very different philosophy than Zig, but both can be considered a "better C".

[JohnDeHope]

Possibly the thing that makes C be C is that there is only one C. It is the single lingua franca of "one notch up from assembly". I would argue any language that wants to be a better C has to accept the challenge of being available on any platform, existing or future, any architecture, suitable for any bare metal use case, and it has to want to be the single obvious go-to choice. That's what it means to step into the ring of "better C" candidates. A lot of languages might offer pointers, manual memory allocation, no runtime, etc. That's cool and that gets you close to the space. But if you want to be a better C, then the bar is much higher: ubiquity.

[flohofwoe]

In general I agree, but a couple of IMHOs:

> that there is only one C

IMHO one of C's strong points is the ubiquity of non-standard compiler extensions, C with Clang extensions is much more "powerful" than standard C, personally I see C as a collection of closely related languages with a common standardized core, and you can basically pick and choose how portabel (between compilers) you want to be versus using compiler-specific extensions for low level optimization work (and in a twisted way, Zig is also a very remote member of that language family because it integrates so well with C).

> "one notch up from assembly"

C is actually a high-level language, it's only low-level when compared to other high-level languages, but much closer to those than to assembly. Arguably Zig is in some places even lower-level than C because it's stricter where C has more "wiggle room" (for instance when it comes to implicit type conversions where Zig is extremely strict).

> being available on any platform, existing or future, any architecture, suitable for any bare metal use case

Zig has a pretty good shot at that requirement, it has a good bootstrapping story, and for the worst case it has (or will have) a C and LLVM (bitcode) backend.

For me personnally, Zig will most likely never completely replace C, but instead will augment it. I expect that most of my projects will be a mix of C, C++, ObjC and Zig (and Zig makes it easy to integrate all those languages into a single project).

[marktani]

parent replied to grandparent's statement that Zig is the only language trying to be a better C