3 ms·
> It hasn’t completely replaced C The keyword here is completely. Rust doesn't need to completely replace C, it only needs to cover those usecases other langua
by bhaak 8y ago
> It hasn’t completely replaced C
The keyword here is completely. Rust doesn't need to completely replace C, it only needs to cover those usecases other languages haven't already covered. Or maybe just some and a completely different language takes what is left.
You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être.
If you dismiss this outright, you could have written a much shorter article or at least written a much more interesting article by starting with this admission and from that working your way through Rust's feature and explaining how this doesn't alleviate the warts of Rust.
> But now you know why we are still writing C
I wonder who this "we" is?
I'm also still writing C but for quite different reasons. Mostly because of legacy code and to some degree even just to be able to claim that I'm working on 35 year old code.
- bb88 8y ago> You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être. Rust is still young. I think it's a bit naive to proclaim the language of the future is here. Why? That was also the point of Ada until people realized that unhandled Constraint Errors could still crash missiles. https://itsfoss.com/a-floating-point-error-that-caused-a-damage-worth-half-a-billion/ https://itsfoss.com/a-floating-point-error-that-caused-a-dam... That was the point of Java until people realized that JRE's were full of security holes. https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html https://www.cvedetails.com/vulnerability-list/vendor_id-93/p... So, what's the point of Rust again? To protect us from all these security holes? Wasn't that also the goal of other languages? > I wonder who this "we" is? TIOBE says C is second most popular language after Java even with all the security holes. So there's a lot of "we" (though I don't code in C). https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
- bhaak 8y ago> Rust is still young. I think it's a bit naive to proclaim the language of the future is here. I never claimed that Rust is the language of the future. I didn't say it directly but I think you can deduce it from my comments that I consider a multi language approach more sensible than using the same programming language for everything. Using Rust is more safe than using C. That's valuable. > So, what's the point of Rust again? To protect us from all these security holes? Wasn't that also the goal of other languages? Are you saying that just because Rust doesn't solve all problems it isn't worth having? You're also conflating stuff. The Ariane 5 explosion was not a programming error, it was a testing and specification error. The code worked exactly to the spec but the spec was for another piece of hardware. You can't use a fork and complain that it's not a good spoon. How about quantifying the bugs in the JRE against all the buffer overflows in similar C code? 600 CVE worthy bugs in 10 years doesn't sound like that much if you put it that way. https://www.cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 https://www.cvedetails.com/product/19117/Oracle-JRE.html?ven... > TIOBE says C is second most popular language after Java even with all the security holes. So there's a lot of "we" (though I don't code in C). The TIOBE index has some issues. It is essentially counting hits for a search engine query for a specific language. I would rephrase it as "C has the second most webpages on the internet." On PYPL it is only the 6th popular language, although coupled with C++. Nevertheless there is still demand for C. Otherwise we wouldn't even have this discussion at all. But most people would rather see this demand decrease as we haven't been able to fix the language in the last 30 years.
- bb88 8y ago> The Ariane 5 explosion was not a programming error, it was a testing and specification error. What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw. It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.
- bhaak 8y ago> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw. That's completely wrong. It was an integer overflow. One that could not happen on Ariane 4 but because of different hardware specs. But that was only the end of the chain of fails that lead to the crash. Ada is of course completely able to handle such a problem. But the programmers evaluated this and consciously decided not to handle it for performance reason and because it shouldn't happen anyway. But it could happen, just only on the Ariane 5. Sorry to be blunt but I don't think you know as much as you think you do. You should read up more on the incident. You could even read the post mortem report. It is available on the net.
- Raphael_Amiard 8y ago> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw. That's immensely different actually ... One is undefined behavior, the other is defined but crash. In the first case the problem can stay unnoticed almost forever until somebody exploits it. In the second case, if you actually test and cover your code, you will catch the problem. Short for using a proof technology (which Ada enables and makes easy because of the large palette of constraints you can add on types), there is NO language that can statically guarantee that your program won't crash at runtime. Yes, Ada is not special in that regard. What Ada guarantees is that it will crash, so you can actually catch those kind of bugs in testing. Also nowadays you can use SPARK Ada to formally prove your code correct. https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language) Blaming on the language what is actually bad testing/architecture is pretty unfair. > It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening. Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time. I have never seen anybody saying that it was because Ada was "not safe enough", and even today it stays one of the safest languages out there in many aspects.