[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.