This “skills issue” thing just sounds so stupid in my ears. I am sick of reading it.
So, I am choosing a language that I hope will ensure fast, secure, and sophisticated code for my project. It has to do this for code I write, my team writes, and all future maintainers and contributors will write as well. If I choose a language that makes it easy to write unstable, fragile, and insecure code then “the skills issue” applies more to my lack of capability as an architect than it does the coders that come after me.
Stop saying, “well ya, it is super easy to make these mistakes in this language but that would never happen if you are as awesome as I am” and thinking that sounds like an intelligent argument for your language choice. There are better options. Consider them.
Why do you want sophisticated code ? That word seems out of place from the other two to me.
Rust doesn’t introduce the same problems as C, but it sure does introduce a lot of other problems in making code overly complicated. Lifetimes and async are both leaky abstractions (and don’t even work as advertised, as rust-cve recently demonstrated), macros can hide control flow…
C is unsafe, sure, but also doesn’t pretend to be safe. C is also stupid simple, and that’s a good thing : you can’t just slap ArcMutexes around, because by the time you know how to code them yourself you also know why you shouldn’t do that.
I hope Rust can reach a point where its safety model can be formally proven, and we have a formal specification and a stable ABI so we don’t have to hard-compile every crate into the binary.
But I personally expect something with some of Rust’s ideas, but cleaned up, to do that instead. Actually, I wouldn’t be surprised if C itself ends up absorbing some of Rust’s core ideas in an upcoming standard.
This “skills issue” thing just sounds so stupid in my ears. I am sick of reading it.
So, I am choosing a language that I hope will ensure fast, secure, and sophisticated code for my project. It has to do this for code I write, my team writes, and all future maintainers and contributors will write as well. If I choose a language that makes it easy to write unstable, fragile, and insecure code then “the skills issue” applies more to my lack of capability as an architect than it does the coders that come after me.
Stop saying, “well ya, it is super easy to make these mistakes in this language but that would never happen if you are as awesome as I am” and thinking that sounds like an intelligent argument for your language choice. There are better options. Consider them.
Why do you want sophisticated code ? That word seems out of place from the other two to me.
Rust doesn’t introduce the same problems as C, but it sure does introduce a lot of other problems in making code overly complicated. Lifetimes and async are both leaky abstractions (and don’t even work as advertised, as rust-cve recently demonstrated), macros can hide control flow…
C is unsafe, sure, but also doesn’t pretend to be safe. C is also stupid simple, and that’s a good thing : you can’t just slap ArcMutexes around, because by the time you know how to code them yourself you also know why you shouldn’t do that.
I hope Rust can reach a point where its safety model can be formally proven, and we have a formal specification and a stable ABI so we don’t have to hard-compile every crate into the binary.
But I personally expect something with some of Rust’s ideas, but cleaned up, to do that instead. Actually, I wouldn’t be surprised if C itself ends up absorbing some of Rust’s core ideas in an upcoming standard.
Isn’t rust-cve based on a single error of the borrow checker?