I'm not entirely clear on your point. Are you suggesting that writing in C as opposed to Rust is somehow morally cleansing? Or are you suggesting that having higher level abstractions is somehow ruinous to ability?
The evidence is pretty clear that programming in C does not confer enough skill to prevent disastrous mistakes despite its near-hardware level of abstraction, so I'd really like to know what you're saying here.
I don't think I worded my original comment in the best way. However, I find that the people who make statements like "C makes it far more difficult to write safe and correct code" haven't touched the language in years if ever. Hence, no wonder it will be difficult for them because they have not practiced or been exposed to good C idioms. Correct code in C is actually easy since the language is very simple. Due to this simplicity, unit-testing is very easy yet lots of legacy codebases don't use these testing strategies to their potential. If they did lots of issues would be corrected.
Although I cannot refute there are additional memory-related issues to be aware of in C, it is precisely such awareness that make someone a better programmer because its how the underlying hardware works. For instance, parallelizing algorithms must take into account cache-alignment boundaries and so on.
Abstractions are good. However, too much abstraction is bad. Just as too much of anything is a bad thing. When people rely solely on such abstractions, it is in fact ruinous to ability.
That being said, higher-level languages certainly have their place. But I firmly believe that C is a high-enough abstraction for systems programming and with proper idioms and testing strategies, it can be just as safe as the plethora of garbage-collected languages out there in the wild.
> Correct code in C is actually easy since the language is very simple.
1. No, it's not. Witness the various arguments that have happened on HN over the years concerning whether the imprecise language of the spec makes some idiom undefined behavior or not.
2. The evidence over the past 35 years has not shown that correct code is "simple" in C.
> For instance, parallelizing algorithms must take into account cache-alignment boundaries and so on.
…which Rust makes you just aware of as C does.
> But I firmly believe that C is a high-enough abstraction for systems programming and with proper idioms and testing strategies, it can be just as safe as the plethora of garbage-collected languages out there in the wild.
1. Rust isn't garbage collected.
2. Your firm belief is contradicted by 35 years' worth of memory safety track records of large-scale software written in C.
"The evidence over the past 35 years has not shown that correct code is 'simple' in C."
"Your firm belief is contradicted by 35 years' worth of memory safety track records of large-scale software written in C."
Keep in mind, of those 35 years, it only makes sense to consider the last decade-onward (or so) in comparison. While the language hasn't changed a whole lot, programming methodologies certainly have. How many of those libraries in question were written within the last 5 or 10 years? What is the code coverage on them? Et cetera.
I am not trying to argue that C is perfect and everything should be written in C. That would be crazy! There are definitely issues with C no doubt--but so many people say C is dangerous and difficult when in fact they don't even practice using the language. This is no different than practicing Violin on a daily basis and saying Cello is difficult so people should stop playing Cello (not a perfect analogy but you know what I mean).
The other comments is just me ranting at how the majority of programmers don't understand important computer-science concepts because of their removal from such concepts by higher-level languages. And sometimes its important to have a higher level abstraction to help solve certain problems. But, people have a tendency to become lazy and therefore they lose the fundamentals over time.
> Keep in mind, of those 35 years, it only makes sense to consider the last decade-onward (or so) in comparison. While the language hasn't changed a whole lot, programming methodologies certainly have.
The last decade has seen an explosion of modern C++ code using best practices that routinely exhibits the same memory safety issues. C is worse.
> There are definitely issues with C no doubt--but so many people say C is dangerous and difficult when in fact they don't even practice using the language.
I practice C all the time and I think it's dangerous and difficult. I've seen so many brilliant programmers accidentally create game-over RCEs via use after free, for example.
Is it? You're telling me that all code in all browsers have been re-written into C++11 (or C++14) with best practices? I don't believe you. At a minimum, I'm going to need some documentation before I believe that.
[Edit: I'm not trying to pull a No True Scotsman here. I just doubt that browsers have been completely rewritten into modern C++, or with anything approaching best practices. I've seen how long old code lives to believe it without some supporting evidence.]
Most exploits tend to be in new code (contrary to popular belief), which in all modern browsers is written in modern C++. The WTF (Blink/WebKit) and the MFBT (Firefox) are state-of-the-art template libraries; you are free to search for those libraries and verify for yourself. New C++11 features such as rvalue references do nothing to avoid memory safety problems; in fact, they make them worse, since "use-after-move" is now a problem whereas it wasn't before.
I know it's hard to believe, but C++ is not memory safe, old C++ or modern C++, in theory or in practice. The new C++ features do effectively nothing to change this. As far as use-after-free goes, C++ basically adds safety over C in two places: (1) reference counting is easier to use and is easier to get right; (2) smart pointers are arguably somewhat less likely to get freed before accessed again due to the destructor rules (though I think (2) may not be true in practice). Browsers have been making use of these two features for a very long time.
Bringing up modern C++ here is "no true Scotsman" unless you can point to a specific C++11 feature that browsers are not using that is a comprehensive solution to the use-after-free vulnerabilities they suffer from. There is no such feature I am aware of.
No, I wasn't asserting that there is some magic C++ feature that the browsers aren't using. "Most exploits tend to be in new code" was the piece of your argument that I was missing.
I am certainly biased as I enjoy procedural languages for their simplicity. So many constructs in the others. As the saying goes, C++ is my favorite 4 languages. I hope that doesn't become the fate of Rust. Go-Lang seems to get that part properly then that's probably debatable.
> "Correct code in C is actually easy since the language is very simple."
I broke back into this account just to share my marvel at the singly most wrong sentence in human history. The Mona Lisa of being incorrect about programming.
I audit code for security vulnerabilities in several languages professionally. You are correct about the benefits of unit testing, which is language agnostic, but C is not and cannot be Easy To Be Correct, ever, no matter what.
The evidence is pretty clear that programming in C does not confer enough skill to prevent disastrous mistakes despite its near-hardware level of abstraction, so I'd really like to know what you're saying here.