10 ms·

Zig is one of the most interesting languages I've seen in a very long time, and possibly the first radical breakthrough in low-level programming design in decad

by pron 6y ago

Zig is one of the most interesting languages I've seen in a very long time, and possibly the first radical breakthrough in low-level programming design in decades. Maybe it will become a big success and maybe it will tank, but after having two visions for low-level programming -- that of C's "syntax-sugared Assembly", or that of C++'s "zero-cost abstractions" whose low-level, low-abstraction code appears high level on the page, once you get all the pieces to fit (Rust, while introducing the ingenious borrow checking, still firmly follows C++'s design philosophy and can be seen as a C++ that checks your work) -- Zig shows a third way by rethinking, from the ground up, how low-level programming could and should be done. It manages to address all of C++'s biggest shortcomings, which, in my view, are 1. language complexity, 2. compilation time, 3. safety -- in this order -- and it does so in a language that is arguably simpler than C, can be fully learned in a day or two (although the full implications of the design might take longer to sink in), and also inspires a new approach to partial evaluation, replacing generics and value templates, concepts/traits/typeclasses, constexprs/procedural macros, macros (or, at least, the "good parts" of macros) and conditional compilation with a single, simple feature.

skohan 6y ago
I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. I think Rust is a great, worthy language, and for a lot of use-cases it makes sense to optimize for trying to just put everything on the stack, but there are a lot of other cases where what you really want to do is own allocation by yourself instead of trusting it to the compiler. I haven't tried Zig, but I really want to see if it can deliver on this.
- whatshisface 6y ago
  Rust has manual allocation with Box<T>, it's just not as automatic as Zig. Rust's manual allocation pain is constant-factor overhead: typing out the type signatures takes longer every time you use it, but the complexity doesn't grow beyond that. I don't enjoy typing Box everywhere, but it's not that bad. https://doc.rust-lang.org/std/boxed/index.html https://doc.rust-lang.org/std/boxed/index.html
  - skohan 6y ago
    Rust allows virtually any type of memory management you want, my point is the syntax is not optimized for things like arena-based memory management or custom allocators. Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack.
    - whatshisface 6y ago
      Yes, that's quite right. For many purposes, that's helpful encouragement, but sometimes you just want a reference.
    - the_duke 6y ago
      In Zig, as far as I understand, you really just pass an allocator around. I don't see any special syntax to support this? This could be done in Rust. There is, for example, the simple bump allocator bumpalo [1]. It would be nice if the the std collections supported this (in planning, but hasn't seen much progress), and most dependencies would not be built around a manually passed allocator. > Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack. Can you clarify what you mean here? All of the std collections (Vec, HashMap, etc) use allocation. There are also `Box`, `Rc` and `Arc`, which allocate and are used everywhere. [1] https://github.com/fitzgen/bumpalo https://github.com/fitzgen/bumpalo
      - skohan 6y ago
        Again, it's not about what you are able to do in Rust vs. Zig, it's essentially about the API of the language. Zig's semantics around memory management are imperative: i.e. you are telling the compiler when to allocate and deallocate memory. Rust's are declarative: you tell the compiler how the memory for a given value should be managed, and the compiler interprets these requirements to decide when memory should be allocated or deallocated. Again, I do not think this a weakness of Rust, and I do not think it should change. In very many cases, the Rust approach is very helpful. The point is there are also cases where imperative, explicit memory management is desirable.
