Rust gives two reasons for the borrow checker, iterator invalidation and use after free.
As I have always bought into
Dennis Ritchie's loop programming concepts, iterator invalidating hasn't been a problem.
Zig has defer which makes it trivial to place next to allocation, and it is released when it goes out of scope.
As building a linked list, dealing with bit fields, ARM peripherals, etc...; all require disabling the Rust borrow checker rules, you don't benefit at all from them in those cases IMHO.
It is horses for courses, and the Rust project admits they chose a very specific horse.
C is what it is, and people who did assembly on a PDP7 probably know where a lot of that is from.
I personally prefer zig to c... but I will use c when it makes the task easier.
As I have always bought into Dennis Ritchie's loop programming concepts, iterator invalidating hasn't been a problem.
Zig has defer which makes it trivial to place next to allocation, and it is released when it goes out of scope.
As building a linked list, dealing with bit fields, ARM peripherals, etc...; all require disabling the Rust borrow checker rules, you don't benefit at all from them in those cases IMHO.
It is horses for courses, and the Rust project admits they chose a very specific horse.
C is what it is, and people who did assembly on a PDP7 probably know where a lot of that is from.
I personally prefer zig to c... but I will use c when it makes the task easier.