Arguably Zig has a simpler approach to memory management (which can also lead to more errors, arguably) which makes the transition from
C somewhat easier. Downside is that the language is still under heavy development and you definitely have to be up for the ride.
Agreed that it makes the transition from C easier, but I’d also say it makes the transition from C more pointless. I don’t really know that much about Zig but from what I’ve heard, I don’t really get the benefits - if you want a fast systems-level language without guard rails, why aren’t you just writing C (or C++, if that’s your thing)?
Zig is way better than C in many other respects, so if you want a modern sane language and you’re either a Rust luddite or working on a project where memory safety isn’t that important, it might be attractive.
Like, if the choice is C or Zig, then Zig is pretty much a no-brainer (or it will be when it hits 1.0). It just fixes so many insane things about C that have been broken for literal decades.
working on a project where memory safety isn’t that important
I can’t really imagine anything where this is not the case, unless you’re doing like… I dunno, small scripts for personal use or something? But why would you use Zig or C or even Rust for that, just do Python or even bash at that point? Python is memory safe and perfectly suitable for very small programs where static analysis gives little benefit.
There are definitely some cases where memory safety isn’t especially important:
Single player games
Apps that don’t process external data (e.g. a simple calculator).
Lots of things running on microcontrollers, where the form of input could never possibly cause any security issues. E.g. a motor controller or a basic syringe pump or a (non-smart) washing machine or something.
Tests, e.g. I’ve considered writing RISC-V tests in Zig. They’re traditionally written in C or assembly.
In cases like those, memory unsafety mainly leads to non-security bugs and annoying debugging sessions. But I wouldn’t say it’s as much of a deal breaker compared to e.g. writing a video codec or font renderer or web browser or DNS server or whatever.
I still think Rust is a better choice than Zig in most cases anyway, even ignoring memory safety. But in these cases it’s at least a defensible choice.
zig does have guard rails, they’re just different approaches. zig defaults to optional types where null must be handled. and memory safety is checked through unit testing and exposing debugger memory allocators that check for different memory corruption bugs.
rust takes a shift left approach where all declarations drive safety whereas zig takes a more laid back shift right where it’s expected you’ll have written tests. rust will force all developers to conform to produce good code where zig requires a bit more though, i mean every dev writes test cases right?
Saying that “memory safety is checked by tests” is basically saying “memory safety is not checked”. Yes, you can write tests. How do you know the tests cover all cases? How do you know the tests aren’t buggy?
Also, what about memory safety across threads? Are you testing multi-threaded scenarios? Are you ensuring you have no data races?
I also don’t understand how this is an argument for Zig over C. You can also test memory safety of your C code via various means, but it’s never a guarantee. Zig is the same. So again, it seems a bit more pointless to go from C to Zig. Going from C to Rust brings actual tangible guarantees of memory safety (outside of any unsafe usage, obviously).
in c code you will see malloc, alloc, free w/e scattered through the code base, most static tools lack because they don’t control the memory and just analyze address spaces or do static code analysis. they look top down and try to catch errors.
zig’s design forces you to create a memory allocator before any object initializations (alloc/free) and is typically constructed at the top level and passed through to functions. this allows you to swap implementation easily and use the allocator to claim memory or return an error to the caller if it can’t.
you can do some simple static allocator, general purpose allocator (can grow memory space as you allocate more objects) or in this case to test memory safety a debug allocator which you use in your tests. This moves the memory inspection inside of where your program allocates memory. this is more of an inside out approach where the analysis is produced by controlling the memory allocations and frees through a standard interface.
@SorteKanin@kewjo Fuzzing! Zig is working on an integrated fuzzer that will work seamlessly with the testing system.
And for those cases you don’t catch, there’s ReleaseSafe which have runtime checks to prevent illegal behavior.
Zig removes a lot of the footguns of C and also provides a lot of the tools you’ll need anyway built-in. The debug allocator does leak-checking. You have to unwrap your nulls. There is compile-time duck-typing so generic data structures don’t have to rely on void pointers. Also no separate preprocessor language.
Arguably Zig has a simpler approach to memory management (which can also lead to more errors, arguably) which makes the transition from C somewhat easier. Downside is that the language is still under heavy development and you definitely have to be up for the ride.
Agreed that it makes the transition from C easier, but I’d also say it makes the transition from C more pointless. I don’t really know that much about Zig but from what I’ve heard, I don’t really get the benefits - if you want a fast systems-level language without guard rails, why aren’t you just writing C (or C++, if that’s your thing)?
Zig is way better than C in many other respects, so if you want a modern sane language and you’re either a Rust luddite or working on a project where memory safety isn’t that important, it might be attractive.
Like, if the choice is C or Zig, then Zig is pretty much a no-brainer (or it will be when it hits 1.0). It just fixes so many insane things about C that have been broken for literal decades.
I can’t really imagine anything where this is not the case, unless you’re doing like… I dunno, small scripts for personal use or something? But why would you use Zig or C or even Rust for that, just do Python or even bash at that point? Python is memory safe and perfectly suitable for very small programs where static analysis gives little benefit.
There are definitely some cases where memory safety isn’t especially important:
In cases like those, memory unsafety mainly leads to non-security bugs and annoying debugging sessions. But I wouldn’t say it’s as much of a deal breaker compared to e.g. writing a video codec or font renderer or web browser or DNS server or whatever.
I still think Rust is a better choice than Zig in most cases anyway, even ignoring memory safety. But in these cases it’s at least a defensible choice.
zig does have guard rails, they’re just different approaches. zig defaults to optional types where null must be handled. and memory safety is checked through unit testing and exposing debugger memory allocators that check for different memory corruption bugs.
rust takes a shift left approach where all declarations drive safety whereas zig takes a more laid back shift right where it’s expected you’ll have written tests. rust will force all developers to conform to produce good code where zig requires a bit more though, i mean every dev writes test cases right?
🤣 🤣🤣🤣🤣🤣
Saying that “memory safety is checked by tests” is basically saying “memory safety is not checked”. Yes, you can write tests. How do you know the tests cover all cases? How do you know the tests aren’t buggy?
Also, what about memory safety across threads? Are you testing multi-threaded scenarios? Are you ensuring you have no data races?
I also don’t understand how this is an argument for Zig over C. You can also test memory safety of your C code via various means, but it’s never a guarantee. Zig is the same. So again, it seems a bit more pointless to go from C to Zig. Going from C to Rust brings actual tangible guarantees of memory safety (outside of any
unsafeusage, obviously).in c code you will see malloc, alloc, free w/e scattered through the code base, most static tools lack because they don’t control the memory and just analyze address spaces or do static code analysis. they look top down and try to catch errors.
zig’s design forces you to create a memory allocator before any object initializations (alloc/free) and is typically constructed at the top level and passed through to functions. this allows you to swap implementation easily and use the allocator to claim memory or return an error to the caller if it can’t.
you can do some simple static allocator, general purpose allocator (can grow memory space as you allocate more objects) or in this case to test memory safety a debug allocator which you use in your tests. This moves the memory inspection inside of where your program allocates memory. this is more of an inside out approach where the analysis is produced by controlling the memory allocations and frees through a standard interface.
@SorteKanin @kewjo Fuzzing! Zig is working on an integrated fuzzer that will work seamlessly with the testing system.
And for those cases you don’t catch, there’s ReleaseSafe which have runtime checks to prevent illegal behavior.
Zig removes a lot of the footguns of C and also provides a lot of the tools you’ll need anyway built-in. The debug allocator does leak-checking. You have to unwrap your nulls. There is compile-time duck-typing so generic data structures don’t have to rely on void pointers. Also no separate preprocessor language.
To prevent some illegal behaviour. Again, I’m not an expert on Zig, but as far as I understand, even Release"Safe" is not actually memory safe.