5 ms·

Can someone give me an elevator-pitch for Zig? When would I use it? Is it worth checking out in 2021?

by kello 5y ago

enriquto 5y ago
> Can someone give me an elevator-pitch for Zig? The main page ziglang.com makes a good job at that: A simple language: * No hidden control flow. * No hidden memory allocations. * No preprocessor, no macros. Compile time goodness: * Call any function at compile-time. * Manipulate types as values without runtime overhead. * Comptime emulates the target architecture. Close to C and C++: * Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box. * Add a Zig compilation unit to C/C++ projects; cross-language LTO is enabled by default.
- woodrowbarlow 5y ago
  comptime is hard to grasp from that blurb. for c programmers, here's a good example: you know how gcc will usually optimize `memcpy(dest, src, strlen("hello"))` to just `memcpy(dest, src, 5)` -- because it knows how strlen works, and in this case all the inputs are known at compile time? well, in zig, if a function is pure and all of its inputs are known at compile time, the compiler will always run the function at compile time and replace the function call with the result. you can also add the keyword `comptime` to force this behavior on a per-statement basis. so comptime gives you conditional compilation and also results in more optimized code. coupled with zig's import system, this eliminates the need for a preprocessor. perhaps more interestingly: even types can be comptimed... which gives you generics 'for free'. edit: removed inaccurate assumption regarding qemu
  - ifreund 5y ago
    > it actually builds a stub program and runs it in qemu for your target arch That's not at all how the implementation works, the zig compiler does not depend on qemu. The comptime evaluation works much more like evaluating an interpreted language such as python.
  - AnIdiotOnTheNet 5y ago
    To provide a simple example of how comptime is used for generics in Zig, consider the ArrayList. Idiomatic Zig code uses TitleCase for types, but ArrayList is technically a function with the signature `ArrayList(comptime T: type) type`. Given the type `T` as an argument, it returns a new type `ArrayList(T)` that implements the ArrayList for `T`. You can initialize a new ArrayList of `Foo`s like this: `var list = ArrayList(Foo).init(allocator);`. No second macro language, no magic variables, no special syntax.
cturtle 5y ago
Zig is a general purpose language with no hidden control flow, powerful compile time metaprogramming, and easy cross-compilation and interop with C code. For me it hits the sweet spot of fixing major problems in C, while staying small, consistent, and easy to fit the language inside my head unlike C++ or Rust. Also absolutely loving the compile time evaluation and type syntax.
- Calamitous 5y ago
  Interesting. I keep seeing marketing on “no hidden flow control”, but I’m curious what flow control is being hidden in other languages? Are they talking about exception handling?
  - e12e 5y ago
    See: https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-control-flow https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-cont... I'd venture a guess that exceptions might be the "least bad" here, and things like "a + b" resulting in "a. plus(b)" is considered worse. At any rate they seem to want jumps/calls to be visible/obvious.
  - cturtle 5y ago
    Operator overloading, constructors, destructors, exceptions, etc. This page [0] is good for comparing Zig to other languages. And this [1] is a nice overview of the language. One reason I think "no hidden control flow" is used so much when talking about Zig, is because Zig wants code to be easy to read, including understanding what is happening behind the scenes. Zig also has no hidden allocations (a function call will not allocate unless given an allocator) which fits this model. [0]: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/ [1]: https://ziglang.org/learn/overview/ https://ziglang.org/learn/overview/
ksec 5y ago
A Better C. But It doesn't provide memory safety like Rust.
- deleted 5y ago
  [deleted]
- e12e 5y ago
  I think I'd call it a better and safer C - stricter overflow/undefined behavior than C (sometimes similar to rust unsafe) - and some help with eg pointers: https://ziglang.org/learn/overview/#optional-type-instead-of-null-pointers https://ziglang.org/learn/overview/#optional-type-instead-of... Not as safe as rust, perhaps - but not "violently unsafe" either?
