I say this because achieving that level of memory safety is a significant engineering challenge for Zig. Without a borrow checker like Rust’s, Zig relies heavily on developer discipline and runtime checks. How can we ensure it reaches the same level of reliability for mission-critical systems without adding too much complexity?
To be fair, adding a borrow checker is not the solution to memory safety - it’s just a way to impose a philosophical strong opinion about ownership, which incidentally prevents some types of memory bug in some common situations. It’s a subtle difference.
pony’s capability restrictions are a different approach again, which prevents some memory safety issues, with the added bonus of not requiring locks to avoid race conditions.
Erlang achieves very strong memory safety by having every object operate in its own hermetically sealed environment. No borrow checker needed.
Intercal achieves perfect memory safety by making it almost impossible for the programmer to write a program that compiles, let alone runs.
none of these memory safe tools solve memory safety - they all provide a restricted subset of ways to build applications, and fence off the more dangerous areas that are needed for a true general purpose tool aimed at supplementing C
2 Likes
On the contrary. It invited me in my short rust life to write insanely unsafe code 
1 Like
Maybe this is pedantic, but it seems you’ve adopted your own definition for “memory safety” that is not a common one. There is no other definition I know of that says a solution that provides memory safety may not make any restrictions.
I guess you’re saying that you don’t consider any solution to memory safety acceptable, unless there are no restrictions added. Is that right?