7 ms·

I’m sorry, but any non-trivial Zig code gives me PTSD flashbacks of C. I don’t understand who Zig is targeting: with pervasive mutability, manual allocation, an

by 8s2ngy 1y ago

I’m sorry, but any non-trivial Zig code gives me PTSD flashbacks of C. I don’t understand who Zig is targeting: with pervasive mutability, manual allocation, and a lack of proper sum types, it feels like a step back from languages such as Rust. If it is indeed a different way to write code, one that embraces default memory unsafety, why would I choose it over C, which has decades of work behind it? Am I missing some context? I’d love to hear it.

ozgrakkurt 1y ago
Compared to C: Discriminated unions, error handling, comptime, defer. Better default integer type casting, ability to choose between releaseSafe/releaseFast And probably other things. As for comparison to Rust, you do want very low level memory handling for writing databases as an example. It is extremely difficult to write low level libraries in Rust
- simonask 1y ago
  I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C. You will just only notice the difficulty at some later point after writing the code, potentially in production.
  - flohofwoe 1y ago
    > low level libraries in Zig, just as it is in C Did you write any Zig code yet? In terms of enforced correctness in the language (e.g. no integer promotion, no implicit 'dangerous' casts, null-safety, enforced error handling, etc...) and runtime safety (range-, nullptr-, integer-overflow-checks etc...), Zig is much closer to Rust than it is to C and C++. It "just" doesn't solve static memory safety and some (admittedly important) temporal memory safety issues (aka "use-after-free"), but it still makes it much harder to accidentially trigger memory corruption as a side effect in most situations that C and C++ let slip through via a mix of compile errors and runtime checks (and you get ASAN/UBSAN automatically enabled in debug builds, a debug allocator which detects memory leaks and use-after-free for heap-allocations (unfortunately not for stack allocations), and proper runtime stack traces - things that many C/C++ toolchains are still missing or don't enable by default). There is still one notable issue: returning a reference to stack memory from a function - this is something that many unexperienced Zig programmers seem to stumble into, especially since Zig's slice syntax looks so 'innocent' (slices look too similar to arrays, but arrays are values, while slices are references - e.g. 'fat pointers') - and which IMHO needs some sort of solution (either a compile time error via watertight escape analysis, or at least some sort runtime check which panics when trying to access 'stale' data on the stack) - and maybe giving slices their own distinct syntax that doesn't overlap with arrays might also help a bit.
    - simonask 1y ago
      I mean, there's no question that Zig, also in its current state, is vast improvement over C or even C++ - for the "small stuff". It is much more pleasant to use. But there is still the "big stuff" - the things that have a fundamental, architectural impact. Things like: Will my program be multithreaded? Will I have many systems that interact? Will my program be maximally memory-efficient? Do I have the capacity (or money) to ensure correctness if I say "yes" to any of that? The most important consideration in any software project is managing architectural complexity. Zig is better, yes, but not a paradigm shift. If you say "yes" to any of the above, you are in the same world of pain (or expenses) as you would be in C or C++. This is the reason that Rust is interesting: It makes things feasible/cheap that were previously very hard/expensive, at a fundamental level.
      - flohofwoe 1y ago
        > Zig is better, yes, but not a paradigm shift. But it doesn't have to be and it shouldn't. Rust also isn't a paradigm shift, it "just" solved static memory safety (admittedly a great engineering feat) but other languages solved memory safety too decades ago, just with more of it happening at runtime. But in many other areas Rust copied too many bad ideas from C++ (and many of those "other things" Zig already does much better than Rust - but different people will have vastly different opinions about whether one solution is actually better than another - so discussions about those features usually run in circles). There shouldn't be a single language that solves all problems - this will just result in stagnation, it's much better to have many languages to pick from - and even if they just differ in personal opinions of the language author of how to do things or entirely subjective 'syntax sugar' features. Competition is good, monocultures are bad. > The most important consideration in any software project is managing architectural complexity No language will help you managing "architectural complexity" in any meaningful way except by imposing tons of arbitrary restrictions which then get in the way for smaller projects that don't need much "architecture". We have plenty of "Enterprise-scale languages" already (Java, C#, Rust, C++, ...), what we need is more languages for small teams that don't get in the way of just getting shit done, since the really interesting and innovative stuff doesn't happen in enterprise environments but in small 'basement and bedroom teams' :)
  - kristoff_it 1y ago
    > I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C. This has been not my experience at all in the ~6 years I've been writing Zig. I started having very little experience writing C (<1000, lines all written while in university) and since day 1 Zig has been a tremendous improvement over it, even back when it was at version 0.4.0.
    - simonask 1y ago
      Glad you're having a great time with it. :-) I'm informed by having shipped a lot of C++ code in my time, which has taught me a lot about actually delivering stable software. Being better than C is a very low bar here.
  - ozgrakkurt 1y ago
    This is a subjective argument. You don’t know me, I don’t know you. There is no meaning in assuming anything. There is plenty of working software written with pretty much any language
- kstenerud 1y ago
  > It is extremely difficult to write low level libraries in Rust Really? I've not found it at all difficult to write low level libraries in Rust.
  - ozgrakkurt 1y ago
    For me it was very difficult to make an io library on io_uring that is properly safe. Also using arena and other special allocators in different sections of the program. While maintaining hard memory limits for different sections of the program. These are possible to do in rust but it is very difficult for me so I decided to just not do it. Otherwise I have to spend 5x the normal amount of time to make sure the library cannot be misused by the user ever. This is pretty pointless since I’m the only one who is going to use that code anyway. Could be skill issue or w/e but I just find zig easier to make progress in
LAC-Tech 1y ago
Zig is a systems programming language. I think that's probably who it's targeting. People do systems programming in rust, but that's not really what most of the community is doing. And it's DEFINITELY not what the standard library is designed for.
- konart 1y ago
  >People do systems programming in rust, but that's not really what most of the community is doing. As someone who haven't done any systems programming after university: wait, what? I was under impression that this is exactly what people where doing with Rust.(system apps, even linux kernel, no?) If not - what do they (most if the community) are doing with Rust?
  - LAC-Tech 1y ago
    Web servers, games, and applications, that sort of thing. Some people definitely do systems programming in, but it's a minority. The std library is not set up for it at all, you need something like rustix, but even that results in very unidiomatic ("unsafe") rust code. In Zig it's all in the std library by default. Because it's a systems programming language, first and foremost.
    - porridgeraisin 1y ago
      Actually I was also under OPs impression... can you tell me few specific problems with using rust for systems programming? BTW, I have only ever done something that resembles systems programming in C.
    - Ar-Curunir 1y ago
      Rust is in the Linux kernel. Doesn’t get more systems than that…
- simonask 1y ago
  Which part of the Rust standard library are you referring to here? As far as I can tell, it contains many, many features that are irrelevant outside of systems programming scenarios with highly particular needs.
sothatsit 1y ago
I love Zig precisely because it is so similar to C. Honestly, if you don't like C, I can totally understand why you wouldn't like Zig. But I love C, and I love Zig. Zig has become my go-to for projects where I would previously have reached for C, largely because Zig has such good compatibility with other C projects. Rust, on the other hand, is a completely different beast. It is very different from C, and it is far more complicated. That makes it harder to justify using, whereas Zig is a very easy choice as an alternative to using C itself.
- simonask 1y ago
  C is entirely as complicated as Rust, if your goal is to write correct software that doesn't crash all the time. It's only a syntactically simple language. Actually making anything interesting with it is _not_ simple.
  - taminka 1y ago
    https://github.com/oxidecomputer/omicron/blob/5fd1c35/nexus/db-queries/src/db/pagination.rs#L78-L181 https://github.com/oxidecomputer/omicron/blob/5fd1c35/nexus/...
    - simonask 1y ago
      I don't think a 100-line function signature is representative, but I will point out that the alternative is at least 100 lines of runtime checks instead. In both cases, what a nightmare.
    - kelnos 1y ago
      To me that's more an indictment of Diesel than of Rust. I've been using sea-orm for a project I'm working on, and my (generic) pagination function is a hell of a lot simpler and readable than that one.
    - lll-o-lll 1y ago
      Yuck. I thought some of the signatures you end up with when building “Modern C++” in the Andrei Alexandrescu style were hairy, but this looks sick. Not in a good way. Probably does something cool for all that crazy though?
flohofwoe 1y ago
> a lack of proper sum types Do you consider Rust enums 'proper sum types'? If yes what are Zig's tagged unions missing? E.g.: const Variant = union(enum) { int: i32, boolean: bool, none, fn truthy(self: Variant) bool { return switch (self) { Variant.int => |x_int| x_int != 0, Variant.boolean => |x_bool| x_bool, Variant.none => false, }; } };
kristoff_it 1y ago
[flagged]
kllrnohj 1y ago
Zig is for people who want to write C, that's really it. It's not a replacement for C++ or Rust or Go or Swift or anything "serious". As for why you would choose it over C, because C has too many problems for even the C lovers to ignore. Zig fixes a tiny amount of them, just enough to pretend it's not problematic, but not enough to be useful in any non-hobby capacity. Which is fine, very few languages do achieve non-hobby status after all.

by 8s2ngy 1y ago

ozgrakkurt 1y ago

Compared to C: Discriminated unions, error handling, comptime, defer. Better default integer type casting, ability to choose between releaseSafe/releaseFast And probably other things. As for comparison to Rust, you do want very low level memory handling for writing databases as an example. It is extremely difficult to write low level libraries in Rust

simonask 1y ago
I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C. You will just only notice the difficulty at some later point after writing the code, potentially in production.
- flohofwoe 1y ago
  > low level libraries in Zig, just as it is in C Did you write any Zig code yet? In terms of enforced correctness in the language (e.g. no integer promotion, no implicit 'dangerous' casts, null-safety, enforced error handling, etc...) and runtime safety (range-, nullptr-, integer-overflow-checks etc...), Zig is much closer to Rust than it is to C and C++. It "just" doesn't solve static memory safety and some (admittedly important) temporal memory safety issues (aka "use-after-free"), but it still makes it much harder to accidentially trigger memory corruption as a side effect in most situations that C and C++ let slip through via a mix of compile errors and runtime checks (and you get ASAN/UBSAN automatically enabled in debug builds, a debug allocator which detects memory leaks and use-after-free for heap-allocations (unfortunately not for stack allocations), and proper runtime stack traces - things that many C/C++ toolchains are still missing or don't enable by default). There is still one notable issue: returning a reference to stack memory from a function - this is something that many unexperienced Zig programmers seem to stumble into, especially since Zig's slice syntax looks so 'innocent' (slices look too similar to arrays, but arrays are values, while slices are references - e.g. 'fat pointers') - and which IMHO needs some sort of solution (either a compile time error via watertight escape analysis, or at least some sort runtime check which panics when trying to access 'stale' data on the stack) - and maybe giving slices their own distinct syntax that doesn't overlap with arrays might also help a bit.
  - simonask 1y ago
    I mean, there's no question that Zig, also in its current state, is vast improvement over C or even C++ - for the "small stuff". It is much more pleasant to use. But there is still the "big stuff" - the things that have a fundamental, architectural impact. Things like: Will my program be multithreaded? Will I have many systems that interact? Will my program be maximally memory-efficient? Do I have the capacity (or money) to ensure correctness if I say "yes" to any of that? The most important consideration in any software project is managing architectural complexity. Zig is better, yes, but not a paradigm shift. If you say "yes" to any of the above, you are in the same world of pain (or expenses) as you would be in C or C++. This is the reason that Rust is interesting: It makes things feasible/cheap that were previously very hard/expensive, at a fundamental level.
    - flohofwoe 1y ago
      > Zig is better, yes, but not a paradigm shift. But it doesn't have to be and it shouldn't. Rust also isn't a paradigm shift, it "just" solved static memory safety (admittedly a great engineering feat) but other languages solved memory safety too decades ago, just with more of it happening at runtime. But in many other areas Rust copied too many bad ideas from C++ (and many of those "other things" Zig already does much better than Rust - but different people will have vastly different opinions about whether one solution is actually better than another - so discussions about those features usually run in circles). There shouldn't be a single language that solves all problems - this will just result in stagnation, it's much better to have many languages to pick from - and even if they just differ in personal opinions of the language author of how to do things or entirely subjective 'syntax sugar' features. Competition is good, monocultures are bad. > The most important consideration in any software project is managing architectural complexity No language will help you managing "architectural complexity" in any meaningful way except by imposing tons of arbitrary restrictions which then get in the way for smaller projects that don't need much "architecture". We have plenty of "Enterprise-scale languages" already (Java, C#, Rust, C++, ...), what we need is more languages for small teams that don't get in the way of just getting shit done, since the really interesting and innovative stuff doesn't happen in enterprise environments but in small 'basement and bedroom teams' :)
- kristoff_it 1y ago
  > I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C. This has been not my experience at all in the ~6 years I've been writing Zig. I started having very little experience writing C (<1000, lines all written while in university) and since day 1 Zig has been a tremendous improvement over it, even back when it was at version 0.4.0.
  - simonask 1y ago
    Glad you're having a great time with it. :-) I'm informed by having shipped a lot of C++ code in my time, which has taught me a lot about actually delivering stable software. Being better than C is a very low bar here.
- ozgrakkurt 1y ago
  This is a subjective argument. You don’t know me, I don’t know you. There is no meaning in assuming anything. There is plenty of working software written with pretty much any language
kstenerud 1y ago
> It is extremely difficult to write low level libraries in Rust Really? I've not found it at all difficult to write low level libraries in Rust.
- ozgrakkurt 1y ago
  For me it was very difficult to make an io library on io_uring that is properly safe. Also using arena and other special allocators in different sections of the program. While maintaining hard memory limits for different sections of the program. These are possible to do in rust but it is very difficult for me so I decided to just not do it. Otherwise I have to spend 5x the normal amount of time to make sure the library cannot be misused by the user ever. This is pretty pointless since I’m the only one who is going to use that code anyway. Could be skill issue or w/e but I just find zig easier to make progress in

LAC-Tech 1y ago

Zig is a systems programming language. I think that's probably who it's targeting. People do systems programming in rust, but that's not really what most of the community is doing. And it's DEFINITELY not what the standard library is designed for.

konart 1y ago
>People do systems programming in rust, but that's not really what most of the community is doing. As someone who haven't done any systems programming after university: wait, what? I was under impression that this is exactly what people where doing with Rust.(system apps, even linux kernel, no?) If not - what do they (most if the community) are doing with Rust?
- LAC-Tech 1y ago
  Web servers, games, and applications, that sort of thing. Some people definitely do systems programming in, but it's a minority. The std library is not set up for it at all, you need something like rustix, but even that results in very unidiomatic ("unsafe") rust code. In Zig it's all in the std library by default. Because it's a systems programming language, first and foremost.
  - porridgeraisin 1y ago
    Actually I was also under OPs impression... can you tell me few specific problems with using rust for systems programming? BTW, I have only ever done something that resembles systems programming in C.
  - Ar-Curunir 1y ago
    Rust is in the Linux kernel. Doesn’t get more systems than that…
simonask 1y ago
Which part of the Rust standard library are you referring to here? As far as I can tell, it contains many, many features that are irrelevant outside of systems programming scenarios with highly particular needs.

sothatsit 1y ago

I love Zig precisely because it is so similar to C. Honestly, if you don't like C, I can totally understand why you wouldn't like Zig. But I love C, and I love Zig. Zig has become my go-to for projects where I would previously have reached for C, largely because Zig has such good compatibility with other C projects. Rust, on the other hand, is a completely different beast. It is very different from C, and it is far more complicated. That makes it harder to justify using, whereas Zig is a very easy choice as an alternative to using C itself.

simonask 1y ago
C is entirely as complicated as Rust, if your goal is to write correct software that doesn't crash all the time. It's only a syntactically simple language. Actually making anything interesting with it is _not_ simple.
- taminka 1y ago
  https://github.com/oxidecomputer/omicron/blob/5fd1c35/nexus/db-queries/src/db/pagination.rs#L78-L181 https://github.com/oxidecomputer/omicron/blob/5fd1c35/nexus/...
  - simonask 1y ago
    I don't think a 100-line function signature is representative, but I will point out that the alternative is at least 100 lines of runtime checks instead. In both cases, what a nightmare.
  - kelnos 1y ago
    To me that's more an indictment of Diesel than of Rust. I've been using sea-orm for a project I'm working on, and my (generic) pagination function is a hell of a lot simpler and readable than that one.
  - lll-o-lll 1y ago
    Yuck. I thought some of the signatures you end up with when building “Modern C++” in the Andrei Alexandrescu style were hairy, but this looks sick. Not in a good way. Probably does something cool for all that crazy though?

flohofwoe 1y ago

> a lack of proper sum types Do you consider Rust enums 'proper sum types'? If yes what are Zig's tagged unions missing? E.g.: const Variant = union(enum) { int: i32, boolean: bool, none, fn truthy(self: Variant) bool { return switch (self) { Variant.int => |x_int| x_int != 0, Variant.boolean => |x_bool| x_bool, Variant.none => false, }; } };

kristoff_it 1y ago

[flagged]

kllrnohj 1y ago

Zig is for people who want to write C, that's really it. It's not a replacement for C++ or Rust or Go or Swift or anything "serious". As for why you would choose it over C, because C has too many problems for even the C lovers to ignore. Zig fixes a tiny amount of them, just enough to pretend it's not problematic, but not enough to be useful in any non-hobby capacity. Which is fine, very few languages do achieve non-hobby status after all.