Why Zig when there's already D and Rust

[nordlow]

I can't find any motivation to why Zig was invented when there's already D and Rust. Is there any in written form?

Both D and Rust have expression generics. D has particularly elegant syntax for mixing compile-time and run-time code.

[thejoshwolfe]

I just looked through the README, the website, and the introduction blog post and didn't see some of the philosophies I was expecting to find explicitly stated in those places. I'll do a brief overview here, but I think you're right that this should get more official documentation.

No hidden control flow

If Zig code doesn't look like it's jumping away to call a function, then it isn't. This means you can be sure that the following code calls only foo() and then bar(), and this is guaranteed without needing to know the types of anything:

var a = b + c.d;
foo();
bar();

D has @property functions, which are methods that you call with what looks like field access, so in the above example, c.d might call a function. Rust has operator overloading, so the + operator might call a function. D has throw/catch exceptions, so foo() might throw an exception, and prevent bar() from being called. (Of course, even in Zig foo() could deadlock and prevent bar() from being called, but that can happen in any Turing-complete language.)

The purpose of this design decision is to improve readability.

No hidden allocations

More generally, have a hands-off approach when it comes to heap allocation. There is no new keyword or any other language feature that uses a heap allocator (e.g. string concatenation operator[1]). The entire concept of the heap is strictly in userspace. There are some standard library features that provide and work with heap allocators, but those are optional standard library features, not built into the language itself. If you never initialize a heap allocator, then you can be sure your program is never going to cause heap allocations.

Zig's standard library is still very young, but the goal is for every feature that uses an allocator to accept an allocator at runtime, or possibly at either compile time or runtime.

The motivation for this design philosophy is to enable users to write any manner of custom allocator strategy they find necessary, instead of forcing them or even encouraging them into a particular strategy that may not suitable for their needs. For example, Rust seems to encourage a single global allocator strategy, which is not suitable for many usecases such as OS development and high-performance game development. Zig is taking cues from Jai's stance on allocators, since that language is being developed by a high-performance game designer for the usecase of high-performance games.

As stated before, this topic is still a bit fuzzy, and will become more concrete as the Zig standard library matures. The important thing is that heap allocation be a userspace concept, and not built into the language.

Needless to say, there is no builtin garbage collector, like in Go.

[1]: Actually there is a string concatenation operator (generally an array concatenation operator), but it only works at compile time, so there's still no runtime heap allocation with that.

First-class support for no standard library

This was covered a bit in the documents I referenced above, but it's worth repeating again. Zig has an entirely optional standard library that only gets compiled into your program if you use it. Zig has roughly equal support for either linking against libc or not linking against it. Zig wants to be friendly to bare-metal and high-performance development.

I must admit I've never tried to make bare metal applications in Rust or D, so I'm not sure how Zig compares with those languages on this topic, but I mention it here because it's generally an usual thing for languages to target.

[nordlow]

Ok, thanks. I especially like the concise syntax for maybe/error types.

[Immortalin]

@thejoshwolfe can the standard library be designed to minimise use of syscalls? It would be great if the stdlib can be bootstrapped by defining a few primitives. Making the runtime easily bootstrapable/generic would be really nice since pretty much every other programming language requires rewriting the entire standard library when doing OS development due to the lack of malloc, stdio etc. Imagine how much easier OS Dev would be if there's a "zig runtime function stubs" file with perhaps twenty primitives. Once the user fills them out, they would be able to do OS Dev with full access to the stdlib

[andrewrk]

I would agree with everything @thejoshwolfe said, and add a few things:

A Portable Language for Libraries

One of the holy grails of programming is code reuse. Sadly, in practice, we find ourselves re-inventing the wheel many times over again. Often it's justified.

• If an application has real-time requirements, then any library that uses garbage collection or any other non-deterministic behavior is disqualified as a dependency.
• If a language makes it too easy to ignore errors, and thus to verify that a library correctly handles and bubbles up errors, it can be tempting to ignore the library and re-implement it, knowing that one handled all the relevant errors correctly. Zig is designed such that the laziest thing a programmer can do is handle errors correctly, and thus one can be reasonably confident that a library will properly bubble errors up.
• Currently it is pragmatically true that C is the most versatile and portable language. Any language that does not have the ability to interact with C code risks obscurity. Zig is attempting to become the new portable language for libraries by simultaneously making it straightforward to conform to the C ABI for external functions, and introducing safety and language design that prevents common bugs within the implementations.

A Package Manager and Build System for Existing Projects

Zig is a programming language, but it also ships with a build system and package manager that are intended to be useful even in the context of a traditional C/C++ project. (Reminder: we're not at the first beta release yet and some of this stuff is TODO)

Not only can you write Zig code instead of C or C++ code, but you can use Zig as a replacement for autotools, cmake, make, scons, ninja, etc. And on top of this, it (will) provide a package manager for native dependencies. This build system is intended to be appropriate even if the entirety of a project's codebase is in C or C++.

System package managers such as apt-get, pacman, homebrew, and others are instrumental in end user experience. But they can be insufficient for developers' needs. A language-specific package manager can be the difference between 0 contributors and dozens. For open source projects, the difficulty of getting the project to build at all is a huge hurdle for potential contributors. For C/C++ projects, having dependencies can be fatal, especially on Windows, where there is no package manager. Even building Zig itself, most potential contributors have a difficult time with the LLVM dependency. Zig is (will be) offering a way for projects to depend on native libraries directly - without depending on the users' system package manager to have the correct version available, and in a way that is practically guaranteed for projects to build first try on any system.

So what Zig is offering here, is to replace a project's build system with a reasonable language using a declarative API for building projects, that also provides package management, and thus the ability to actually depend on other C libraries. The ability to have dependencies enables higher level abstractions, and thus the proliferation of reusable high-level code.

Simplicity

Honestly, try Rust or D first, and if that works for you, great. If you feel like these languages require you to hold a little too much complexity in your head at once, try Zig. We're going for all the beautiful simplicity of C, minus the pitfalls.

[thejoshwolfe]

@Immortalin that's an intriguing suggestion that might be more detailed than appropriate for this thread. Let's go discuss it in #324

[andrewrk]

I migrated this information to a wiki page: https://github.com/andrewrk/zig/wiki/Why-Zig-When-There-is-Already-CPP,-D,-and-Rust%3F

Feel free to continue the discussion here if there's more to bring up.

[ajbowler]

This might be an issue of its own - and might not be fully answerable until 1.0 - but as someone coming from more of a web and enterprise dev world (Java, Rails, JS, etc.), I'm pretty new and inexperienced to the world of C/C++, Rust, D, etc. where I can get right next to the memory, and haven't delved into programming at more of a lower level since I had to write C in a couple of college courses. (I confess that I've never really looked into Rust or D much before.)

Obviously because I'm not very experienced in this area of coding, it's something I'd like to get better at. I enjoy game development and have done a fair bit with Unity/C#, and your Tetris project has me really excited about trying something at a lower level.

The introductory blog post might have already answered my question, notably being pragmatic about the existing success of C, but is Zig intended to be a language that we can use without having a strong familiarity and experience with C or C++? I'm wondering if Zig would be a good candidate for a developer who isn't very good at lower level programming to help get better at it.

If it's far too early to answer a question like this, I totally get that 👍

[andrewrk]

Yes it is 100% intended to be that. The fact that the language is small, simple, and consistent makes it a great candidate to use to learn lower level programming. However, the current lack of documentation is likely to be a hurdle, and one of the next areas of focus is adding Zig By Example to the website as a documentation effort.