4 ms·

Zig is in the space of languages where an abstraction that decides that memory allocations are irrecoverable is not good enough. If you work in an environment

by lionkor 5mo ago

Zig is in the space of languages where an abstraction that decides that memory allocations are irrecoverable is not good enough. If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, or C for that matter. Not every language should be designed to live in the space of "somehow low level but also a good choice for your basic web backend", like Rust.

Panzerschrek 5mo ago
> If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, It's most of environments. Basically any program running under a modern OS. So, why do this language exists, if its practical applicability is so small?
- lionkor 5mo ago
  On modern OSs you can write Zig and just ignore allocation errors. It doesn't force you to handle them properly. This language exists to supercede or supplement C, not JavaScript or C#. It's practical applicability is similar to that of C, so I struggle to comprehend how it is "so small".
  - Panzerschrek 5mo ago
    > On modern OSs you can write Zig and just ignore allocation errors. I can ignore errors, but I still need to free memory manually if I want to avoid memory leaks. Languages like C++ or Rust have destructors, which do the job for me. > This language exists to supercede or supplement C There are way better alternatives, like Rust. Even C++ is better.
    - lionkor 4mo ago
      Zig has defer, your point is quite invalid.
      - Panzerschrek 4mo ago
        defer can be forgotten to be written. C++ always calls destructors for local variables without additional programmer's intervention needed.
- Zambyte 5mo ago
  This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail. Let's say you write an application that runs as a Unix daemon in Zig. Later you may decide that your application is really the only thing you're interested in running on the target machine, and for performance and predictability reasons, you'd prefer to boot directly to your application, instead of to an OS that launches your daemon. You can just swap out the implementation of the std.Io runtime for one that targets the hardware directly, instead of a Unix. You don't have to make any changes to your application. That's kind of an extreme case, but it's the kind of flexibility Zig provides.
  - Panzerschrek 5mo ago
    > This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail. In my hypothetical example of a language where allocation fails aren't exposed it's possible too. An allocation fail just triggers a full system reboot.
- audunw 5mo ago
  You don’t know there’s still millions of lines of code being written for environments with no OS or much more limited OS than what’s on modern desktops/laptops/servers?
kibwen 5mo ago
Rust doesn't stop you from checking if memory allocation has failed. Its libstd provides many operations that don't bother to surface memory allocation failure (for the reasons given above), but that's why Rust provides a libcore that does no allocation, while continually working to push more things down from libstd into libcore, while providing alternative APIs in libstd to let you handle allocation failure if you know you actually need to.
- Zambyte 5mo ago
  Conversely, Rust doesn't force you to explicitly handle if memory allocation failures. The least you can do in Zig is explicitly ignore allocation failures.
  - kibwen 5mo ago
    You can certainly write data structures in Zig that swallow allocation failures rather than surfacing them. We're talking about library-level concerns, not language-level concerns. Both Rust and Zig give you the power to allocate raw memory and handle the result of that syscall however you want, it's the standard libraries that differ beyond that point.
    - Zambyte 5mo ago
      Yes, it is a standard library difference. But unless you plan on rewriting the entire Rust ecosystem, you're going to be dealing with invisible failure points in Rust code that you would not be dealing with when writing the equivalent Zig code. The standard library is almost as fundamentally important to a language as it's built-in operators. And Zig does have language-level features that combine to require you to explicitly handle propagated errors (error sets, requiring all return values be explicitly handled, requiring all switch cases be explicitly handled). Rust has a similar set of features (pattern matching, requiring all match cases be explicitly handled), but does not use them for allocation (Box::new, vec![], etc. does not return a Result value).
      - 5mo ago

by lionkor 5mo ago

Panzerschrek 5mo ago

> If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, It's most of environments. Basically any program running under a modern OS. So, why do this language exists, if its practical applicability is so small?

lionkor 5mo ago
On modern OSs you can write Zig and just ignore allocation errors. It doesn't force you to handle them properly. This language exists to supercede or supplement C, not JavaScript or C#. It's practical applicability is similar to that of C, so I struggle to comprehend how it is "so small".
- Panzerschrek 5mo ago
  > On modern OSs you can write Zig and just ignore allocation errors. I can ignore errors, but I still need to free memory manually if I want to avoid memory leaks. Languages like C++ or Rust have destructors, which do the job for me. > This language exists to supercede or supplement C There are way better alternatives, like Rust. Even C++ is better.
  - lionkor 4mo ago
    Zig has defer, your point is quite invalid.
    - Panzerschrek 4mo ago
      defer can be forgotten to be written. C++ always calls destructors for local variables without additional programmer's intervention needed.
Zambyte 5mo ago
This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail. Let's say you write an application that runs as a Unix daemon in Zig. Later you may decide that your application is really the only thing you're interested in running on the target machine, and for performance and predictability reasons, you'd prefer to boot directly to your application, instead of to an OS that launches your daemon. You can just swap out the implementation of the std.Io runtime for one that targets the hardware directly, instead of a Unix. You don't have to make any changes to your application. That's kind of an extreme case, but it's the kind of flexibility Zig provides.
- Panzerschrek 5mo ago
  > This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail. In my hypothetical example of a language where allocation fails aren't exposed it's possible too. An allocation fail just triggers a full system reboot.
audunw 5mo ago
You don’t know there’s still millions of lines of code being written for environments with no OS or much more limited OS than what’s on modern desktops/laptops/servers?

kibwen 5mo ago

Rust doesn't stop you from checking if memory allocation has failed. Its libstd provides many operations that don't bother to surface memory allocation failure (for the reasons given above), but that's why Rust provides a libcore that does no allocation, while continually working to push more things down from libstd into libcore, while providing alternative APIs in libstd to let you handle allocation failure if you know you actually need to.

Zambyte 5mo ago
Conversely, Rust doesn't force you to explicitly handle if memory allocation failures. The least you can do in Zig is explicitly ignore allocation failures.
- kibwen 5mo ago
  You can certainly write data structures in Zig that swallow allocation failures rather than surfacing them. We're talking about library-level concerns, not language-level concerns. Both Rust and Zig give you the power to allocate raw memory and handle the result of that syscall however you want, it's the standard libraries that differ beyond that point.
  - Zambyte 5mo ago
    Yes, it is a standard library difference. But unless you plan on rewriting the entire Rust ecosystem, you're going to be dealing with invisible failure points in Rust code that you would not be dealing with when writing the equivalent Zig code. The standard library is almost as fundamentally important to a language as it's built-in operators. And Zig does have language-level features that combine to require you to explicitly handle propagated errors (error sets, requiring all return values be explicitly handled, requiring all switch cases be explicitly handled). Rust has a similar set of features (pattern matching, requiring all match cases be explicitly handled), but does not use them for allocation (Box::new, vec![], etc. does not return a Result value).
    - 5mo ago