12 ms·

Zig is a very interesting language. You are able to do thing that would require wizard level skills in C with simple plain language construct. Like serializing/

Zig is a very interesting language. You are able to do thing that would require wizard level skills in C with simple plain language construct. Like serializing/deserializing an enum variants over the wire for example in the most efficient way (look at std.json.{parser, stringify} [0]). > soon we’ll also have a package manager This. If they succeed to do this (and I have my doubts) it will be a paradigm shift for low-level "system" programming. Let's hope this is not vaporware. Finally, it's relatively easy to contribute to Zig. Andrew Kelley is very opinionated on where the language should go with an emphasis on simplicity which sometimes can make things awkward but he is also persuasive and welcoming. I have been using Zig for a month and I am still positively surprised so he must be onto something. [0]: https://github.com/ziglang/zig/blob/master/lib/std/json.zig#L2273 https://github.com/ziglang/zig/blob/master/lib/std/json.zig#...

void_mint 5y ago
I've been paying attention to Zig posts on HN, mostly just because it seems well-liked and I think Andrew Kelley is interesting/smart. Would it be fair to say that Zig is to C, what Rust is to C++? Or are they both just kind of...low-ish-level systems languages solving similar problems, differently?
- tristan957 5y ago
  Zig/Rust aim to fit in the same systems/general purpose space which can be viewed as alternatives to both C and C++.
- oconnor663 5y ago
  > Would it be fair to say that Zig is to C, what Rust is to C++? There's definitely something to that analogy, but I think it also misses a lot of really important details. For example, Zig has generics, which right off the bat makes it hard to say that it's "like C". Also Rust enforces memory safety, which isn't like C or C++.
  - roblabla 5y ago
    I mean, C11 also has generics, but I would really suggest not using it X). See https://en.cppreference.com/w/c/language/generic https://en.cppreference.com/w/c/language/generic Of couse, it's a much less powerful feature, there's nothing like interfaces or stuff, just a way to "overload" based on the type.
    - yisonPylkita 5y ago
      Thank you. I had no idea that you could do such a thing in C11 preprocessor
      - flohofwoe 5y ago
        _Generic() is not a preprocessor feature, but a "real" language feature (I was confused too when I saw it first though). The only preprocessor part in the example is mapping the function-like macro 'cbrt(X)' to the language keyword '_Generic(X)'.
  - woodrowbarlow 5y ago
    i love that zig doesn't have a special syntax for generics, it just allows anything to be resolved at compile-time -- including types. which gives you generics 'for free'.
    - maleldil 5y ago
      I've only cursory of Zig, so bear with me. Does this mean that Zig templates are like C++, that is, duck typing? Or is there a notion of constraining the type arguments?
      - robinei 5y ago
        You can constrain type arguments with a compile-time `if` check, and generate a compile error on violation.
      - kristoff_it 5y ago