- dnautics 6y ago
  > I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. The new test allocator checks your code for memory leaks, use after free, and double free in a highly ergonomic fashion. I think is fantastic that zig encourages writing tests, and I think if you get full test coverage in your zig code with the test allocator, you will probably solve 99% of your memory errors. I know this is possible in C++ (see alexandrescu's allocators talk from CppCon 2017?) But I would be surprised if anyone does it.
  - fanf2 6y ago
    Address Sanitizer and valgrind are widely-used standard tools for finding allocation bugs
    - setpatchaddress 6y ago
      They are very effective, but relatively difficult to use.
      - pjmlp 6y ago
        On VS 2019, literally a checkbox away and rebuild.
      - chubot 6y ago
        They're built into both GCC and Clang and very easy to use IMO. The only hard part is figuring out how to pass -fsanitize=address into your compiler via your complex build system! And building with symbols. That is inherent to the C/C++ toolchain and not a problem that sanitizers can address.
        samatman 6y ago
        Sure but a language where "the only hard part" isn't a factor surely has a leg up on one where it is. A lot of the advantage which Zig has over C is exactly in not having to support a towering edifice of tools and hacks which is older than I am. This is true to a significant degree of Rust and C++ as well.
UncleOxidant 6y ago
Tend to agree, but I hope that the zig folks aren't biting off too much by trying to replace LLVM. Sure, I can understand some of their reasons, but LLVM provides all kinds of functionality (optimization, code lowering, targeting lots of cpus,etc.) that will be difficult and time consuming to replace. I hope this doesn't cause them to lose focus on the development of the language itself and libraries.
- Johanx64 6y ago
  *Replacing llvm in debug builds and similar where incremental build times are the most crucial Fully optimized release builds will surely still have an option to use LLVM
MrBuddyCasino 6y ago
Fully agree. There were many other attempts at building a better C, but Zig's big achievement is that it offers enough new and compelling features that sufficiently distinguishes it from C, while still managing to keep the overall complexity very low while still being familiar. That mix of "fresh, yet familiar and simple" sets it apart.
TakeOffEveryZig 6y ago
Take off every zig take of every ziiig, totally agree with you. Rust and Zig is totally the best examples of things that are happening now. I am sorry for the introduction but everyone who recognize it will. Zig and Rust is where things' at, Python and Go can go, all us old dudes use Perl anyways-
the_duke 6y ago
> and possibly the first radical breakthrough in low-level programming design in decades Can you expand what you mean here? I really like Zig, and there is definitely a big design space to explore in creating a modern low-level language that doesn't come with the complexity of something like Ada/Spark or Rust. This binary patching + daemonized compiler approach is particularly exciting. But as a language, I'm not aware of any features that would amount to a "radical breakthrough". As far as I am aware, it is a modernized, low level language, with nice compile time evaluation, async, and some runtime-provided safety guarantees. But nothing that is so novel from a type system / language design point of view. Happy to be corrected though!
- pron 6y ago
  > creating a better C I'm not sure I like the "better C" label. After all, Zig allows you to easily do stuff that's virtually impossible in C, and only possible in C++ with templates and constexprs and concepts. It also doesn't have pointer arithmetic and pervasive wild casts, so it's not a "syntax-sugared Assembly". Its only similarity to C is that it is a low-level language and that, unlike other low-level languages that aren't C -- like C++, Rust, and Ada -- not only is it not among the most complex languages in the history of software (all three of those have probably secured their places in the top-five), but it is probably among the simplest. > I'm not aware of any features that would amount to a "radical breakthrough". As far as I am aware, it is a modernized C, with nice compile time evaluation, async, and some runtime-provided safety guarantees. But nothing that is novel from a type system / language design point of view. AFAIK, general partial evaluation with introspection as a single mechanism to do the work of generics, typeclasses/traits/concepts, value templates, macros, and conditional compilation -- combined with a general error reporting mechanism that is shared between runtime and compile-time -- has never been attempted before. It is revolutionary.
  - the_duke 6y ago
    > I'm not sure I like the "better C" label. I agree that Zig is more than a "better C", and I edited my comment. Regarding `comptime`: I haven't fully grokked it, but it looks very similar to the capabilities of D (and in part Nim). Do you by chance know those languages and can give a comparison? (Languages like Idris also allow to express a lot at compile time, but that's quite a different domain)
jimbob45 6y ago
Wait doesn’t Zig compete with C, not C++? IIRC it doesn’t have any intuitive form of typeclasses.
- pron 6y ago
  comptime combined with introspection gives you something similar to generics and typeclasses.
- discreteevent 6y ago
  This claims to do runtime dynamic dispatch with interfaces: https://github.com/alexnask/interface.zig https://github.com/alexnask/interface.zig
  - alexnask 6y ago
    Note that this is still very much a WIP :) I guess I should also mention my inspiration, the C++ dyno library (https://github.com/ldionne/dyno https://github.com/ldionne/dyno) I don't really see how this is relevant to typeclasses though ^^
  - jimbob45 6y ago
    I need it to be a first-class feature because I’m a baby. My #1 complaint with C++ is that they make everything a lower-class feature to avoid breaking backwards compatibility and it makes the language more verbose, less enjoyable, and less intuitive. All that said, I’m personally okay with the decision to omit typeclasses since the language is meant to compete with C, not C++.
    - pron 6y ago
      I think Zig competes with C++, too. But to match the expressivity of C++ you don't necessarily need to have the exact same features. C++ gives you control over generics with concepts, and Zig does it differently -- with introspection, which is very much a first-class feature. If Zig wanted to achieve what other languages do in the same way they do it, it wouldn't be radical. Instead, it offers a different way. When comparing two languages, especially those designed with drastically different aesthetics, you don't ask how easily can an expression in one language be translated to the other, but how easy it is to achieve similar general goals.
sai_c 6y ago
At this point in time, i agree with this analysis. But what for a C programmer (systems/embedded) remains to be seen, is, if any of the new languages (say for example Rust, Zig, Odin) can (or want to) offer one of C's strengths most language designers do not think of (at least it looks to me like that). And this would be for me "leave the language alone (for the most part)". If i may quote from Zig's website (https://ziglang.org/#Small-simple-language https://ziglang.org/#Small-simple-language): "Focus on debugging your application rather than debugging your programming language knowledge." I have yet so see a community driven language that fulfills this promise in a comparable way to C's. There's always "this little feature" necessary, or "this cruft to clean up". You name it i've seen it. If you want people like me (and trust me HN community, there's a GIANT silent majority out there) to use Zig e.a. for production in the embedded and systems space where product lifecycles are counted in decades, you will have to provide this feature. Sure, you can call me a dinosaur (still under 40 :-)), or a BLUB programmer or what not. But language designers wanting to (slowly) put C to rest, should, imho, not forget about this "feature". In this space you really want to focus on the real problems, not on problems of keeping up with the latest and greatest. Side note for all the "if all you know is a hammer" responses: Please don't compare programming languages with tools. This is a bad analogy. Programming languages are more like materials. Once chosen and the product (the source code) built, you cannot simply change it without starting from scratch and a new product (new source code). So, downvotes, here i come ;-).
- cashsterling 6y ago
  My 0.02... and have an upvote for stating your opinion. C is not going any where.. we all know that. But it is not the best tool for accomplishing many systems programming tasks. IMO, this has probably been true since Ada95. Ada2012/SPARK, Rust, and probably Zig make this even more clear. For some domains, C was the ONLY tool available... e.g. C is/was the only language with board-level support and an available compiler. At my place of work, we presently use C for embedded code because it is best supported for the microprocessor we are using... but we'd rather use Rust, Ada, or Zig. we may explore using Nim to generate C with static-only allocation.
  - 6y ago
disown 6y ago
> Zig shows a third way by rethinking, from the ground up, how low-level programming could and should be done. I don't know about that. "that of C's "syntax-sugared Assembly" is pretty much how most people want to do system programming. Don't systems programmers want to be as close to assembly without delving into the pain that is assembly? Also, I don't know how "ground up" it is. Seems like zig is just more syntactic sugar on top of C to me. Wasn't there a big push for D to supplant C/C++ a while back. Now Rust has joined the fray. Why would Zig succeed when D failed and Rust is failing? What is it that Zig offers that D or Rust doesn't? And does that justify the migration of legions of C programmers and mountains of C code to Zig?
stormbrew 6y ago
> also inspires a new approach to partial evaluation, replacing generics and value templates, concepts/traits/typeclasses, constexprs/procedural macros, macros (or, at least, the "good parts" of macros) and conditional compilation with a single, simple feature. So, zig is new to me but looking at an overview of the feature in question here this feels pretty hyperbolic? I certainly agree that the approach it takes is syntactically less noisy than angle-bracket generics/templates (which I dislike quite a lot) but it doesn't seem particularly revolutionary vs. the way evaluation of types in haskell works, for eg. A function that produces a type based on type arguments is roughly a typeclass. And the intermediate products of a function with comptime arguments are still pretty much semantically equivalent to a C++ template anyways, just with the arguments in a different place. It is cool, and I like the angle it takes, but it seems more synthesis than revolution to me. Am I missing something?
- dnautics 6y ago
  It's not super revolutionary. Other languages (like elixir) have something similar.

by pron 6y ago

skohan 6y ago

I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. I think Rust is a great, worthy language, and for a lot of use-cases it makes sense to optimize for trying to just put everything on the stack, but there are a lot of other cases where what you really want to do is own allocation by yourself instead of trusting it to the compiler. I haven't tried Zig, but I really want to see if it can deliver on this.

whatshisface 6y ago
Rust has manual allocation with Box<T>, it's just not as automatic as Zig. Rust's manual allocation pain is constant-factor overhead: typing out the type signatures takes longer every time you use it, but the complexity doesn't grow beyond that. I don't enjoy typing Box everywhere, but it's not that bad. https://doc.rust-lang.org/std/boxed/index.html https://doc.rust-lang.org/std/boxed/index.html
- skohan 6y ago
  Rust allows virtually any type of memory management you want, my point is the syntax is not optimized for things like arena-based memory management or custom allocators. Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack.
  - whatshisface 6y ago
    Yes, that's quite right. For many purposes, that's helpful encouragement, but sometimes you just want a reference.
  - the_duke 6y ago
    In Zig, as far as I understand, you really just pass an allocator around. I don't see any special syntax to support this? This could be done in Rust. There is, for example, the simple bump allocator bumpalo [1]. It would be nice if the the std collections supported this (in planning, but hasn't seen much progress), and most dependencies would not be built around a manually passed allocator. > Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack. Can you clarify what you mean here? All of the std collections (Vec, HashMap, etc) use allocation. There are also `Box`, `Rc` and `Arc`, which allocate and are used everywhere. [1] https://github.com/fitzgen/bumpalo https://github.com/fitzgen/bumpalo
    - skohan 6y ago
      Again, it's not about what you are able to do in Rust vs. Zig, it's essentially about the API of the language. Zig's semantics around memory management are imperative: i.e. you are telling the compiler when to allocate and deallocate memory. Rust's are declarative: you tell the compiler how the memory for a given value should be managed, and the compiler interprets these requirements to decide when memory should be allocated or deallocated. Again, I do not think this a weakness of Rust, and I do not think it should change. In very many cases, the Rust approach is very helpful. The point is there are also cases where imperative, explicit memory management is desirable.
dnautics 6y ago
> I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. The new test allocator checks your code for memory leaks, use after free, and double free in a highly ergonomic fashion. I think is fantastic that zig encourages writing tests, and I think if you get full test coverage in your zig code with the test allocator, you will probably solve 99% of your memory errors. I know this is possible in C++ (see alexandrescu's allocators talk from CppCon 2017?) But I would be surprised if anyone does it.
- fanf2 6y ago
  Address Sanitizer and valgrind are widely-used standard tools for finding allocation bugs
  - setpatchaddress 6y ago
    They are very effective, but relatively difficult to use.
    - pjmlp 6y ago
      On VS 2019, literally a checkbox away and rebuild.
    - chubot 6y ago
      They're built into both GCC and Clang and very easy to use IMO. The only hard part is figuring out how to pass -fsanitize=address into your compiler via your complex build system! And building with symbols. That is inherent to the C/C++ toolchain and not a problem that sanitizers can address.
      - samatman 6y ago
        Sure but a language where "the only hard part" isn't a factor surely has a leg up on one where it is. A lot of the advantage which Zig has over C is exactly in not having to support a towering edifice of tools and hacks which is older than I am. This is true to a significant degree of Rust and C++ as well.

UncleOxidant 6y ago

Tend to agree, but I hope that the zig folks aren't biting off too much by trying to replace LLVM. Sure, I can understand some of their reasons, but LLVM provides all kinds of functionality (optimization, code lowering, targeting lots of cpus,etc.) that will be difficult and time consuming to replace. I hope this doesn't cause them to lose focus on the development of the language itself and libraries.

Johanx64 6y ago
*Replacing llvm in debug builds and similar where incremental build times are the most crucial Fully optimized release builds will surely still have an option to use LLVM

MrBuddyCasino 6y ago

Fully agree. There were many other attempts at building a better C, but Zig's big achievement is that it offers enough new and compelling features that sufficiently distinguishes it from C, while still managing to keep the overall complexity very low while still being familiar. That mix of "fresh, yet familiar and simple" sets it apart.

TakeOffEveryZig 6y ago

Take off every zig take of every ziiig, totally agree with you. Rust and Zig is totally the best examples of things that are happening now. I am sorry for the introduction but everyone who recognize it will. Zig and Rust is where things' at, Python and Go can go, all us old dudes use Perl anyways-

the_duke 6y ago

> and possibly the first radical breakthrough in low-level programming design in decades Can you expand what you mean here? I really like Zig, and there is definitely a big design space to explore in creating a modern low-level language that doesn't come with the complexity of something like Ada/Spark or Rust. This binary patching + daemonized compiler approach is particularly exciting. But as a language, I'm not aware of any features that would amount to a "radical breakthrough". As far as I am aware, it is a modernized, low level language, with nice compile time evaluation, async, and some runtime-provided safety guarantees. But nothing that is so novel from a type system / language design point of view. Happy to be corrected though!

pron 6y ago
> creating a better C I'm not sure I like the "better C" label. After all, Zig allows you to easily do stuff that's virtually impossible in C, and only possible in C++ with templates and constexprs and concepts. It also doesn't have pointer arithmetic and pervasive wild casts, so it's not a "syntax-sugared Assembly". Its only similarity to C is that it is a low-level language and that, unlike other low-level languages that aren't C -- like C++, Rust, and Ada -- not only is it not among the most complex languages in the history of software (all three of those have probably secured their places in the top-five), but it is probably among the simplest. > I'm not aware of any features that would amount to a "radical breakthrough". As far as I am aware, it is a modernized C, with nice compile time evaluation, async, and some runtime-provided safety guarantees. But nothing that is novel from a type system / language design point of view. AFAIK, general partial evaluation with introspection as a single mechanism to do the work of generics, typeclasses/traits/concepts, value templates, macros, and conditional compilation -- combined with a general error reporting mechanism that is shared between runtime and compile-time -- has never been attempted before. It is revolutionary.
- the_duke 6y ago
  > I'm not sure I like the "better C" label. I agree that Zig is more than a "better C", and I edited my comment. Regarding `comptime`: I haven't fully grokked it, but it looks very similar to the capabilities of D (and in part Nim). Do you by chance know those languages and can give a comparison? (Languages like Idris also allow to express a lot at compile time, but that's quite a different domain)

jimbob45 6y ago

Wait doesn’t Zig compete with C, not C++? IIRC it doesn’t have any intuitive form of typeclasses.

pron 6y ago
comptime combined with introspection gives you something similar to generics and typeclasses.
discreteevent 6y ago
This claims to do runtime dynamic dispatch with interfaces: https://github.com/alexnask/interface.zig https://github.com/alexnask/interface.zig
- alexnask 6y ago
  Note that this is still very much a WIP :) I guess I should also mention my inspiration, the C++ dyno library (https://github.com/ldionne/dyno https://github.com/ldionne/dyno) I don't really see how this is relevant to typeclasses though ^^
- jimbob45 6y ago
  I need it to be a first-class feature because I’m a baby. My #1 complaint with C++ is that they make everything a lower-class feature to avoid breaking backwards compatibility and it makes the language more verbose, less enjoyable, and less intuitive. All that said, I’m personally okay with the decision to omit typeclasses since the language is meant to compete with C, not C++.
  - pron 6y ago
    I think Zig competes with C++, too. But to match the expressivity of C++ you don't necessarily need to have the exact same features. C++ gives you control over generics with concepts, and Zig does it differently -- with introspection, which is very much a first-class feature. If Zig wanted to achieve what other languages do in the same way they do it, it wouldn't be radical. Instead, it offers a different way. When comparing two languages, especially those designed with drastically different aesthetics, you don't ask how easily can an expression in one language be translated to the other, but how easy it is to achieve similar general goals.

sai_c 6y ago

At this point in time, i agree with this analysis. But what for a C programmer (systems/embedded) remains to be seen, is, if any of the new languages (say for example Rust, Zig, Odin) can (or want to) offer one of C's strengths most language designers do not think of (at least it looks to me like that). And this would be for me "leave the language alone (for the most part)". If i may quote from Zig's website (https://ziglang.org/#Small-simple-language https://ziglang.org/#Small-simple-language): "Focus on debugging your application rather than debugging your programming language knowledge." I have yet so see a community driven language that fulfills this promise in a comparable way to C's. There's always "this little feature" necessary, or "this cruft to clean up". You name it i've seen it. If you want people like me (and trust me HN community, there's a GIANT silent majority out there) to use Zig e.a. for production in the embedded and systems space where product lifecycles are counted in decades, you will have to provide this feature. Sure, you can call me a dinosaur (still under 40 :-)), or a BLUB programmer or what not. But language designers wanting to (slowly) put C to rest, should, imho, not forget about this "feature". In this space you really want to focus on the real problems, not on problems of keeping up with the latest and greatest. Side note for all the "if all you know is a hammer" responses: Please don't compare programming languages with tools. This is a bad analogy. Programming languages are more like materials. Once chosen and the product (the source code) built, you cannot simply change it without starting from scratch and a new product (new source code). So, downvotes, here i come ;-).

cashsterling 6y ago
My 0.02... and have an upvote for stating your opinion. C is not going any where.. we all know that. But it is not the best tool for accomplishing many systems programming tasks. IMO, this has probably been true since Ada95. Ada2012/SPARK, Rust, and probably Zig make this even more clear. For some domains, C was the ONLY tool available... e.g. C is/was the only language with board-level support and an available compiler. At my place of work, we presently use C for embedded code because it is best supported for the microprocessor we are using... but we'd rather use Rust, Ada, or Zig. we may explore using Nim to generate C with static-only allocation.
- 6y ago

disown 6y ago

> Zig shows a third way by rethinking, from the ground up, how low-level programming could and should be done. I don't know about that. "that of C's "syntax-sugared Assembly" is pretty much how most people want to do system programming. Don't systems programmers want to be as close to assembly without delving into the pain that is assembly? Also, I don't know how "ground up" it is. Seems like zig is just more syntactic sugar on top of C to me. Wasn't there a big push for D to supplant C/C++ a while back. Now Rust has joined the fray. Why would Zig succeed when D failed and Rust is failing? What is it that Zig offers that D or Rust doesn't? And does that justify the migration of legions of C programmers and mountains of C code to Zig?

stormbrew 6y ago

> also inspires a new approach to partial evaluation, replacing generics and value templates, concepts/traits/typeclasses, constexprs/procedural macros, macros (or, at least, the "good parts" of macros) and conditional compilation with a single, simple feature. So, zig is new to me but looking at an overview of the feature in question here this feels pretty hyperbolic? I certainly agree that the approach it takes is syntactically less noisy than angle-bracket generics/templates (which I dislike quite a lot) but it doesn't seem particularly revolutionary vs. the way evaluation of types in haskell works, for eg. A function that produces a type based on type arguments is roughly a typeclass. And the intermediate products of a function with comptime arguments are still pretty much semantically equivalent to a C++ template anyways, just with the arguments in a different place. It is cool, and I like the angle it takes, but it seems more synthesis than revolution to me. Am I missing something?

dnautics 6y ago
It's not super revolutionary. Other languages (like elixir) have something similar.