Just a historical note: Rust's ownership system has much historical pedigree, such as the Cyclone language and the work on ML compilers with region inference, following Tofte and Talpin's pioneering work. The Wikipedia article (https://en.wikipedia.org/wiki/Region-based_memory_management...) has a good overview.
Around 2002, when there was concern about computer-related terrorism, I suggested that the C++ standards committee's unwillingness to deal with memory safety constituted material support of terrorism. They were angry, and terrified. That post was actually deleted from their USENET group.
Although as a long-time C++ programmer I'm the first to criticize it when it deserves it, that's a pretty assholish thing to suggest. As if we needed more decisions being made by fear instead of logic around that time.
> memory safety constituted material support of terrorism.
I love this. Not the terrorism charge per-se, but the general idea. Using unsafe code should be shunned, in general. After Rust 1.0 or so, any new C projects, especially for people not heavily invested in C, should be met with questioning.
I'm looking at this one project, mostly PHP. But they need some socket and packet handling, and they wrote it in C. Complete with lines like:
thing = malloc(somesize); // gets memory
...
free(thing); // give memory back
And network-connected string parsing galore. Or a million line project, used in many networks, compete with its own hacked up XML processor, that has never issued a security advisory. I'm looking forward to a time when the choice to use C here would be questioned and viewed with a doubtful eye by everyone.
Propaganda similar to "loose lips sink ships", aimed at memory unsafe code, might help achieve that goal.
Around 2002, when there was concern about computer-related terrorism, I suggested that the C++ standards committee's unwillingness to deal with memory safety constituted material support of terrorism. They were angry, and terrified. That post was actually deleted from their USENET group.