Besides of memory safety, what is different in panicking? I'm not trying to argue - I don't know it. For me result is the same - process failed. What is difference in consequences for memory?

Not all violations of memory safety result in immediate program termination. There's an intervening period of execution during which your program simply performs unintended operations such as overwriting unrelated memory (which could be a memory-mapped file), terminating "correctly" (and performing whatever operations that entails) with corrupt state, and generally an unbounded set of other potential consequences. An immediate segfault is the absolute best hope for a program without memory safety, since you both see no unintended effects performed on the program's behalf and you learn that your program needs fixing.

Got it, thank you.

Panic behaviour is well defined. Segfaults are non-reliable (i.e. it might or might not crash) and often exploitable.

There are tools you can use with C compilers that don't access OOB memory on OOB access. What's your point?

I think I'd rather not have it panic at all. They were making a language from scratch and still didn't solve the crash-at-runtime problem that C has. Instead they just made a common C compiler option default and called it 'safe'.

It's worse than the fact that the Go creators ignored years of research after the year 1970 and didn't implement generics, for no good reason.

Rust's safety is a joke, and so is the idea that a lot of it is anything 'new'. They had the chance to fix it and they didn't. Boo.

Which common C compiler has a production quality implementation of array bounds checking?

Before you say Address Sanitizer you should be aware that its authors intended it as a debugging tool and recommend against using it in production as it introduces new attack surface, as described in the "Address Sanitizer local root" mail.

http://seclists.org/oss-sec/2016/q1/363

> What's your point?

My point is that panics are memory safe, contrary to what my parent said.