Btw, why doesn't the STL contain also safe versions with access control? Like a second variant where the methods operator[] and at() are switched (cf https://en.cppreference.com/w/cpp/container/vector/at). That would be such an easy addition.
Are read faults considered Buffer Overflows?
I thought that was exclusively for writing, with other terms like Buffer overread for reading past the end of an array?
It is irrelevant to the point the article is making as a minor detail, just curious for my own knowledge.
> This means languages which emphasize security, at the cost of ease of use, are at a disadvantage.
Why make such languages in the first place? Especially considering that you don't need to, user experience is not in conflict with emphasizing security.
Suggesting rewrites is also a non-solution, given that you can make C much safer without rewrites. The problem here is rather different: you just want people to use Rust, not actually solve any of the raised issues.
I think we all like to think that our high level languages will save us from those pesky errors we encountered when learning how to program in C or C++.
Some definitely will be taken care of, but in the end, experience with and learning about the edge cases of your language is the only thing that can prevent you from writing code that doesn't do what you expect it to do.
For example, I am a functional programming fan boy, and once I was like "damn, these people can't stop writing code with null ref exceptions. What if I introduce them to the option type?"
In the end I just got a lot of questions about why this was a problem... so what do I know?
No mention of performance in the article; if you live on the server and can spare big bucks for compute, sure... go ahead and pay for your Java or C# runtimes.
Rust has its applications, but the static analysis ecosystem for C++ has come a long way. I can't imagine memory unsafety still being an issue in 99.9% of C++ code (and if it is, you need better tooling and policies, not a new language).
7 comments
[ 13.7 ms ] story [ 344 ms ] threadIt is irrelevant to the point the article is making as a minor detail, just curious for my own knowledge.
Why make such languages in the first place? Especially considering that you don't need to, user experience is not in conflict with emphasizing security.
Suggesting rewrites is also a non-solution, given that you can make C much safer without rewrites. The problem here is rather different: you just want people to use Rust, not actually solve any of the raised issues.
Some definitely will be taken care of, but in the end, experience with and learning about the edge cases of your language is the only thing that can prevent you from writing code that doesn't do what you expect it to do.
For example, I am a functional programming fan boy, and once I was like "damn, these people can't stop writing code with null ref exceptions. What if I introduce them to the option type?"
In the end I just got a lot of questions about why this was a problem... so what do I know?
Rust has its applications, but the static analysis ecosystem for C++ has come a long way. I can't imagine memory unsafety still being an issue in 99.9% of C++ code (and if it is, you need better tooling and policies, not a new language).