[davemp]

Without explicitly entering the language holy wars. I think there’s an interesting trade-off here.

Static analysis based approaches restrict what is possible to express in the language (See: doubly linked lists). But can have lower dynamic overhead.

Ways to work around expressiveness limitations include strategies such as using indices into an array instead of pointers. Which in turn incurs the dynamic overhead from bounds checking.

Maybe zig could find a way to elide enough of the capability overhead that careful programming could get a <2x penalty vs C. Maybe explicit opt-in built in types or something. This would essentially be the reverse of unsafe blocks, but then there’s no escape hatch.

Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries. This would be great for compile times and places where open source is not tenable.

Regardless, I’m very happy to see another independent school of thought approach memory safety. I’ll forgive Mr. Kelly any gruffness, these topics can be quite annoying to discuss in public.

[tstack]

You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug.

> Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries.

One of the benefits of having lifetimes in the type system is thread-safety. Again, there is a lot of focus here on just memory-management: use-after-free, double-free, etc... But, being confident in the code running in a threaded environment is important as well.

[davemp]

Looks like Mr. Kelly agrees with you. From the zen of zig:

- Runtime crashes are better than bugs.

- Compile errors are better than runtime crashes.

- Incremental improvements.

- Avoid local maximums.

Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.

Personally, I’d like to see refinement types that allow people to elide the runtime overhead/panics. Though that may be too much complexity to stomach.

[tstack]

> Looks like Mr. Kelly agrees with you. From the zen of zig:

... what? No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors. Which is fine, but saying he is in agreement is nonsense.

> Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.

Many of those languages go to great lengths to avoid raw indexing: rich iterators, arenas with branded indexes, checked gets, and so on... But, sure, if you ignore all that and do `get(i).unwrap()`. Then, yes, things are exactly the "same".

I have no problem with people choosing the set of tradeoffs that works for their context. I have a problem with people acting like those tradeoffs don't exist.

[davemp]

> No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors

>> Compile errors are better than runtime crashes

I don’t think you’re being fair here.