- nrclark 5y ago
  I think that's correct with some overlap, yes. Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. I feel like Rust wants to replace C but it also wants to replace C++. And given the complexity difference between the two languages, that means that Rust will end up closer to C++ than to C. So there's some overlap based on how Rust positions itself, but not based on how Zig positions itself.
  - masklinn 5y ago
    > I feel like Rust wants to replace C but it also wants to replace C++. Rust wants to make systems programming memory safe (and type safe while at it). It's not really about any specific language, it's about dragging the field forwards on the safety front. Well it's not really Rust, it's the Rust community, which kinda wrestled it away from Graydon Hoare: the original inception of Rust was more of an applications language (what with the evented model and the split stack and the planned-though-never-really-implemented GC'd pointers) — which explains part of the historical confusion with / comparison to Go. But then a critical mass of people took a look at this early rust and figured "we've got plenty of memory-safe and type-safe (ish) languages for applications, but this thing has precise control over memory and lifetimes and shit, we could actually build reliable infrastructure with that", and it coincided with a lot of memory safety issues news (which has been continuing ever since), and the rest is history, pretty much.
  - jhoechtl 5y ago
    > Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. The ZIG compiler requires a C compiler to compile to a native executable though.
    - Twisol 5y ago
      To be fair, the C compiler also requires a C compiler. Bootstrapping is a common milestone in language development (Rust can bootstrap itself too), so while the current state of affairs for Zig might require a C compiler, that's not necessarily written in stone.
    - 5y ago
- rattray 5y ago
  I think they solve some similar and some different problems, with some similarities and differences! The biggest difference in the problems they solve, in my view, is that Zig does not aim for safety. It'll be easier to write safe programs yourself with Zig than it might be with C, but it doesn't give you any guarantees. Zig also seems like it may be a better fit for embedded programming; there's a big community around embedded Rust, and it sounds like there's a lot of progress, but still an uphill battle. But yes, Zig:Rust :: C:C++ has merit in that Zig is a much smaller, less feature-rich language.
  - void_mint 5y ago
    Thanks for the response. I'm excited for as many viable alternatives to C/C++ as we can get.
  - travisgriggs 5y ago
    I write/maintain multiple code bases for XMega, SAMD, and STM chips. The kind where 32K ram is cool and 256K flash is lots. I'm curious if either of these is ready for normal humans to cross compile for these kinds of targets (M0 and the ilk). Zig looks very interesting to me.
- steveklabnik 5y ago
  Many people say this, and there's some truth to it, but like all analogies, it can be useful in some contexts but not others. The issue with this analogy is that it assumes that C, one of the languages used in the most diverse set of circumstances ever, means the same thing to everyone. Same with C++, frankly.
- JoshTriplett 5y ago
  > Would it be fair to say that Zig is to C, what Rust is to C++? I don't think that's the parallel I would draw. Rather, I think both Zig and Rust aim to serve the use cases C and C++ do, but Zig and Rust pick different points on the tradeoffs involving safety. Zig feels like a "better C", in the sense of bringing modern language features to C, but it chooses safer rather than safe. Rust supplies modern language features as well, and chooses to prioritize safe; sometimes that comes at the expense of other factors, such as productivity or compile time. I personally prefer the point on the spectrum that Rust chose, but I think Zig still offers improvements over C.
  - mumblemumble 5y ago
    disclaimer: I haven't actually used either, just done a lot of interested reading and a little toying around. One thing that impressed me about Zig is how simple the language is. I get the impression that it would take very little time to properly learn the language and become effective at it. Rust, on the other hand, has a whole lot of complexity even without the ownership semantics. So much to learn and understand. And, in some cases, work around. It seems, from looking at others' code, that there is a very strong temptation to lean on `unsafe` instead of figuring out how to solve a problem within the constraints it normally applies. That has me wondering if there's really all that much safety difference in practice? Simpler code is generally easier to understand, and it's generally easier to find and fix bugs in code that's easier to understand. I can imagine a world where it's a tradeoff between, "You definitely won't have any of this relatively narrow category of bug, unless of course you opt out of the static checks, which you will probably do sometimes, even though we tell you you shouldn't," and, "There are no particular guarantees, but you're generally less likely to have any of this broader category of bug."
    - steveklabnik 5y ago
      "simple" is, unfortunately, not a simple concept, nor does everyone agree on its effects on programs written in a language that is or is not simple. Some people do believe that, let's say "conceptually parsimonious" languages (using complicated words to describe simplicity is amusing to me, sorry) do exactly what you say. Others believe that complexity inherently exists, and you can put it in the language, where a compiler can tirelessly check certain properties for you or a runtime can do magical complicated work on your behalf, or you can put it in the programs, where users have to check such things themselves. Another way I heard this expressed one time is Ruby vs Python. I once heard someone talk about how they preferred Python as a language more, because it was simpler, but enjoyed actually programming in Ruby more, even thought it was more complex, and they value simplicity. The reason is that all of that nasty ugly stuff Ruby lets you do makes you be able to make extremely nice APIs. Things you couldn't do, or just folks don't do, in Python. And therefore they ended up liking using Ruby more in practice. I suspect that this is a topic that we, as a profession, will debate about endlessly.
- matu3ba 5y ago
  Take a look at my comparison of semantics that unfortunately not yet includes a sketch of memory and synchronization: https://gist.github.com/matu3ba/dda72ad5ee473e3ea26426c121e0a967 https://gist.github.com/matu3ba/dda72ad5ee473e3ea26426c121e0...
moogly 5y ago
I've been toying with Zig over the summer, and I'm really impressed by the build system, general ergonomics and the explicitness of the language. The only thing I've found being a pain point is C's biggest pain point: the lack of a proper string type. Even though I've worked for years in the past with C and C++, I still get tripped up, and in Zig I keep on being confused whether I should use raw byte arrays, or sentinel-terminated arrays for certain string manipulations. Maybe I'm not familiar with common idioms in Zig that might help avoid this C-style tracking of string/buffer lengths malarkey that I tend to end up with where a slice is not appropriate. Maybe a dynamic-length string library is the way forward. I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age. I understand having one of those could make C interop a bit gnarlier (I think Odin's approach of having two separate string types -- one of which is just meant to be used for interop -- should be workable). Oh, and the ecosystem of libraries is still young. I needed to format timestamps as human readable date/time to a file, and had to step down to C to do something that basic[1], but it'll get there in time, I'm sure. [1]: "basic" from the perspective of the end-user of the language. Having written a (not even fully featured) date/time library in C++, I consider date and time to be one of the hardest domains I've ever had to work in.
- 10000truths 5y ago
  > I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age. You don't need a string type for that, you just need routines that handle UTF-8 strings, like utfcpp (https://github.com/nemtrif/utfcpp https://github.com/nemtrif/utfcpp).
  - moogly 5y ago
    Sure, you're not wrong. For my purposes that'd work, but I'm of the opinion that delegating that to an optional library will make a lot of developers lazy and not even bother thinking about Unicode/i18n/l10n issues at all. I've seen so much code, in a multitude of languages that is oblivious to it, but even if it's reified in a type or even having some form of language support, I guess you can argue that people can still ignore it.
AndyKelley 5y ago
> Let's hope this is not vaporware. I sincerely approve of the skepticism. I can assure you there is already a very large fire under my ass to get this shipped. To provide some more context, here is a snippet from the latest release notes[0]: > Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature. > If the package manager works well, people will use it, which means building Zig projects will involve compiling more lines of Zig code, which means the Zig compiler must get faster, better at incremental compilation, and better at resource management. > Therefore, the package manager depends on finishing the Self-Hosted Compiler, since it is planned to have these improved performance characteristics, while the Bootstrap Compiler is not planned to have them. I can't help but mention, I am incredibly excited about how well the self-hosted compiler is coming along. Progress is swift, and all the ambitious design decisions (fully incremental compilation[1], extremely fast debug builds[2], low memory usage, multi-threaded) are intact. I anticipate it to make quite a splash once it becomes generally usable. I don't expect the package manager to take nearly as long to develop. [0]: https://ziglang.org/download/0.8.0/release-notes.html#Package-Manager-Status https://ziglang.org/download/0.8.0/release-notes.html#Packag... [1]: https://vimeo.com/491488902 https://vimeo.com/491488902 [2]: https://twitter.com/andy_kelley/status/1416485475125141504 https://twitter.com/andy_kelley/status/1416485475125141504
- cs702 5y ago
  > ...I can assure you there is already a very large fire under my ass to get this shipped ... [followed by a short, easy-to-follow explanation as to why it's taking so long] I'm going to check out Zig because of your response. I love coming across comments like this one on HN.
  - ljm 5y ago
    Zig has been on my radar precisely because of Andrew Kelley's vision. I wrote about cross-compiling to a raspberry-pi and writing a barebones driver for an OLED display[^1] That was a lot of fun despite the fact the code was incredibly basic. The interop with C was effortless. [^1] https://www.kamelasa.dev/posts/gettin-ziggy-with-it-pi-zero.html https://www.kamelasa.dev/posts/gettin-ziggy-with-it-pi-zero....
phplovesong 5y ago
Just curious. Why do you have doubts about about the package manager? There are so many languages that have a package ecosystem, so by now you'd think its easy to find out what works and what does not.

void_mint 5y ago

I've been paying attention to Zig posts on HN, mostly just because it seems well-liked and I think Andrew Kelley is interesting/smart. Would it be fair to say that Zig is to C, what Rust is to C++? Or are they both just kind of...low-ish-level systems languages solving similar problems, differently?

tristan957 5y ago
Zig/Rust aim to fit in the same systems/general purpose space which can be viewed as alternatives to both C and C++.
oconnor663 5y ago
> Would it be fair to say that Zig is to C, what Rust is to C++? There's definitely something to that analogy, but I think it also misses a lot of really important details. For example, Zig has generics, which right off the bat makes it hard to say that it's "like C". Also Rust enforces memory safety, which isn't like C or C++.
- roblabla 5y ago
  I mean, C11 also has generics, but I would really suggest not using it X). See https://en.cppreference.com/w/c/language/generic https://en.cppreference.com/w/c/language/generic Of couse, it's a much less powerful feature, there's nothing like interfaces or stuff, just a way to "overload" based on the type.
  - yisonPylkita 5y ago
    Thank you. I had no idea that you could do such a thing in C11 preprocessor
    - flohofwoe 5y ago
      _Generic() is not a preprocessor feature, but a "real" language feature (I was confused too when I saw it first though). The only preprocessor part in the example is mapping the function-like macro 'cbrt(X)' to the language keyword '_Generic(X)'.
- woodrowbarlow 5y ago
  i love that zig doesn't have a special syntax for generics, it just allows anything to be resolved at compile-time -- including types. which gives you generics 'for free'.
  - maleldil 5y ago
    I've only cursory of Zig, so bear with me. Does this mean that Zig templates are like C++, that is, duck typing? Or is there a notion of constraining the type arguments?
    - robinei 5y ago
      You can constrain type arguments with a compile-time `if` check, and generate a compile error on violation.
    - kristoff_it 5y ago
nrclark 5y ago
I think that's correct with some overlap, yes. Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. I feel like Rust wants to replace C but it also wants to replace C++. And given the complexity difference between the two languages, that means that Rust will end up closer to C++ than to C. So there's some overlap based on how Rust positions itself, but not based on how Zig positions itself.
- masklinn 5y ago
  > I feel like Rust wants to replace C but it also wants to replace C++. Rust wants to make systems programming memory safe (and type safe while at it). It's not really about any specific language, it's about dragging the field forwards on the safety front. Well it's not really Rust, it's the Rust community, which kinda wrestled it away from Graydon Hoare: the original inception of Rust was more of an applications language (what with the evented model and the split stack and the planned-though-never-really-implemented GC'd pointers) — which explains part of the historical confusion with / comparison to Go. But then a critical mass of people took a look at this early rust and figured "we've got plenty of memory-safe and type-safe (ish) languages for applications, but this thing has precise control over memory and lifetimes and shit, we could actually build reliable infrastructure with that", and it coincided with a lot of memory safety issues news (which has been continuing ever since), and the rest is history, pretty much.
- jhoechtl 5y ago
  > Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. The ZIG compiler requires a C compiler to compile to a native executable though.
  - Twisol 5y ago
    To be fair, the C compiler also requires a C compiler. Bootstrapping is a common milestone in language development (Rust can bootstrap itself too), so while the current state of affairs for Zig might require a C compiler, that's not necessarily written in stone.
  - 5y ago
rattray 5y ago
I think they solve some similar and some different problems, with some similarities and differences! The biggest difference in the problems they solve, in my view, is that Zig does not aim for safety. It'll be easier to write safe programs yourself with Zig than it might be with C, but it doesn't give you any guarantees. Zig also seems like it may be a better fit for embedded programming; there's a big community around embedded Rust, and it sounds like there's a lot of progress, but still an uphill battle. But yes, Zig:Rust :: C:C++ has merit in that Zig is a much smaller, less feature-rich language.
- void_mint 5y ago
  Thanks for the response. I'm excited for as many viable alternatives to C/C++ as we can get.
- travisgriggs 5y ago
  I write/maintain multiple code bases for XMega, SAMD, and STM chips. The kind where 32K ram is cool and 256K flash is lots. I'm curious if either of these is ready for normal humans to cross compile for these kinds of targets (M0 and the ilk). Zig looks very interesting to me.
steveklabnik 5y ago
Many people say this, and there's some truth to it, but like all analogies, it can be useful in some contexts but not others. The issue with this analogy is that it assumes that C, one of the languages used in the most diverse set of circumstances ever, means the same thing to everyone. Same with C++, frankly.
JoshTriplett 5y ago
> Would it be fair to say that Zig is to C, what Rust is to C++? I don't think that's the parallel I would draw. Rather, I think both Zig and Rust aim to serve the use cases C and C++ do, but Zig and Rust pick different points on the tradeoffs involving safety. Zig feels like a "better C", in the sense of bringing modern language features to C, but it chooses safer rather than safe. Rust supplies modern language features as well, and chooses to prioritize safe; sometimes that comes at the expense of other factors, such as productivity or compile time. I personally prefer the point on the spectrum that Rust chose, but I think Zig still offers improvements over C.
- mumblemumble 5y ago
  disclaimer: I haven't actually used either, just done a lot of interested reading and a little toying around. One thing that impressed me about Zig is how simple the language is. I get the impression that it would take very little time to properly learn the language and become effective at it. Rust, on the other hand, has a whole lot of complexity even without the ownership semantics. So much to learn and understand. And, in some cases, work around. It seems, from looking at others' code, that there is a very strong temptation to lean on `unsafe` instead of figuring out how to solve a problem within the constraints it normally applies. That has me wondering if there's really all that much safety difference in practice? Simpler code is generally easier to understand, and it's generally easier to find and fix bugs in code that's easier to understand. I can imagine a world where it's a tradeoff between, "You definitely won't have any of this relatively narrow category of bug, unless of course you opt out of the static checks, which you will probably do sometimes, even though we tell you you shouldn't," and, "There are no particular guarantees, but you're generally less likely to have any of this broader category of bug."
  - steveklabnik 5y ago
    "simple" is, unfortunately, not a simple concept, nor does everyone agree on its effects on programs written in a language that is or is not simple. Some people do believe that, let's say "conceptually parsimonious" languages (using complicated words to describe simplicity is amusing to me, sorry) do exactly what you say. Others believe that complexity inherently exists, and you can put it in the language, where a compiler can tirelessly check certain properties for you or a runtime can do magical complicated work on your behalf, or you can put it in the programs, where users have to check such things themselves. Another way I heard this expressed one time is Ruby vs Python. I once heard someone talk about how they preferred Python as a language more, because it was simpler, but enjoyed actually programming in Ruby more, even thought it was more complex, and they value simplicity. The reason is that all of that nasty ugly stuff Ruby lets you do makes you be able to make extremely nice APIs. Things you couldn't do, or just folks don't do, in Python. And therefore they ended up liking using Ruby more in practice. I suspect that this is a topic that we, as a profession, will debate about endlessly.
matu3ba 5y ago
Take a look at my comparison of semantics that unfortunately not yet includes a sketch of memory and synchronization: https://gist.github.com/matu3ba/dda72ad5ee473e3ea26426c121e0a967 https://gist.github.com/matu3ba/dda72ad5ee473e3ea26426c121e0...

moogly 5y ago

I've been toying with Zig over the summer, and I'm really impressed by the build system, general ergonomics and the explicitness of the language. The only thing I've found being a pain point is C's biggest pain point: the lack of a proper string type. Even though I've worked for years in the past with C and C++, I still get tripped up, and in Zig I keep on being confused whether I should use raw byte arrays, or sentinel-terminated arrays for certain string manipulations. Maybe I'm not familiar with common idioms in Zig that might help avoid this C-style tracking of string/buffer lengths malarkey that I tend to end up with where a slice is not appropriate. Maybe a dynamic-length string library is the way forward. I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age. I understand having one of those could make C interop a bit gnarlier (I think Odin's approach of having two separate string types -- one of which is just meant to be used for interop -- should be workable). Oh, and the ecosystem of libraries is still young. I needed to format timestamps as human readable date/time to a file, and had to step down to C to do something that basic[1], but it'll get there in time, I'm sure. [1]: "basic" from the perspective of the end-user of the language. Having written a (not even fully featured) date/time library in C++, I consider date and time to be one of the hardest domains I've ever had to work in.

10000truths 5y ago
> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age. You don't need a string type for that, you just need routines that handle UTF-8 strings, like utfcpp (https://github.com/nemtrif/utfcpp https://github.com/nemtrif/utfcpp).
- moogly 5y ago
  Sure, you're not wrong. For my purposes that'd work, but I'm of the opinion that delegating that to an optional library will make a lot of developers lazy and not even bother thinking about Unicode/i18n/l10n issues at all. I've seen so much code, in a multitude of languages that is oblivious to it, but even if it's reified in a type or even having some form of language support, I guess you can argue that people can still ignore it.

AndyKelley 5y ago

> Let's hope this is not vaporware. I sincerely approve of the skepticism. I can assure you there is already a very large fire under my ass to get this shipped. To provide some more context, here is a snippet from the latest release notes[0]: > Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature. > If the package manager works well, people will use it, which means building Zig projects will involve compiling more lines of Zig code, which means the Zig compiler must get faster, better at incremental compilation, and better at resource management. > Therefore, the package manager depends on finishing the Self-Hosted Compiler, since it is planned to have these improved performance characteristics, while the Bootstrap Compiler is not planned to have them. I can't help but mention, I am incredibly excited about how well the self-hosted compiler is coming along. Progress is swift, and all the ambitious design decisions (fully incremental compilation[1], extremely fast debug builds[2], low memory usage, multi-threaded) are intact. I anticipate it to make quite a splash once it becomes generally usable. I don't expect the package manager to take nearly as long to develop. [0]: https://ziglang.org/download/0.8.0/release-notes.html#Package-Manager-Status https://ziglang.org/download/0.8.0/release-notes.html#Packag... [1]: https://vimeo.com/491488902 https://vimeo.com/491488902 [2]: https://twitter.com/andy_kelley/status/1416485475125141504 https://twitter.com/andy_kelley/status/1416485475125141504

cs702 5y ago
> ...I can assure you there is already a very large fire under my ass to get this shipped ... [followed by a short, easy-to-follow explanation as to why it's taking so long] I'm going to check out Zig because of your response. I love coming across comments like this one on HN.
- ljm 5y ago
  Zig has been on my radar precisely because of Andrew Kelley's vision. I wrote about cross-compiling to a raspberry-pi and writing a barebones driver for an OLED display[^1] That was a lot of fun despite the fact the code was incredibly basic. The interop with C was effortless. [^1] https://www.kamelasa.dev/posts/gettin-ziggy-with-it-pi-zero.html https://www.kamelasa.dev/posts/gettin-ziggy-with-it-pi-zero....

phplovesong 5y ago

Just curious. Why do you have doubts about about the package manager? There are so many languages that have a package ecosystem, so by now you'd think its easy to find out what works and what does not.