3 ms·

Zig libraries can be exported with the C ABI[0], so pretty much anything can interface with it. You can write very fast code with it. It is also small and fits

Zig libraries can be exported with the C ABI[0], so pretty much anything can interface with it. You can write very fast code with it. It is also small and fits in your head. The only thing missing is a variety of implementations, however there is a clear path to bootstrapping the compiler from source with a semi-recent C++ compiler[1] and from there, there's already a growing number of supported targets[2]. There is also a major focus on making sure cross-compilation is well supported out of the box, including C code that Zig can also compile[3]. It's perfectly fair to compare Zig to C in this case, as the project originated as a dialect of C before the author decided to do a complete clean break[4]. The primary frame of reference when designing the language was C and addressing its shortcomings, both language and tooling. [0]: https://ziglang.org/learn/overview/#export-functions-variables-and-types-for-c-code-to-depend-on https://ziglang.org/learn/overview/#export-functions-variabl... [1]: https://github.com/ziglang/zig-bootstrap https://github.com/ziglang/zig-bootstrap [2]: https://ziglang.org/download/0.8.0/release-notes.html#Support-Table https://ziglang.org/download/0.8.0/release-notes.html#Suppor... [3]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace... [4]: https://www.youtube.com/watch?v=Gv2I7qTux7g https://www.youtube.com/watch?v=Gv2I7qTux7g

Zababa 5y ago
I'll restate my point: sometimes when replacing C people want something that's just as fast but also way more safe, and in that case will usually reach out for Rust. That's what the people doing the cryptography in Python did. Rust can also expose a C ABI, you can write code as fast as C. People will often choose Rust instead of Zig because Rust has stronger guarantees about memory safety, and these guarantees are more important for them than having a language that's small and fits in your head. This is why I think talking about what you're trying to achieve is more fruitful than just talking about the language you want to replace. For example, if you want to replace C code and you don't need all of the performance in the world, you couold simply switch to a garbage collected language. In that case, since speed wasn't the most important requirement, a language that isn't usually thought as a C replacement can replace C code. If you want to make the point that Zig is "closer to C" compared to other language that wants to replace C, that's a fair claim to make.
- xhealthgothx 5y ago
  Rust is also not 'small and fits in your head', so that's yet another point it is missing in your initial set of criteria. Its main implementation and library also emits rather large binaries in the usual case. You may not find this important, but others do.
  - Zababa 5y ago
    I addressed that point: > People will often choose Rust instead of Zig because Rust has stronger guarantees about memory safety, and these guarantees are more important for them than having a language that's small and fits in your head. For some people, having a language that's small and fits in your head is not a requirement, not a priority, and sometimes not even important.
  - nicoburns 5y ago
    As others have pointed out, neither is C if you take into account avoiding UB, the preprocessor, the build systems, the many stdlib functions you need to avoid, etc. You might already know how these work, but that doesn't mean there's less to learn than a language like Rust.
- tialaramex 5y ago
  > This is why I think talking about what you're trying to achieve is more fruitful than just talking about the language you want to replace This is definitely the right approach in my opinion. Even for your garbage collection example on the one hand, in some cases your program is dominated by tricky reclamation problems and the "correct" Rust program is basically 90% garbage collector, so that an existing GC language might produce faster programs; but on the far opposite scale maybe your program has tricky non-memory resource problems and GC doesn't help at all, so the GC language has worse performance and yet it makes your problem harder to solve than in Rust anyway. One of the nice things about Rust and about C++ RAII here is that you don't care whether the resources are memory. Database handles? Aerial drones? A tape robot? These are all just resources you can wrap in an object to manage them, in both languages. "I only have 15MB of RAM" and "I only have 4 fire-fighting robots" are the same kind of problem from this perspective. > If you want to make the point that Zig is "closer to C" compared to other language that wants to replace C, that's a fair claim to make. This is really important. Zig is very much inspired by C. Rust has the syntax of a semi-colon language like C, but its inspirations come from all over the shop. I came to Rust having already programmed not only C and Java (and a little C++) but also Python and ML (and a little Prolog) and so this was less disconcerting. But I can see if you've literally never encountered a functional language some of Rust is weird because even though it is spelled like semi-colon languages you know it behaves very differently. I like Rust, much more than I liked Go or Python when I picked those up. It feels less clunky. An elegant weapon, for a more civilised age.

Zababa 5y ago

I'll restate my point: sometimes when replacing C people want something that's just as fast but also way more safe, and in that case will usually reach out for Rust. That's what the people doing the cryptography in Python did. Rust can also expose a C ABI, you can write code as fast as C. People will often choose Rust instead of Zig because Rust has stronger guarantees about memory safety, and these guarantees are more important for them than having a language that's small and fits in your head. This is why I think talking about what you're trying to achieve is more fruitful than just talking about the language you want to replace. For example, if you want to replace C code and you don't need all of the performance in the world, you couold simply switch to a garbage collected language. In that case, since speed wasn't the most important requirement, a language that isn't usually thought as a C replacement can replace C code. If you want to make the point that Zig is "closer to C" compared to other language that wants to replace C, that's a fair claim to make.

xhealthgothx 5y ago
Rust is also not 'small and fits in your head', so that's yet another point it is missing in your initial set of criteria. Its main implementation and library also emits rather large binaries in the usual case. You may not find this important, but others do.
- Zababa 5y ago
  I addressed that point: > People will often choose Rust instead of Zig because Rust has stronger guarantees about memory safety, and these guarantees are more important for them than having a language that's small and fits in your head. For some people, having a language that's small and fits in your head is not a requirement, not a priority, and sometimes not even important.
- nicoburns 5y ago
  As others have pointed out, neither is C if you take into account avoiding UB, the preprocessor, the build systems, the many stdlib functions you need to avoid, etc. You might already know how these work, but that doesn't mean there's less to learn than a language like Rust.
tialaramex 5y ago
> This is why I think talking about what you're trying to achieve is more fruitful than just talking about the language you want to replace This is definitely the right approach in my opinion. Even for your garbage collection example on the one hand, in some cases your program is dominated by tricky reclamation problems and the "correct" Rust program is basically 90% garbage collector, so that an existing GC language might produce faster programs; but on the far opposite scale maybe your program has tricky non-memory resource problems and GC doesn't help at all, so the GC language has worse performance and yet it makes your problem harder to solve than in Rust anyway. One of the nice things about Rust and about C++ RAII here is that you don't care whether the resources are memory. Database handles? Aerial drones? A tape robot? These are all just resources you can wrap in an object to manage them, in both languages. "I only have 15MB of RAM" and "I only have 4 fire-fighting robots" are the same kind of problem from this perspective. > If you want to make the point that Zig is "closer to C" compared to other language that wants to replace C, that's a fair claim to make. This is really important. Zig is very much inspired by C. Rust has the syntax of a semi-colon language like C, but its inspirations come from all over the shop. I came to Rust having already programmed not only C and Java (and a little C++) but also Python and ML (and a little Prolog) and so this was less disconcerting. But I can see if you've literally never encountered a functional language some of Rust is weird because even though it is spelled like semi-colon languages you know it behaves very differently. I like Rust, much more than I liked Go or Python when I picked those up. It feels less clunky. An elegant weapon, for a more civilised age.