Ariadne Conill 🐰 on Nostr: anyway. do we have a memory safety crisis? yes. is Rust a valuable tool in getting ...
anyway.
do we have a memory safety crisis? yes.
is Rust a valuable tool in getting our way out of this crisis? also yes.
is rewriting all of the software that the world's IT systems depend on in Rust a sustainably achievable solution for this crisis? no, there is way too much software to rewrite.
the answer to this problem is two-fold:
- write new software in modern languages that help with memory safety (e.g. Rust's borrow checking, traits, etc.) where it makes sense to do so
- train software engineers to have a full understanding of memory safety concerns and how to write code in legacy programming languages that is robust and memory safe, allowing for software written in legacy codebases to become more memory safe over time
we need *both* of these things.
we *also* need people to still write software in C, so that they are practicing their skills in maintaining the code that exists in the world today.
we *also* need people who are writing software in modern languages to *also* have an understanding of memory safety fundamentals, because compilers and languages are not infallible.
like COBOL, embedded C developers are in increasingly high demand, and the salaries are growing like wildfire. this is because there are codebases that are running on safety critical systems, like avionics, which rewriting in a different language would require a product recertification.
in other words, C, COBOL and Fortran are always going to exist and pretending otherwise is a fantasy. but we can at least teach developers how to avoid shooting themselves in the foot when maintaining software which uses them.
do we have a memory safety crisis? yes.
is Rust a valuable tool in getting our way out of this crisis? also yes.
is rewriting all of the software that the world's IT systems depend on in Rust a sustainably achievable solution for this crisis? no, there is way too much software to rewrite.
the answer to this problem is two-fold:
- write new software in modern languages that help with memory safety (e.g. Rust's borrow checking, traits, etc.) where it makes sense to do so
- train software engineers to have a full understanding of memory safety concerns and how to write code in legacy programming languages that is robust and memory safe, allowing for software written in legacy codebases to become more memory safe over time
we need *both* of these things.
we *also* need people to still write software in C, so that they are practicing their skills in maintaining the code that exists in the world today.
we *also* need people who are writing software in modern languages to *also* have an understanding of memory safety fundamentals, because compilers and languages are not infallible.
like COBOL, embedded C developers are in increasingly high demand, and the salaries are growing like wildfire. this is because there are codebases that are running on safety critical systems, like avionics, which rewriting in a different language would require a product recertification.
in other words, C, COBOL and Fortran are always going to exist and pretending otherwise is a fantasy. but we can at least teach developers how to avoid shooting themselves in the foot when maintaining software which uses them.