blippage 5y ago
I discovered Zig a few days ago. I'm evaluating it for use with my STM32 microcontroller. A few observations: * it cross-compiles to other architectures without any extra libraries required. The chances are that you've already installed the GNU cross-compiler tools, but it's a nice touch to have an all-in-one solution. * you can split memory into bitfields. This is useful for microcontrollers, where different parts of a 32-bit register do different things. The compiler can check the field widths, too. C++ does have bitfields, but AFAIK, it doesn't give guarantees as to exactly how the bits might be packed. * I can have a single registers file, that lays out the memory map of the microcontroller, somewhere in my path. In C, vendor-supplied libraries tend to have definitions all over the place, so a single file is a bonus. * a module system. You write the build script in Zig itself. * no macros, but it can perform compile-time execution. I've been wondering if compile-time execution actually provides a whole new way of thinking about programming. * async/await/suspend/resume. Ooo, a way of doing cooperative programming baked into the language itself. Seems very handy for microcontrollers * a library system that is part of the language. This means that you could write bare-metal systems, and it will give you things like maps and list. You don't have to try to integrate third-party libraries like newlib. Presumably it doesn't all work out of the box, though. I've not delved into the mechanics of it yet. There are plenty of other things of well, but those are the ones that jumped out at me if you're interested in system-level work. Zig is squarely aimed at C, a kind of "C done right". The syntax is fairly intuitive to understand. In terms of size, there's virtually a one-to-one translation between C and Zig. Zig aims for correctness and transparency, although it isn't as strict as Rust. To give perhaps one example, C99 introduced flexible array members, so you could do stuff like ``` void func(int n) { int arr[n]; } ``` And the question is: where/how is the memory allocated for arr? The answer is: probably on the heap. If you're using a microcontroller, though, heap allocation might be a big no-no. You need a memory allocator for starters, and you have to worry about memory fragmentation on resource-constrained systems. Zig takes the philosophy, if I can put words in the developers mouths, of having a strong dislike of "stuff going on under the hood" that you don't know about. They take and ability to reason about what the code does seriously.
- hawski 5y ago
  Isn't your example code a stack allocated array? Flexible array members would rather be: struct Foo { int len; int data[]; } *foo = malloc(sizeof(struct Foo) + n*sizeof(foo->data[0])); foo->len=n;
