Live data from Hacker News

Why is Zig so cool?

nilostolte.github.io

431–440 of 527 posts

Re: Why is Zig so cool?

#431

Earlier quoted context omitted.

It's more of an in-between C and Rust than Go as it is a systems language with no built-in garbage collector for memory management. It has a lot of memory safety features, but it's not as memory safe as Rust. However, it avoids a lot of the complexity of Rust like implicit macro expansion, managing lifetimes, generics and complex trait system, etc. It also compiles much more compactly than Rust, in my experience. In…

> managing lifetimes If you are not using a GC language, you WILL be managing lifetimes. Rust just makes it explicit, when the compiler can’t prove it’s safe, which Zig, C don't really care.

A better way of saying it is that Rust makes lifetimes implicit (by default), but in some cases it is necessary to manually manage lifetimes in Rust, when there's ambiguity the compiler can't resolve on its own.

In Zig and C, it's always expected that you will explicitly manage your lifetimes. Zig uses the allocator interface to explicitly allocate new buffer or heap values and its keyword 'defer' to clean up allocated variables after the scope exits so that allocations and frees generally live next to each other.

C on the other hand, is relatively unopinionated about how lifetimes are managed. The defer keyword honestly takes most of the pain of managing lifetimes away.

Re: Why is Zig so cool?

#432
post #209

Author is apparently unaware of alternatives like Ada, Object Pascal and Modula-2, where most of those "innovations" were already available. It is kind of interesting that packaging the same ideas with a C like syntax suddenly makes them "cool", 40 years later.

I’m actually not a huge Zig person.

But yes, avoiding arcaneness for the sake of arcaneness will earn you more users.

A big success of Rust has nothing to do with systems programming or the borrow checker.

But just that it brings ML ideas to the masses without having to learn a completely new syntax and fight with idiosyncratic toolchains and design decisions.

Re: Why is Zig so cool?

#433
post #348
post #79

Earlier quoted context omitted.

I think this is a major mistake for Zig's target adoption market - low level programmers trying to use a better C. 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.

Ada has them, and I guess we all agree on its systems programming nature.

NOOOO!

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 `n == 1` is actually syntactic sugar for the type declaration `n :: singleton(1)`.

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 is perhaps a crazy way to write `fib()` instead of a conventional `if/then/else` or `?:` or switch with a default case, but kinda fun :-)

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;

Re: Why is Zig so cool?

#434
post #92

I like the idea of the `defer `keyword - you can have automatic cleanup at the end of the scope but you have to make it obvious you are doing so, no hidden execution of anything (unlike c++ destructors).

C++ doesn't have hidden execution, you just don't know the language. Once you exit scope destructor is invoked.

Re: Why is Zig so cool?

#435
post #396

Earlier quoted context omitted.

> Calling into malloc () is writing C in C++, and should only be used for backwards compatibility And this is exactly the stance I am arguing against. C++ is not the newer version of C. It forked of at some point and is a quite different language now. One of the reasons I do use malloc for, is for compatibility with C. It is not for backward compatibility, because the C code is newer. In fact I actively change the co…

So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. Finally, people like to argue between C and C++ when it convenient to do so, yet the compiler language switches to use C extensions in C++ mode keep being used across many projects.

> So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler.

What do you mean? I don't think I can follow you.

> yet the compiler language switches to use C extensions in C++ mode keep being used across many projects.

When you use compiler extensions, that just happen to be both available in C and C++, I wouldn't say you are writing C in C++, I mean the extension isn't standard C either.

Code written in C++ has different semantics, even when it is word-for-word the same as C code. They ARE different languages.

Re: Why is Zig so cool?

#436
post #6

> I can’t think of any other language in my 45 years long career that surprised more than Zig. I can say the same (although my career spans only 30 years), or, more accurately, that it's one of the few languages that surprised me most. Coming to it from a language design perspective, what surprised me is just how far partial evaluation can be taken. While strictly weaker than AST macros in expressive power (macros ar…

> hence its "zero-cost abstractions", made to give the illusion of a high-level language without its actual high-level abstraction

What does this mean?

For example (you can pick another example if you want), how is C++'s std::vector less abstract than Java's ArrayList?

Re: Why is Zig so cool?

#437
post #395
post #339

Earlier quoted context omitted.

This has nothing to do with bikeshedding, it is a genuine misunderstanding of these two languages that is propagated in this way. This is not about grammar.

Yet those complaining usually make use of plenty C constructs, data types and standard library on their C++ projects, instead of modern C++ practices.

"C-like" code in C++ still has C++ semantics. "modern C++" is a disputed paradigm, but not necessarily how things should be done. When you write C++, but not "modern C++", that doesn't mean you are writing C. There are also modern features in C. https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...

Re: Why is Zig so cool?

#439
post #6

> I can’t think of any other language in my 45 years long career that surprised more than Zig. I can say the same (although my career spans only 30 years), or, more accurately, that it's one of the few languages that surprised me most. Coming to it from a language design perspective, what surprised me is just how far partial evaluation can be taken. While strictly weaker than AST macros in expressive power (macros ar…

Great comment! I agree about comptime, as a Rust programmer I consider it one of the areas where Zig is clearly better than Rust with its two macro systems and the declarative generics language. It's probably the biggest "killer feature" of the language.

Consider that Python + C++ has proved to be a very strong combo: driver in Python, heavy lifting in C++.

It's possible that something similar might be the right path for metaprogramming. Rust's generics are simple and weaker than Zig's comptime, while proc macros are complicated and stronger than Zig's comptime.

So I think the jury's still out on whether Rust's metaprogramming is "better" than Zig's.

Re: Why is Zig so cool?

#440
post #97

Earlier quoted context omitted.

Interestingly, I just read an article from matklad (who works a lot with Zig) talking about the benefits of splitting up error codes and error diagnostics, and the pattern of using a diagnostic sync to provide human-readable diagnostic information: https://matklad.github.io/2025/11/06/error-codes-for-control... Honestly I was quite convinced by that, because it kind of matches my own experiences that, even when using…

If they want to keep to the error/diagnostic pattern I think they're gonna have to adopt some kind of standard context object that gets passed around. Passing an allocator, an IO implementation, and a diagnostic object all over your code base is going to get really fucking old.

if it helps: it's pretty typical to attach the allocator to the object directly, so you dont have to pass it everywhere. for library consumers, just build a global allocator and use that. io will just "have to be passed the annoying way" in libraries (but a consumer can also also easily globalize that).
Post reply on HN