> In the case of rust we get to call these “compiler bugs” whereas in the C-language world such occurrences are more often labeled “undefined behavior”. C has

> In the case of rust we get to call these “compiler bugs” whereas in the C-language world such occurrences are more often labeled “undefined behavior”. C has both compiler bugs and undefined behaviour. Undefined behaviour is an inherent property of the C standard, while a compiler bug is a property of the implementation (a place where it doesn't match the standard). A valid argument along the same lines might be that the Rust compiler has existed for less time and is used less than C compilers, and therefore is more likely to contain bugs. > Because it is a newer language, it does not have (afaik) tools like gcov that are so helpful for doing machine-code testing. Coverage tools work on Rust, such as kcov. I'm not sure of the state of gcov itself though. > Nor are there multiple independently-developed rust compilers for diversity testing. Isn't diversity testing only necessary/good because there are many C compilers? Using your phrasing, if the code compiles and runs correctly (i.e. every single machine instruction is checked) with the one Rust compiler that exists, then it works. There's definitely many reasons why a language having multiple compilers is good, but I think "diversity testing" is circular logic.