7 ms·

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 t

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
      It's duck typed but it's not based on a funky and limited syntax, but rather types at comptime become normal arguments to functions that you can then inspect using normal Zig code. I wrote a blog post about comptime if you want to learn more: https://kristoff.it/blog/what-is-zig-comptime/ https://kristoff.it/blog/what-is-zig-comptime/
    - dnautics 5y ago
      It's duck typed but let's say your "template" takes an integer and divides by two depending on some boolean (perhaps you need to return a lookup table of sometimes half the bitwidth of an integer type). That function called by your template at compile time to maybe-divide-by-two is in the same language as runtime zig, and you could even conceivably call that very same function as a compiled entity in the runtime context.
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...

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
    It's duck typed but it's not based on a funky and limited syntax, but rather types at comptime become normal arguments to functions that you can then inspect using normal Zig code. I wrote a blog post about comptime if you want to learn more: https://kristoff.it/blog/what-is-zig-comptime/ https://kristoff.it/blog/what-is-zig-comptime/
  - dnautics 5y ago
    It's duck typed but let's say your "template" takes an integer and divides by two depending on some boolean (perhaps you need to return a lookup table of sometimes half the bitwidth of an integer type). That function called by your template at compile time to maybe-divide-by-two is in the same language as runtime zig, and you could even conceivably call that very same function as a compiled entity in the runtime context.

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...