Something that is important to me is that it's caught at compile time. A memory issue is a logic bug. Fil-c simply moves that from undefined behavior/security issue/incorrectness to a crash. That's better than what it was. But I generally don't want my programs to crash. Having memory safety at compile time is much more worthwhile imo.

▲ muvlon an hour ago | parent | next [-]

As a Rust fanboy, I have to concede that Rust also doesn't have pure compile-time memory safety. Some checks are runtime there as well, in particular most of bounds safety.

▲ rowanG077 an hour ago | parent [-]

I agree. Rust does not go far enough imo. Still catching most memory problems at compile time is still much superior.

	▲	Animats 4 minutes ago \| parent [-]
		The important thing from a performance standpoint is to be able to hoist bounds checks out of inner loops. This avoids a check on each iteration. Languages which have constructs such as `for foo in bartab {}` can usually hoist checks out of inner loops almost for free. I used to argue with the C++ committee about to when it's OK to catch an error early. If you write `#define LEN 1000 int tab[LEN]; for (auto p = tab; p++; p <= LEN) { *p = 0; }` that's a buffer overflow. The question is, is the compiler allowed to generate checking code which will abort the program before entering the loop? Or does it have to execute all the iterations up to the subscript error? I argued that it's legit to catch an error at the point it becomes inevitable. This leads to bikeshedding objections: "But what if a signal interrupts the loop before it runs off the end". That's why you need a language where undefined behavior has been nailed down to do this optimization properly.

▲ wat10000 2 hours ago | parent | prev [-]

It’s the exact opposite for me. Catching it at compile time is great, but the most important thing by far is that it’s caught somewhere instead of creating a security issue.