hansvm 5y ago
Zig makes it easy to write correct, reusable, low-level code. Correctness: Zig (compared to C) introduced defer, errdefer, optional types, exhaustive switch statements, comptime, error sets, .... These have comparable succinctness to how error handling, null checking, macros and whatnot would be done in C, but they allow the compiler to check your work. Moreover, you gain some small optimizations because the compiler can infer intent a bit better (e.g., eliding null-checks on non-optional pointers). Reusable: Zig operates on a principle of least power. If you don't need libc you don't link it. If you don't need an OS you don't depend on syscalls. If you don't need to use a specific memory allocator you pass one in as an argument. If you don't need a stack you don't set one up. Because of this, nearly the entire standard library can be used in UEFI apps, WASM modules, embedded unikernels, and all kinds of places where you'd be fighting against a typical C/C++/whatever toolchain. Reusable: Comptime simplifies a lot of parts of the language design. It allows for easy generics (e.g., writing a maximum(a,b) macro in C that behaves correctly requires a ton of boilerplate or compiler-specific preprocessor extensions that don't even exist in any form in every major C compiler). It also allows you to write things like lookup tables and embedded data in Zig itself, rather than copy/paste/fat-fingering from another tool as part of your build process. Then those functions that generate your tables are testable and can be reused elsewhere. Low-level: Much like C you have nearly complete control of the machine. You can easily override the _start symbol, drop into assembly, edit your favorite memory directly, set up dual stacks to trampoline your function calls against, call into any C library, present a C interface to Python, etc. Some low-level tasks like register bit-banging are way easier because the packed struct interface allows you to manipulate packed fields directly rather than shifting and masking your way to the right answer. I'd reach for Zig any time I would have formerly reached for C, especially in any kind of atypical (embedded, no libc, no filesystem, ...) scenarios. I personally also don't find the high-level features of C++ and whatnot worth it compared to their downsides most of the time, so if I don't want something like Python/Perl/Javascript then I'm usually inclined to drop down as far as C (now Zig) anyway unless I have a good reason to do otherwise (like using the EGG library in Rust). Is it worth checking out in 2021? Well, it hasn't hit 1.0, still has bugs, and isn't perfect. I'd be careful which production systems I ran on it. That said, I've had a blast using Zig for FUSE programs, Sudoku solvers, and all kinds of things. Give it a shot.

Can someone give me an elevator-pitch for Zig? When would I use it? Is it worth checking out in 2021?

by kello 5y ago

Can someone give me an elevator-pitch for Zig? When would I use it? Is it worth checking out in 2021?

> Can someone give me an elevator-pitch for Zig? The main page ziglang.com makes a good job at that: A simple language: * No hidden control flow. * No hidden memory allocations. * No preprocessor, no macros. Compile time goodness: * Call any function at compile-time. * Manipulate types as values without runtime overhead. * Comptime emulates the target architecture. Close to C and C++: * Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box. * Add a Zig compilation unit to C/C++ projects; cross-language LTO is enabled by default.

woodrowbarlow 5y ago
comptime is hard to grasp from that blurb. for c programmers, here's a good example: you know how gcc will usually optimize `memcpy(dest, src, strlen("hello"))` to just `memcpy(dest, src, 5)` -- because it knows how strlen works, and in this case all the inputs are known at compile time? well, in zig, if a function is pure and all of its inputs are known at compile time, the compiler will always run the function at compile time and replace the function call with the result. you can also add the keyword `comptime` to force this behavior on a per-statement basis. so comptime gives you conditional compilation and also results in more optimized code. coupled with zig's import system, this eliminates the need for a preprocessor. perhaps more interestingly: even types can be comptimed... which gives you generics 'for free'. edit: removed inaccurate assumption regarding qemu
- ifreund 5y ago
  > it actually builds a stub program and runs it in qemu for your target arch That's not at all how the implementation works, the zig compiler does not depend on qemu. The comptime evaluation works much more like evaluating an interpreted language such as python.
- AnIdiotOnTheNet 5y ago
  To provide a simple example of how comptime is used for generics in Zig, consider the ArrayList. Idiomatic Zig code uses TitleCase for types, but ArrayList is technically a function with the signature `ArrayList(comptime T: type) type`. Given the type `T` as an argument, it returns a new type `ArrayList(T)` that implements the ArrayList for `T`. You can initialize a new ArrayList of `Foo`s like this: `var list = ArrayList(Foo).init(allocator);`. No second macro language, no magic variables, no special syntax.

cturtle 5y ago

Zig is a general purpose language with no hidden control flow, powerful compile time metaprogramming, and easy cross-compilation and interop with C code. For me it hits the sweet spot of fixing major problems in C, while staying small, consistent, and easy to fit the language inside my head unlike C++ or Rust. Also absolutely loving the compile time evaluation and type syntax.

Calamitous 5y ago
Interesting. I keep seeing marketing on “no hidden flow control”, but I’m curious what flow control is being hidden in other languages? Are they talking about exception handling?
- e12e 5y ago
  See: https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-control-flow https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-cont... I'd venture a guess that exceptions might be the "least bad" here, and things like "a + b" resulting in "a. plus(b)" is considered worse. At any rate they seem to want jumps/calls to be visible/obvious.
- cturtle 5y ago
  Operator overloading, constructors, destructors, exceptions, etc. This page [0] is good for comparing Zig to other languages. And this [1] is a nice overview of the language. One reason I think "no hidden control flow" is used so much when talking about Zig, is because Zig wants code to be easy to read, including understanding what is happening behind the scenes. Zig also has no hidden allocations (a function call will not allocate unless given an allocator) which fits this model. [0]: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/ [1]: https://ziglang.org/learn/overview/ https://ziglang.org/learn/overview/

ksec 5y ago

A Better C. But It doesn't provide memory safety like Rust.

deleted 5y ago
[deleted]
e12e 5y ago
I think I'd call it a better and safer C - stricter overflow/undefined behavior than C (sometimes similar to rust unsafe) - and some help with eg pointers: https://ziglang.org/learn/overview/#optional-type-instead-of-null-pointers https://ziglang.org/learn/overview/#optional-type-instead-of... Not as safe as rust, perhaps - but not "violently unsafe" either?

blippage 5y ago

I discovered Zig a few days ago. I'm evaluating it for use with my STM32 microcontroller. A few observations: * it cross-compiles to other architectures without any extra libraries required. The chances are that you've already installed the GNU cross-compiler tools, but it's a nice touch to have an all-in-one solution. * you can split memory into bitfields. This is useful for microcontrollers, where different parts of a 32-bit register do different things. The compiler can check the field widths, too. C++ does have bitfields, but AFAIK, it doesn't give guarantees as to exactly how the bits might be packed. * I can have a single registers file, that lays out the memory map of the microcontroller, somewhere in my path. In C, vendor-supplied libraries tend to have definitions all over the place, so a single file is a bonus. * a module system. You write the build script in Zig itself. * no macros, but it can perform compile-time execution. I've been wondering if compile-time execution actually provides a whole new way of thinking about programming. * async/await/suspend/resume. Ooo, a way of doing cooperative programming baked into the language itself. Seems very handy for microcontrollers * a library system that is part of the language. This means that you could write bare-metal systems, and it will give you things like maps and list. You don't have to try to integrate third-party libraries like newlib. Presumably it doesn't all work out of the box, though. I've not delved into the mechanics of it yet. There are plenty of other things of well, but those are the ones that jumped out at me if you're interested in system-level work. Zig is squarely aimed at C, a kind of "C done right". The syntax is fairly intuitive to understand. In terms of size, there's virtually a one-to-one translation between C and Zig. Zig aims for correctness and transparency, although it isn't as strict as Rust. To give perhaps one example, C99 introduced flexible array members, so you could do stuff like ``` void func(int n) { int arr[n]; } ``` And the question is: where/how is the memory allocated for arr? The answer is: probably on the heap. If you're using a microcontroller, though, heap allocation might be a big no-no. You need a memory allocator for starters, and you have to worry about memory fragmentation on resource-constrained systems. Zig takes the philosophy, if I can put words in the developers mouths, of having a strong dislike of "stuff going on under the hood" that you don't know about. They take and ability to reason about what the code does seriously.

hawski 5y ago
Isn't your example code a stack allocated array? Flexible array members would rather be: struct Foo { int len; int data[]; } *foo = malloc(sizeof(struct Foo) + n*sizeof(foo->data[0])); foo->len=n;

hansvm 5y ago

Zig makes it easy to write correct, reusable, low-level code. Correctness: Zig (compared to C) introduced defer, errdefer, optional types, exhaustive switch statements, comptime, error sets, .... These have comparable succinctness to how error handling, null checking, macros and whatnot would be done in C, but they allow the compiler to check your work. Moreover, you gain some small optimizations because the compiler can infer intent a bit better (e.g., eliding null-checks on non-optional pointers). Reusable: Zig operates on a principle of least power. If you don't need libc you don't link it. If you don't need an OS you don't depend on syscalls. If you don't need to use a specific memory allocator you pass one in as an argument. If you don't need a stack you don't set one up. Because of this, nearly the entire standard library can be used in UEFI apps, WASM modules, embedded unikernels, and all kinds of places where you'd be fighting against a typical C/C++/whatever toolchain. Reusable: Comptime simplifies a lot of parts of the language design. It allows for easy generics (e.g., writing a maximum(a,b) macro in C that behaves correctly requires a ton of boilerplate or compiler-specific preprocessor extensions that don't even exist in any form in every major C compiler). It also allows you to write things like lookup tables and embedded data in Zig itself, rather than copy/paste/fat-fingering from another tool as part of your build process. Then those functions that generate your tables are testable and can be reused elsewhere. Low-level: Much like C you have nearly complete control of the machine. You can easily override the _start symbol, drop into assembly, edit your favorite memory directly, set up dual stacks to trampoline your function calls against, call into any C library, present a C interface to Python, etc. Some low-level tasks like register bit-banging are way easier because the packed struct interface allows you to manipulate packed fields directly rather than shifting and masking your way to the right answer. I'd reach for Zig any time I would have formerly reached for C, especially in any kind of atypical (embedded, no libc, no filesystem, ...) scenarios. I personally also don't find the high-level features of C++ and whatnot worth it compared to their downsides most of the time, so if I don't want something like Python/Perl/Javascript then I'm usually inclined to drop down as far as C (now Zig) anyway unless I have a good reason to do otherwise (like using the EGG library in Rust). Is it worth checking out in 2021? Well, it hasn't hit 1.0, still has bugs, and isn't perfect. I'd be careful which production systems I ran on it. That said, I've had a blast using Zig for FUSE programs, Sudoku solvers, and all kinds of things. Give it a shot.