Exactly, this is what I should have explicitly said. Language defaults have a powerful effect on a project's norms and culture.
> You have to go out of your way to get these things wrong.
Yes, you actually have to try to write shitty Rust code, at least where there are defaults that prevent it. Thus the average Rust program will have that baseline level of quality. Like TQM/TPM/Six-Sigma for manufacturing software.
Also that is besides the point, unsafe only deals with a very specific cause of errors that plague C code bases (and those of languages copy-paste compatible with it).
Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r.
It is no accident that Ada and Java also have security guidelines similar to MISRA, because even with memory corruption bugs out of the picture, as log4j newly remided us, security only happens when it is part of the daily process, regardless of the language.
As for the memory fuckups you are right, pity that they are using a C GUI library.
Even if the binding has been deemed safe upon validation, if only remains a valid certification until the next Gtk version update, even minor ones might break the assumptions validated on the unsafe code block.
You are correct. No programming language will protect you from writing flawed application logic.
> pity that they are using a C GUI library. (...) Gtk version update, even minor ones might break the assumptions
I don't know about that. GTK is more "battletested" than most frameworks, and has a lot of contributors to fix bugs. Also, and that's a very important point, GTK cares for accessibility! Using any other framework would have meant excluding a lot of people from the GUI.
As for assumptions, i certainly hope GTK devs don't push breaking changes to the ABI on minor updates. But i guess that's yet another assumption that can be broken.