5 ms·

> One nugget of knowledge I’ve worked out though - Zig is not a replacement for C. It is another replacement for C++. I hope this isn't the case, since I see R

> One nugget of knowledge I’ve worked out though - Zig is not a replacement for C. It is another replacement for C++. I hope this isn't the case, since I see Rust as the C++ replacement, and another replacement isn't very interesting to me. The main reason I've been interested in Zig is because I thought it was a replacement for C, which is an interesting idea.

dnautics 5y ago
I don't understand where that came from. It's really a replacement for C. The place where complexity comes from in zig is pretty much the comptime type system, which is emergent from the idea of replacing irregular consteval rules for C and replacing preprocessor macros I would say that Zig is: C - {make, autoconf, etc., preprocessor, UB[0]} + {*defer, !, ?, catch/try, "async"[1], alignment, comptime} I don't think that rises to the level of "C++ replacement". Maybe it's that comptime lets you do generics a la C++ templates? [0] by default, in zig you can have UB for performance [1] in quotes because async is not actually async, it's a control flow statement that is usually and most usefully used to do async things.
isaiahg 5y ago
That's the one part in which I really disagreed and the author does a bad job of explaining why they think that.
ncmncm 5y ago
Hint: Rust will not be replacing C++. C++ and Rust will coexist indefinitely. At some point in the future, it is possible that more Rust coders will be using it daily in their work than the number who pick up C++ for the first time in any given week, who will go on to use it professionally. Or, that might not happen, and Rust will join Ada and so many other languages that never got their miracle. Even if Zig doesn't fizzle like the overwhelming majority of languages, it won't replace, or displace, C, never mind C++. Everybody willing to move on from C already did a long time ago. People still using C today like it for its failings, so a language that fixes them is exactly what they don't want. It doesn't give C++ users any of the things they need. The only real advance in systems languages in the last 50 years is the destructor, so it is frankly weird to find a new language without it. The Drop trait is all that makes Rust a viable prospect for its own miracle.
- gilbetron 5y ago
  Oh I definitely meant "replacement" as in "replacement for me and many people", not that C++ would vanish. C and C++ are not going anywhere.
oconnor663 5y ago
Is a C replacement (which is not also a C++ replacement) really what anybody wants? Like with no generics, no dedicated error handling, and no automatic cleanup? I get that everyone enjoys a simple language, but these features feel like table stakes now.
- sirwhinesalot 5y ago
  Zig has all of those things, if you consider defer to be a form of automatic cleanup.
  - afdbcreid 5y ago
    Which it is not. It is harder to forget it, but it's possible.
    - oconnor663 5y ago
      For what it's worth, I think it makes sense to include defer in the "automatic cleanup" category. If we don't, then I think we end up suggesting that the only popular languages that support automatic cleanup for anything other than memory are C++ and Rust. That does have some truth to it, but if the goal is to describe "languages that are viable today", it seems pretty clear that e.g. Python and Go are viable.
    - sirwhinesalot 5y ago
      True but most languages need something like it to manage non-memory resources. Stuff like Python's with block or C#'s using block. So Zig is on par with those for non-memory stuff and much much better than C. Having everything accept an allocator also makes managing memory a lot simpler since you can use a simple arena allocator for temporary heap allocations.
- Bayart 5y ago
  Exception handling and garbage collection are two features that feel superfluous, if not outright noxious, to a number of programmers; in particular those doing systems, embedded, real time programming. That is the crowd that still uses C. There's a cost associated with the execution environment taking control over from the program itself, and by proxy the programmer. It's not something you want when you design your code with the assumption that is it a more or less accurate representation of its execution flow. Long story short : those who want that sort of programming language know why.

dnautics 5y ago

I don't understand where that came from. It's really a replacement for C. The place where complexity comes from in zig is pretty much the comptime type system, which is emergent from the idea of replacing irregular consteval rules for C and replacing preprocessor macros I would say that Zig is: C - {make, autoconf, etc., preprocessor, UB[0]} + {*defer, !, ?, catch/try, "async"[1], alignment, comptime} I don't think that rises to the level of "C++ replacement". Maybe it's that comptime lets you do generics a la C++ templates? [0] by default, in zig you can have UB for performance [1] in quotes because async is not actually async, it's a control flow statement that is usually and most usefully used to do async things.

isaiahg 5y ago

That's the one part in which I really disagreed and the author does a bad job of explaining why they think that.

ncmncm 5y ago

Hint: Rust will not be replacing C++. C++ and Rust will coexist indefinitely. At some point in the future, it is possible that more Rust coders will be using it daily in their work than the number who pick up C++ for the first time in any given week, who will go on to use it professionally. Or, that might not happen, and Rust will join Ada and so many other languages that never got their miracle. Even if Zig doesn't fizzle like the overwhelming majority of languages, it won't replace, or displace, C, never mind C++. Everybody willing to move on from C already did a long time ago. People still using C today like it for its failings, so a language that fixes them is exactly what they don't want. It doesn't give C++ users any of the things they need. The only real advance in systems languages in the last 50 years is the destructor, so it is frankly weird to find a new language without it. The Drop trait is all that makes Rust a viable prospect for its own miracle.

gilbetron 5y ago
Oh I definitely meant "replacement" as in "replacement for me and many people", not that C++ would vanish. C and C++ are not going anywhere.

oconnor663 5y ago

Is a C replacement (which is not also a C++ replacement) really what anybody wants? Like with no generics, no dedicated error handling, and no automatic cleanup? I get that everyone enjoys a simple language, but these features feel like table stakes now.

sirwhinesalot 5y ago
Zig has all of those things, if you consider defer to be a form of automatic cleanup.
- afdbcreid 5y ago
  Which it is not. It is harder to forget it, but it's possible.
  - oconnor663 5y ago
    For what it's worth, I think it makes sense to include defer in the "automatic cleanup" category. If we don't, then I think we end up suggesting that the only popular languages that support automatic cleanup for anything other than memory are C++ and Rust. That does have some truth to it, but if the goal is to describe "languages that are viable today", it seems pretty clear that e.g. Python and Go are viable.
  - sirwhinesalot 5y ago
    True but most languages need something like it to manage non-memory resources. Stuff like Python's with block or C#'s using block. So Zig is on par with those for non-memory stuff and much much better than C. Having everything accept an allocator also makes managing memory a lot simpler since you can use a simple arena allocator for temporary heap allocations.
Bayart 5y ago
Exception handling and garbage collection are two features that feel superfluous, if not outright noxious, to a number of programmers; in particular those doing systems, embedded, real time programming. That is the crowd that still uses C. There's a cost associated with the execution environment taking control over from the program itself, and by proxy the programmer. It's not something you want when you design your code with the assumption that is it a more or less accurate representation of its execution flow. Long story short : those who want that sort of programming language know why.