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: 3, Interesting) by Ethanol-fueled on Friday May 08 2015, @09:11PM
Ow, my eyes! Ow, my brain! Can't you just give me a garbage-collector instead?!
(Score: 3, Funny) by Anonymous Coward on Friday May 08 2015, @09:19PM
Unpossible - Everyone knows a garbage collected Rust would collect itself!
(Score: 4, Touché) by mtrycz on Friday May 08 2015, @09:52PM
Takehome message: you have to write extra code to call unsafe code.
I like Rust more now.
In capitalist America, ads view YOU!
(Score: 1) by Ethanol-fueled on Friday May 08 2015, @10:56PM
Rust: Write once, write again!
(Score: 4, Informative) by Anonymous Coward on Friday May 08 2015, @11:02PM
That's been my experience with Rust. I wrote some code one weekend, I spent the following work week at work coding in C++, then went back to my hobbyist Rust code on the weekend. Well it turns out that during that single week a bunch of the language's syntax changed, so my code no longer compiled. It required lots of changes before it would compile again. So I spent the weekend doing that, instead of actually using Rust for something productive. Then I had to go back to work for the next work week. When the weekend rolled around again, I went back to my hobbyist Rust code once more. Like before, the language and even the standard library had changed in incompatible ways. So again I had to waste a lot of time fixing my existing code, and not doing something productive. It didn't help that some of my code triggered a crash of the Rust compiler. Why would the Rust compiler crash? I thought that Rust was supposed to help stop crashes! Well whatever. The whole experience really made me think of Rust as a box of lemons. I work with C++ code that was first written in 1989. A lot of it hasn't been changed since the early 1990s, yet it all still compiles and works, even after we started using C++14. Rust has a lot of catching up to do if it ever wants to be as good as C++. I can compile C++ code written almost a quarter of a century ago, but I couldn't reliably compile Rust code written just 5 days earlier!
(Score: 1, Insightful) by Anonymous Coward on Friday May 08 2015, @11:21PM
...perhaps you should have waited until Rust is actually released?
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @03:31AM
When the fuck will that actually be? The Rust devs keep saying "soon" and then "soon" arrives but it's never the right "soon".
(Score: 2) by maxwell demon on Friday May 08 2015, @11:27PM
So it's called "rust" because your code doesn't just bitrot, but actually rusts away if you don't constantly update it? Or is it more because your language knowledge will seem rusty already next week? :-)
Well, maybe it's a security feature: It makes sure that unmaintained code will stop working quickly. ;-)
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by mtrycz on Saturday May 09 2015, @08:38AM
if you're using a language that has not yet been released, couldn't you just have stick with the same version of the compiler for the project?
Just sayin'.
In capitalist America, ads view YOU!
(Score: 1) by iWantToKeepAnon on Monday May 11 2015, @06:58PM
If it isn't stable enough to compile code five days latter, then why the h@!! is there an article called "Death to C"? Don't gripe at the OP for doing something that is totally reasonable for a language being touted as the next "C(++) killer". I've heard that tune too many times and too many times it sounds and falls flat.
"Happy families are all alike; every unhappy family is unhappy in its own way." -- Anna Karenina by Leo Tolstoy
(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
(Score: 3, Insightful) by LoRdTAW on Friday May 08 2015, @09:59PM
This was a carefully thought out feature which permits high performance without a run-time or GC overhead. It also allows for deterministic behaviour which is critical for hard real-time systems. You want GC? Use a language that provides one.
(Score: 4, Interesting) by Anonymous Coward on Friday May 08 2015, @10:31PM
Is there any proof that Rust code actually performs well?
I know that the Rust compiler, which itself consists of a lot of Rust code, is really fucking slow. Although it builds on LLVM, I don't think that LLVM is to blame, because Clang uses it and Clang is still really damn fast when compiling C++ code, and C++ compilers are generally among the slowest compilers out there.
If Rust is so fast, then why is perhaps the biggest project written in Rust so far so goddamn slow?
(Score: 1, Funny) by Anonymous Coward on Saturday May 09 2015, @12:29AM
Is there any proof that Rust code actually performs well?
According to the posts above it rusts very well. I guess no one can be surprised that it lived up to its name.
(Score: 3, Informative) by LoRdTAW on Saturday May 09 2015, @01:10AM
determinism!=fast
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @04:34AM
That's total bullshit. C++ offers determinism, yet it's way fucking faster than Rust is.
Your comparison only holds true for Rust. It does hold true for C++. That means that Rust is flawed.
(Score: 2) by LoRdTAW on Saturday May 09 2015, @05:25PM
What's bullshit? I pointed out that GC isn't determinism friendly. Duh.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @11:13PM
You didn't fucking mention garbage collection at all.
You said determinism is slow, as an excuse for Rust being really fucking slow. But C++ offers determinism, and it's blazing fast.
The problem is that Rust is shit.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @04:40AM
Rust supporters never admit that the problem may just be with Rust. We always hear excuses, denial, and outright falsehoods from them.
Determinism is very fast in languages like C++ and Ada. It's only slow in Rust, because Rust is shit!
(Score: 2) by LoRdTAW on Saturday May 09 2015, @01:36AM
Also, Rust is still a work in progress. The latest version is still in beta.
(Score: 1, Interesting) by Anonymous Coward on Friday May 08 2015, @10:27PM
As shitty as Rust code is, when the fuck will Rust 1.0 finally be out? It was promised to us like 6 months ago, and I'm pretty sure it was supposed to have been out even before then.
Why can't the Rusters get their shit together? Why the fuck can't they get Rust 1.0 out the door?
They're starting to make Perl 6 look like less of a tragedy.
(Score: 2, Insightful) by Anonymous Coward on Friday May 08 2015, @10:49PM
The article quotes somebody named Steve Klabnik. Apparently he's a member of the Rust core team? But why the fuck should I care what he has to say? What has he done that would make me take him seriously?
(Score: 4, Insightful) by CirclesInSand on Saturday May 09 2015, @11:09AM
Here’s a C program which will simply double all the input it’s given:
int double_input(int input) {
return input * 2;
}
No it isn't. That's the problem with C and almost every other language. It is a function that returns twice of any integer that is between some minimum and some maximum, and it won't give you an error if you screw it up and give bad inputs. That causes things to crash.
Any language that confuses the concept of "integer" and "word" is on my bad side. Any language that confuses "float" and "real" is on my bad side. Any language the confuses "array" and "vector" is on my bad side. Any language that confuses "byte" , "bytes", and "character/glyph" is on my bad side. Any language that confuses "procedure" and "function" is on my bad side. Any language that confuses "assignment" and "definition" is on my bad side. I could go on for days.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @12:30PM
So anyone that uses terminology in a way that you don't like, even if it is perfectly valid for that language, is on your bad side?
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @01:26PM
This has nothing to do with personal preference. It's not about "likes".
When it comes to technical matters, including programming languages and related concepts, words have very, very specific meanings. Misuse of such terminology will cause technical problems.
If you misuse the terminology, confusion will arise. Confusion in programming language design leads to language flaws and bugs.
Rust uses established, well-defined terminology incorrectly. That's one of the reasons why people don't like Rust. "fn" should be "function". "mod" should be "module". When they use gibberish abbreviations, people will get the wrong impression. "mod", for example, is ambiguous with the "modulus" operation.
(Score: 2) by Common Joe on Tuesday May 12 2015, @02:29AM
You just hit upon something near and dear to me. I find no difference between real world procedures, functions, methods, and subroutines. Granted, I don't really use functional languages (which is a different beast), but the procedural and OOP languages make these all the same. It is the implementation by the programmer which makes them different. And although nice in theory, I have found it impractical to draw a hard line between functions (return single value, no side effects) and procedures (no return value, side effects). I find the TryParse [microsoft.com] in C# to be a good example.
As for functional languages, I find them lacking, overly wordy, and a bit unwieldy for projects that don't deal with finances. Side effects can be a good thing.
What languages aren't on your bad side?
(Score: 2) by CirclesInSand on Tuesday May 12 2015, @08:35AM
You just hit upon something near and dear to me. I find no difference between real world procedures, functions, methods, and subroutines.
Well we're in good company then, if we both appreciate these things. A few things:
A function need not be computable. If you are reasoning about programs, then distinguishing between computable and general functions is essential.
Functions (both kinds) are easier to reason about than procedures in most cases.
Procedures don't necessarily have side effects. That is more of a global/local declaration issue.
Conceptually they are very different as well. Procedures are for doing things. Functions are for saying things.
What languages aren't on your bad side?
I may mess around a bit, but I'm still holding out for true love.
(Score: 1) by EETech1 on Tuesday May 12 2015, @01:40AM
I woulda thought for sure you bit-shifted your ints...
Just when you think you got somebody figured out!