SoylentNews is people
SoylentNews
Ladies and gentlemen, the C programming language. It’s a classic. It is blindingly, quicksilver fast, because it’s about as close to the bone of the machine as you can get. It is time-tested and ubiquitous. And it is terrifyingly dangerous.
The author's biggest issue with the C language seems to be security holes:
If you write code in C, you have to be careful not to introduce subtle bugs that can turn into massive security holes — and as anyone who ever wrote software knows, you cannot be perfectly careful all of the time.
The author claims that the Rust language is a modern answer to these issues and should replace C (and C++). It does look that Rust can run C code, so it looks like an interesting proposition. What do Soylent's coders think about this?
(Score: 0) by Anonymous Coward on Friday May 08 2015, @10:57PM
That's not a good thing. It means that while calling "unsafe" (that's a misnomer; the code could very well be perfectly safe, especially if it wasn't written by a Rust programmer) code there is much more that could go wrong.
Complexity is what causes bugs. Simplicity is what helps eliminate them.
Adding complexity to try to prevent bugs will never work. It will just cause more bugs, and they will be harder to detect and properly fix.
(Score: 2) by Immerman on Saturday May 09 2015, @01:39PM
is there added complexity though, or just added tedium? Adding tedium to generally unsafe practices would tend to promote using other practices instead.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @02:01PM
Tedium is a form of unnecessary, wasteful complexity.
(Score: 2) by Immerman on Saturday May 09 2015, @04:42PM
No, it really isn't.
For a simplistic example, naming a function FastButUnsafeConversionFromStringToInteger() is going to nudge people toward using its slower, safer cousin StringToInt(). But there is absolutely no difference in the complexity of using either, only in the tedium of typing and reading the function name.
The various _cast functions in C++ could have done something similar, except that the more concise C-style casts were still supported - I don't think I ever even found a compiler that let you warn against them. Which created the situation where the language constantly nudged people into using the more dangerous (and less locatable) legacy casts