What is the Big Idea of Zig?

What niche is Zig supposed to fill or what is the purpose of the language existing?

As I think I touched upon in an earlier story I wrote, Zig is meant as a full dropin replacement for C. So to use one of your examples: Kotlin is a better Java than Java. Well Zig is a better C than C.

Why does Kotlin work as a better Java than Java? Because is made to work as a dropin replacement for Java. Anywhere you can use Java, you can use Kotlin. That is because it is made to run on the JVM and follows a programming model that closely matches Java. Why is it better? Because it offers a more streamlined syntax with much better typesafety.

That is pretty much exactly what Zig offers to C. A more streamlined syntax with much better type safety. Now there is no C VM, but there is a C ABI and ways of handling resources in C. If you want a language to be a drop-in replacement for C, then it has to interface flawlessly with C and have a resource allocation an usage model which closely matches C.

Zig lets you do all this. You can easily compile in C code with your Zig programs and Zig functions can call C functions. C functions can easily call Zig functions by making them extern.

You can think of Zig as a way of fixing C. Get rid of the terrible type checking. Get rid of the terrible preprocessor, while really pushing what makes people attracted to C in the first place: The full control over what the computer is doing. Zig is taking manual memory management to the next level by building the whole standard library around the use of allocators, rather than `malloc` and `free`. That means it is in fact easier to use Zig on a microcontroller with limited resources than C itself.

In fact there is a video of a company in Sweden doing embedded programming which uses Zig in production for several projects, because Zig proved to be such a time saver:

• The easy cross compilation let them easily target all sorts of esoteric microcontrollers they had to deal with.
• Much better type checking meant they where able to deliver code with less problems than their C based solutions.
• Allocators combined with very small binaries generated for Zig allowed them to work within the confines of microcontrolles with meager resources.

If you look at Zig projects and what excites people you will see it centers a lot around stuff that requires precise control over resources and hardware. I see many emulators, e.g. for old game systems written in Zig.

I see people obsessed with multithreated performance create fine tuned solutions in Zig. E.g. on the 0.7 release on guy showed how Zig totally destroyed Go and Rust in terms of performance. Most of that was technically above my head, but my take away was that this was simply not possible to achieve in Rust, because the language restricts you much more. Zig like C gives a lot of freedom in how you do things.

Many languages have tried to be sort of a replacement for C, but most have really failed. Go e.g. as I mentioned before was a first good try, but garbage collection, large binaries and lack of ability to link easily with C doesn’t make it a good candidate.

Rust is more of a C++ replacement. It isn’t the kind of language C developers look for. Too strict type system, and a lot of high level features that don’t translate well across a C ABI.

Functional Programming

I love functional progamming and I do it all the time in Julia. However it is not a natural thing to do for C style coding. Typically you have a lot of lazy structures or stuff that gets automatically allocated. There are a lot of things typically happening under the hood.

If you want to code in a way that gives you will transparency about what resources are used, how and when, then that is not the right choice.

It all depends on what you are doing. E.g. for the kind of stuff I do when I do microcontroller programming, functional programming has no value. It is more of a problem than a benefit.

However for data science, machine learning or pretty much anything else apart from perhaps GUI programming I greately prefer a functional approach.