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!
(Score: 5, Troll) by Anonymous Coward on Friday May 08 2015, @09:13PM
Use the flavor-of-the-month language, because you're hip and with-it, coder bro! Can you fucking assholes be even more obvious with your shitty hipster evangelism? Not obvious enough! More. Obvious.
(Score: 4, Interesting) by Anonymous Coward on Friday May 08 2015, @10:25PM
Rust is the kind of disaster that's only possible when you get a bunch of Ruby hipsters together, give them funding from Mozilla, and have them try to improve on C++. Nobody else could manage to create something as bad as Rust. That's probably why Rust is seen as "cutting edge". It's on the cutting edge of fucking stuff up so badly.
(Score: 4, Interesting) by FatPhil on Saturday May 09 2015, @08:11AM
I guess if TSA is security theatre, then Rust is secure-code theatre.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @11:00PM
Oh please. Do you not wear seatbelts because it is still possible to die in a car accident even while wearing a seatbelt?
Any language that allows direct memory access in any fashion has that 'problem.'
But the idea is that the normal path is safe unlike C.
You got that black and white geek thinking problem - the fact that it is possible to do something dangerous is not the same as it being easy to do something dangerous.
(Score: 2, Interesting) by Anonymous Coward on Friday May 08 2015, @10:37PM
The parent comment isn't a troll. Somebody should fix that shitting modding.
Anyone who has followed the Rust community knows it's fucking rife with hipsters. Anyone who has worked with software developed by hipsters will know how fucking shitty their creations are.
Hipsters can't create good software. Their whole way of life revolves around rejecting the years of experience required to create good software.
Hipsters are generally teenagers and 20-somethings who are totally clueless about doing things properly.
I don't even give a fuck if they're on my yard. I'd rather them be on my yard, sticking ironic beer up one another's anuses, than writing software.
(Score: 3, Funny) by kaszz on Saturday May 09 2015, @12:26AM
Any tip on other computer languages that are rife with hipster idiocy?
(Score: 1, Informative) by Anonymous Coward on Saturday May 09 2015, @04:38AM
Ruby, obviously.
JavaScript is the other big one.
Go is another one.
Haskell is up there, too.
(Score: 2, Insightful) by Anonymous Coward on Friday May 08 2015, @10:54PM
Can somebody explain how the parent and the sibling comments are "Troll" comments? I don't think they are, based on my many years of using Ruby on Rails (not totally by choice; I prefer PHP). I've worked with a lot of people who are either self-described hipsters, or clearly fall within that community, and what those other comments say describe these people perfectly. They do care more about doing what's cool than about doing things right. They will jump ship really often, too. That's the very reason I'm stuck maintaining so much Ruby on Rails code! They'll write the code, and it won't be good at all. Then they'll run off to the next big thing, like Rust, while the rest of us non-hipsters are stuck fixing the awful disasters they created. We're the ones turning their Ruby on Rails apps into something that's kind of usable, at least until management gives us enough funding to throw their shit away, and to rebuild the system from scratch using PHP and Java. Mod the parent and sibling comments up. They're completely correct, and they clearly aren't trolling.
(Score: 4, Insightful) by Tork on Friday May 08 2015, @11:22PM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @12:02AM
You can't dismiss someone's argument by bringing up their desire to retain at least some semblance of anonymity.
(Score: 4, Insightful) by Tork on Saturday May 09 2015, @12:25AM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 3, Disagree) by Anal Pumpernickel on Saturday May 09 2015, @03:18AM
Their credibility is hurt because they broke some arbitrary 'rule' you try to impose on others? What does that even mean, and why does it matter? Their entire comment is right there; respond to the points you think are dubious or don't. "credibility" doesn't even factor into it for some random comment on Soylentnews, and their credibility isn't hurt merely because they posted as AC or used the word "hipster."
If you've got some problem with their comment, then put forth your logical arguments.
(Score: 0, Disagree) by Anonymous Coward on Saturday May 09 2015, @04:32AM
Nobody really listens to Turk, and nobody cares what Turk says. He's pretty much just ignored around here.
(Score: 2) by Tork on Saturday May 09 2015, @05:17AM
What does that even mean, and why does it matter?
That question was answered later in my post.
If you've got some problem with their comment, then put forth your logical arguments.
I did.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by kaszz on Saturday May 09 2015, @12:22AM
Does it pay to do things the right way? or is it more profitable to jump quick on languages and job?
(Score: 2) by The Mighty Buzzard on Saturday May 09 2015, @11:58AM
Oooh, a 5, Troll score. I am envious.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @12:04PM
It just goes to show that the Troll modifier should be removed, since it's never used correctly here. That comment isn't even an attempt to troll, obviously. It's just some very insightful insight. It should be 5, Insightful.
(Score: 2) by The Mighty Buzzard on Sunday May 10 2015, @08:31PM
Wouldn't matter. Some people are just douchebags and will use any means at their disposal to downmod you simply because they don't like what you have to say. We'd have to remove all downmods to remove that possibility and that's throwing the baby out with the bathwater*.
* Which is an expression I don't really get since babies are nothing but loud, smelly, annoying crap machines.
My rights don't end where your fear begins.
(Score: 3, Insightful) by bob_super on Friday May 08 2015, @09:15PM
The overwhelming majority of C programmers will tell you they write safer code than average. They don't need no stinking protective overhead...
(Score: 3, Informative) by pe1rxq on Friday May 08 2015, @09:35PM
I would state it even more generic: The overwhelming majority of programmers will think they write safer code than average. They will manage to write crappy code in any language.
(Score: 3, Informative) by maxwell demon on Friday May 08 2015, @11:29PM
It is even more generic: The overwhelming majority of people will think they are above average in mastering most of their activities.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Funny) by naubol on Saturday May 09 2015, @03:55AM
The overwhelming majority of people think they're above average.
(Score: 4, Funny) by dyingtolive on Saturday May 09 2015, @06:02AM
The overwhelming majority.
Don't blame me, I voted for moose wang!
(Score: 3, Insightful) by Nerdfest on Saturday May 09 2015, @12:28AM
True, but some languages *encourage* the writing of code that is insecure and hard to maintain. I've never considered C one of those languages though. Visual Basic, JavaScript, and a few others, yes, but not C. I've certainly seen my share of bad C and wouldn't choose it over some other languages for writing the most maintainable code, but I don't think it encourages the bad habits I see in other languages.
(Score: 1, Interesting) by Anonymous Coward on Friday May 08 2015, @09:54PM
If you want to do a buffer overflow on my last C application, you'll have to enter it using a 4 button keypad and a menu on a 1602 LCD, or pry off the "warranty void if removed" sticker and JTAG it, and then its not my problem. Does rust even run on an AVR?
(Score: 3, Informative) by tftp on Saturday May 09 2015, @06:35AM
If you want to do a buffer overflow on my last C application, you'll have to enter it using a 4 button keypad and a menu on a 1602 LCD
Sometimes it is enough to keep one button in the pressed state for an hour or two. Chewing gum will do it for you. Correct coding of the interrupt handler and the input queue takes time; time is always in short supply. Are you sure that the queue implementation in your RTOS, or in whatever code that runs in your main loop, is safe and that you are using it safely? Can you prove it?
I did my share of C coding for AVR, and I had to reinvent all this code more than once. Sometimes I reused my old code. I cannot prove that all of it is safe. I follow best practices, though, and the code is functional. But can it be hacked via an intentional, never occuring in tests, buffer overflow? I cannot say. I just don't have manpower to check for all those "can't happen" situations. I can only say that the code was tested on datastreams that it was supposed to handle.
(Score: 2) by VortexCortex on Saturday May 09 2015, @08:32AM
I can only say that the code was tested on datastreams that it was supposed to handle.
My meta language can output in C and generates unit test stubs with input fuzzing for numerics and strings based on parameter type or explicit doc comment ///@range[a..b,c,d..e] or ///@random[...]
There really is no excuse for not testing your code properly if it has anything to do with security.
(Score: 2, Informative) by tftp on Saturday May 09 2015, @06:11PM
My meta language can output in C and generates unit test stubs with input fuzzing for numerics and strings based on parameter type or explicit doc comment ///@range[a..b,c,d..e] or ///@random[...]
This works great if this is a high level software. However in the examples that the AC and I used you need to generate those test vectors not only across the input space, but also across time. Most embedded systems have global variables. Usually they are protected with some sort of a mutex. Typically they are declared 'volatile.' This works fine in userspace. But it becomes funnier when you enter the land of interrupt handlers. Often you cannot wait on a mutex in an interrupt handler because then the code deadlocks. You sometimes use the {enable,disable}_interrupt() macro to ensure that the usercode touches the protected variables only when interrupt handlers can't... but this is an equivalent of Linux's BKL, and it is bad. What to do if you cannot use this crude "mutex"- say, if you have interrupts that must not be disabled, even for this little, or if you have several levels of interrupts and they can interrupt each other? Then it calls for a more complex interrupt handling, when interrupts of different levels can interrupt lower ones - and this allows to wait in interrupt handlers, as the timer runs on NMI or an equivalent.
As an example, I have the Schwinn 470 Elliptical Machine. (A very useful thing for a programmer, by the way.) It has at least one bug. If you press the "PAUSE/END" button when it beeps, the incline level drops. I suspect that interrupts from the timer and from the GPIO are not on friendly terms with each other.
This is not the only catch that you can find in embedded systems. There are other - like hardware that sends you values that are documented as "cannot happen, ever." Are you sure that you wasted precious bytes and microseconds in an interrupt handler, with interrupts disabled, to check for six impossible things? Yes, it is a prudent thing to do. But how many people have done it, after they received assurances from their hardware developers that this here CPLD of FPGA simply cannot output a byte with values outside of the 0x00 to 0x0F ? Are you using this value as an index into a 16-element array, by any chance?
But of course an embedded programmer with 20 years of experience will spend a single AND machine instruction and make this value safe. Will a junior programmer with three weeks of experience do the same? Will his code be reviewed? Will the bug be found? It's pretty hard to look for bugs in code that is written in languages that have no explicit contract. That byte that we think is in the [0..0x0F] range may be latched in one place, transferred between different pieces of code and different globals, and may end up somewhere where you wouldn't be even checking. You'd have to verify that someone, somewhere ensures that the value is in range. A reviewer sees one module at a time. With tens of such variables, range enforced in various places (or nowhere,) only the code's developer can be reasonably aware of what exactly is happening. Not even him in case of a large codebase, or after a few months of working on another project. Design by contract is possible in C, but only by hand - poorly. Enums can have any int value. Packed structures may have different memory layout on different CPUs, or with different compiler options. Endianness is also somewhere there, lurking in the shadows and waiting to bite you when you are not vigilant. Incompatible types may be freely passed between modules, gaining or losing sign or bits. As memory in MCUs is not exactly infinite, you tend to use uint8 and uint16... but are they sufficient for the task at hand? Why do you think so? Say, the ticks counter will wrap after 240 days of continuous operation. Is this OK or not? What design requirement have you based your opinion on? Does the customer agree? If it is not OK, what have you done to ensure that the overflow is handled properly? Is there is a code somewhere, written by someone else, that checks for a too long execution time and throws an assert() if, when treated as uint32, it exceeds 0x00000FFF? Do you know that this particular runtime implements assertion failure as "while(1) {}" ? It's not an excuse that you never use asserts. A closed source library that your boss purchased may do so.
As most, if not all of these checks can be done by compiler and by the runtime, it is usually beneficial to spend a bit of excess CPU performance on checking all these things and doing the most reasonable thing if the conditions are not satisfied. Doing it all by hand is possible, especially in C (where everything is possible,) but it increases code size, increases probability of a bug, and increases the cost - while doing nothing at all in normal use. What software manager will approve this work if the VP is breathing down his neck?
(Score: 2) by q.kontinuum on Saturday May 09 2015, @09:40AM
<nitpick>Neither RUST not C nor C++ runs on AVR, that's why we need a compiler</nitpick> However, there is a fork [github.com] of the rust project which will compile for AVR. This was the first thing I checked after reading the article. C is widely used to program operating systems and embedded systems, because most other languages (interpreter languages) need a runtime-environment and an underlying OS.
I am interested in learning more about RUST. Having a new language for low-level programming, entirely designed with security in mind, would be awesome. However, the other comments to this article mentioning the current instability of the language definition (the same code compiles one week and is broken the next week due to compiler changes), dampened my enthusiasm a bit for now.
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 2, Informative) by mvdwege on Saturday May 09 2015, @07:31PM
What's wrong with Ada, aside from not being the 'Next Big Thing' praised by all the hipsters?
(Score: 2) by q.kontinuum on Saturday May 09 2015, @08:16PM
I never heard much about ADA, but after seeing your post I started reading about it. Thanks, I guess I will use it for my next AVR project :-)
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 1) by mvdwege on Saturday May 09 2015, @08:51PM
I dabble a bit in it; I'm a sysadmin by trade, programming professionally for me is mostly scripting languages.
When I do have a hobby project that needs C levels of speed, I go for Ada though (note, it's not an acronym, it's named for Lady Ada Lovelace). It's a nice language, a tad verbose, using words instead of sigils for block delimiters, and it's very much tied up in its philosophy of 'everything is a type with defined behaviours', which accounts for its 'bondage-and-discipline' reputation.
That aside, it's very elegant and fairly intuitive once you grasp the type system, and it has a really helpful community centering mostly around the USENET group comp.lang.ada. Where, surprisingly, even a hobbyist dabbler like me gets detailed and friendly answers from guys working on massive industrial projects, with zero condescension.
The AVR runtime is especially good; I have a project on the backburner to hook up some motion sensors to an AVR board and build my own burglary alarm system.
(Score: 4, Interesting) by kaszz on Saturday May 09 2015, @12:16AM
The majority of programmers perhaps just lack the talent [soylentnews.org] and won't realize it, nor will their management. Because coincidentally they might also be cheap and say yes. Doing the homework [soylentnews.org] perhaps isn't done either. So this is first a cognitive bias failure and secondly perhaps a lack of realization that most people doesn't have what it takes to be a sharp programmer. So to run a code factory with code monkeys the languages are under pressure to adapt to the lowest common denominator.
(Score: 2) by richtopia on Friday May 08 2015, @09:18PM
I'm not familiar with the speed of Rust, but when dealing with embedded systems, the speed of C is needed and thanks to its vast deployment has become a bit of a defacto standard.
(Score: 0) by Anonymous Coward on Friday May 08 2015, @09:30PM
but when dealing with embedded systems, the speed of C is needed
Ding, Ding, Ding. The proliferation of embedded systems ... including all the itsy-bitsy processors that will be swarming to become the Stupidnet of Everything ... require fast, small, reliable code. And where can we get this fast, small, reliable code? Hmmm ... let's C ...
(Score: 1, Interesting) by Anonymous Coward on Friday May 08 2015, @09:38PM
C will help you get fast and small, but it also makes reliable harder.
Besides, nowadays "itsy-bitsy" systems are are 1GHz with 512MB of ram. [soylentnews.org]
(Score: 2, Insightful) by Anonymous Coward on Friday May 08 2015, @11:09PM
If you can't write reliable C code, then Rust isn't going to help you. If you can't figure out C, then you won't be able to figure out Rust. You'll just end up writing a lot of Rust code that works around the protections (limitations, really) that Rust tries to provide. You'll end up using Rust's unsafe keyword a lot. Your Rust code will be more dangerous than C code, because you and others will mistakenly think it's "safer" than C code when it really isn't. In fact, this poorly written Rust code could even be unsafer than poorly written C code.
(Score: 1, Insightful) by Anonymous Coward on Saturday May 09 2015, @12:03AM
> If you can't write reliable C code, then Rust isn't going to help you.
If you aren't perfect no tool will make you perfect.
But none of us are perfect. Not even you.
Good tools can make us better. Even you.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @03:34AM
C is a good tool. Rust is not a good tool.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @04:31AM
5 year from now, "itsy-bitsy" systems may be 3GHz hex core with 16 GB of RAM.
Which language do you recommend we use to program them? Will you suggest the "hip" language of the week?
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @04:07PM
That's a nice $9 system you have there. Unfortunately, for what I'm working on, the processor cannot cost more than $0.40 (preferably half that), or the product will not be economically viable. Also, it has to run on a coin cell battery for at least a month.
(Score: 3, Interesting) by MichaelDavidCrawford on Saturday May 09 2015, @12:05AM
or rather, if you aren't regarded as a particularly good programmer, you won't be offered an embedded job.
The problem we have is that many people still learn C as a first programming language, by following K&R's advice about the C standard library with scanf and strcpy.
Yes I Have No Bananas. [gofundme.com]
(Score: 2, Troll) by Anonymous Coward on Friday May 08 2015, @09:25PM
News at 11.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @02:27AM
Yes, and they will promote another hipster language next week/month.
Whats with the modding trolls? More reason to browse at -1.
(Score: 2, Informative) by Anonymous Coward on Friday May 08 2015, @09:27PM
You want to rewrite Linux in Rust? Do you? Huh?
Just compile your shitty code with AddressSanitizer and shut the fuck up already.
(Score: 5, Insightful) by maxwell demon on Friday May 08 2015, @09:32PM
This is from the language home page: [rust-lang.org]
Well, note the star here? Well, let's look at the fine print:
I've got a hint for them: First make your language do what you claim, and then claim that it does it.
BTW, already without the star the text makes me completely mistrust the language. When something is advertised as silver bullet, it most probably isn't.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2, Funny) by Anonymous Coward on Friday May 08 2015, @10:42PM
If Rust is supposed to make it harder to write buggy software, then why the fuck do Rust and Servo, the two largest Rust projects, suffer from so many goddamn bugs?
Rust: 1,925 Open 11,500 Closed [github.com]
Servo: 829 Open 1513 Closed [github.com]
Yeah, Rust is totally preventing bugs.
(Score: 2) by maxwell demon on Sunday May 10 2015, @12:58PM
Well, they obviously were working really hard on those projects. :-)
The Tao of math: The numbers you can count are not the real numbers.
(Score: 4, Insightful) by tangomargarine on Friday May 08 2015, @10:55PM
So it's really fast, and totally safe*?
*actually isn't
Hmm, sounds like C, only minus the 40ish years C has been out so everybody could hammer on it and learn it well.
#newisalwaysbettergeez
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 5, Funny) by snick on Friday May 08 2015, @09:33PM
Everyone should stop using C/C++ and start using a language in beta ... for Security reasons!!!
Kids are *sooooo* cute.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @01:50AM
C'mon, it's not just the kids/hipsters who are to blame for this. What is the prize for the first person to spot a job advertisement specifying "must have 5+ years programming in Rust". I would like to know now because I'm sure these will become ubiquitous within the next few months.
(Score: 4, Insightful) by Gravis on Friday May 08 2015, @09:36PM
no matter what language you use, if you...
then you are going to write shitty code.
(Score: 2, Insightful) by dmbasso on Friday May 08 2015, @09:52PM
To that I add:
then you are going to write minefield code.
But hey, fuck whoever has to maintain it later, not your problem.
`echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
(Score: 3, Insightful) by bug1 on Saturday May 09 2015, @12:11AM
(Score: 2) by krishnoid on Friday May 08 2015, @09:49PM
The string implementation is taken for granted in the language, but it seems like it may not have been a great choice [joelonsoftware.com].
(Score: 5, Insightful) by darkfeline on Friday May 08 2015, @10:11PM
I think Joel is wrong. C is a great hammer when you need to hammer in nails. Do not blame the hammer for working poorly on screws.
There's basically two ways to store string on the machine level: magic character terminated (null-terminated C strings) or you store the length of the string somewhere. There are multiple problems with the second approach. First, you waste a lot of space allocating memory for a large integer if all of your strings are short in length (and remember that back when C was invented, this kind of thing mattered as memory was expensive and limited). Second, there's a maximum limit on the length of your strings, or else you overflow your length integer and potentially run into bugs and security vulnerabilities (in the interest of fairness, this kind of overflow is less dangerous than a buffer overflow). Third, there isn't any advantage over using the null-terminated approach and just storing the length of the string in a integer variable yourself, which is in fact what many C programs do (but not all! C doesn't force you to store the length if you do not need it).
It's been said that C is portable assembly, which is very true. Just like with assembly, you sacrifice convenience for power when you drop down to C. If your problem can be solved better in a different language, don't blame C for your own mistake of choosing the wrong language.
Join the SDF Public Access UNIX System today!
(Score: 4, Insightful) by krishnoid on Saturday May 09 2015, @12:41AM
There's basically two ways to store string on the machine level: magic character terminated (null-terminated C strings) or you store the length of the string somewhere.
There are multiple problems with the second approach. First, you waste a lot of space allocating memory for a large integer if all of your strings are short in length (and remember that back when C was invented, this kind of thing mattered as memory was expensive and limited).
Sure -- is this as much of an issue nowadays? I can see this would add, say, 3 bytes (minus one NULL + 4 bytes) to every string, or possibly less, if memory accesses are 4-byte-aligned anyway and the strings aren't packed together tightly.
Second, there's a maximum limit on the length of your strings, or else you overflow your length integer and potentially run into bugs and security vulnerabilities (in the interest of fairness, this kind of overflow is less dangerous than a buffer overflow).
That would be 4GB for a 4-byte unsigned int, which is long for a string. Point taken in your fairness in comparing the overflow severity and that overwrites can still happen.
Third, there isn't any advantage over using the null-terminated approach and just storing the length of the string in a integer variable yourself, which is in fact what many C programs do (but not all! C doesn't force you to store the length if you do not need it).
If you're doing that for all your strings, shouldn't a language (or standard library) supporting that behind the scenes be better and faster, turning at least some O(n) operations into O(1) for non-multiplicative increase in memory use? For your second point, what programs manipulate and copy strings without referring to their length frequently? I could make the argument that for the majority of application modalities in use nowadays, a string is closer to a (not CPU-wise) 'native type' and should have a strlen()-like operation be O(1).
(Score: 2) by darkfeline on Monday May 11 2015, @12:22AM
>Sure -- is this as much of an issue nowadays? I can see this would add, say, 3 bytes (minus one NULL + 4 bytes) to every string, or possibly less, if memory accesses are 4-byte-aligned anyway and the strings aren't packed together tightly.
No, but backward compatibility IS an issue. C is what it is because back then memory was an issue.
>That would be 4GB for a 4-byte unsigned int, which is long for a string. Point taken in your fairness in comparing the overflow severity and that overwrites can still happen.
Again, memory used to be an issue. If you need good string support there are many alternatives: C++, Golang, Common Lisp, Java for example.
>If you're doing that for all your strings, shouldn't a language (or standard library) supporting that behind the scenes be better and faster, turning at least some O(n) operations into O(1) for non-multiplicative increase in memory use? For your second point, what programs manipulate and copy strings without referring to their length frequently? I could make the argument that for the majority of application modalities in use nowadays, a string is closer to a (not CPU-wise) 'native type' and should have a strlen()-like operation be O(1).
But you don't necessarily need that for all of your strings, do you? If I know that the strings/blobs I am working on will be less than a given size and I am running an algorithm that linearly passes over the string, I can just allocate the memory in one go and not have to worry about the length ever.
C was designed with the UNIX philosophy in full force: do not dictate policy! If the end user (the developer) does not want or need strings with length, do not force it on them. Note that C can perfectly well use length-strings instead of null-strings, in that case they are just length-defined binary buffers. (Chars are just bytes, strings are just char arrays with a NUL at the end.) The UNIX Dev Team Thinks Of Everything.
Join the SDF Public Access UNIX System today!
(Score: 1, Informative) by Anonymous Coward on Friday May 08 2015, @10:12PM
Expecting things to happen by magic is not a great choice in *any* language. As this example, one out of thousands, does amply demonstrate: http://raid6.com.au/~onlyjob/posts/arena/ [raid6.com.au]
If a craftsman does not know his tools, it is not the tools that are to blame.
(Score: 0) by Anonymous Coward on Friday May 08 2015, @10:44PM
Why the fuck should I care about what Joel thinks?
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @02:40AM
Because he is Jewish?
oops...
(Score: 5, Insightful) by Anonymous Coward on Friday May 08 2015, @10:56PM
Your string can't have any zeros in it. So you can't store an arbitrary binary blob like a JPEG picture in a C string.
Stopped reading there. Clearly the writer of this article is incompetent in regards to C. You can store arbitrary 0x00 anywhere in a char[] just fine, you just can't use the built-in string manipulation functions on it, which you shouldn't if you aren't storing 0-terminated strings in the first place.
Fundamental types in C represent fundamental types in your CPU. A char is defined as a byte. A char* is a memory address whose value can be represented as a byte. That's all it means. The standard library provides the means to handle char* as a 0-terminated string, but you are not required to, and in fact, it's very common not to.
If you need to, you can create a compound string type which is length-preserving. This is what structs are for.
(Score: 2) by tangomargarine on Saturday May 09 2015, @07:31PM
Aren't zero-terminated and null-terminated usually two different things? In ASCII the number zero is stored as 32+whatever.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by tangomargarine on Saturday May 09 2015, @07:38PM
Blargh. s/number zero/character zero/g
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Friday May 08 2015, @09:52PM
Guess we should push it aside and all use Rust then.
BTW when will Rust actually work?
(Score: 0) by Anonymous Coward on Friday May 08 2015, @10:17PM
Carmack is still alive? What has he done lately?
(Score: 1, Informative) by Anonymous Coward on Saturday May 09 2015, @01:00AM
He works for Facebook. [techcrunch.com]
(Score: 1, Interesting) by Anonymous Coward on Friday May 08 2015, @10:00PM
I think this sounds like a puff piece written by a used car salesman desperately trying to move a lemon off the lot. Seriously, does the author of this article have some sort of financial stake in this?
(Score: 2, Insightful) by Anonymous Coward on Friday May 08 2015, @10:11PM
We called it Java.
Oh wait python.
Oh wait C#
Oh wait PHP
Oh wait javascript
Oh wait and on and on.
They are *all* riddled with security holes. What makes Rust special?
(Score: 0) by Anonymous Coward on Friday May 08 2015, @10:18PM
Isn't it funny that almost all the wonderful examples on DailyWTF are of languages like the ones in your list, yet you barely find any examples of C (or even C++) code there. I wonder why...
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @12:57AM
I don't know why, either, but I do know that the user makes a language secure, not the language itself. Stop suggesting otherwise.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @09:32AM
A language poses an entry barrier, a baby-language that runs no matter what kind of garbage you write and soft-fails will promote bad coding (see JavaScript).
(Score: 1) by dingus on Saturday May 09 2015, @06:15PM
because C/C++ has decades of thought put into it. I bet if you used the original C compiler it would behave oddly as well.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @12:32AM
It is less the language and more the use. When made with security in mind, just about any language will do. When security is an afterthought, every language will fail.
(Score: 1, Troll) by Subsentient on Friday May 08 2015, @10:31PM
I like C. It's a small language I can always remember pretty much all of, that runs everywhere, requires very little to get going on pretty much any chip ever, and powers most of the shit we use today.
The world isn't a smouldering crater, and C's been around for a very long time. Yes, pointer and overflow bugs are very common and do introduce a lot of security holes, but I don't see anything out there today qualified to replace C. Especially not rust.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 5, Funny) by Marneus68 on Friday May 08 2015, @10:48PM
>in C, you have to be careful
It's almost like you have to pay attention to what you're doing unlike in javascript. Crazy I know.
(Score: 2) by Marand on Friday May 08 2015, @11:35PM
>in C, you have to be careful
It's almost like you have to pay attention to what you're doing unlike in javascript. Crazy I know.
Nonsense! You have to pay attention in Javascript too or you'll hit a random gotcha and realise you've wandered into wat [destroyallsoftware.com]* territory. Not Javascript, but my favourite example is this glorious master-post of PHP insanity [eev.ee]. With PHP, "wat territory" is everything between "<?php" and "?>"
(Not trying to add to the language bashing, just a silly comment with a couple related "fun" links.)
* JS portion of video starts at 1:20.
(Score: 1, Funny) by Anonymous Coward on Friday May 08 2015, @11:43PM
Death to SJWs, feminists, etc.
Marry girl children.
C is good.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @09:55PM
Marry girl children.
Makes sense I guess, after all C is the catholicism of programming languages.
(Score: 5, Funny) by Marand on Saturday May 09 2015, @12:23AM
Article should have been from the "off-with-its-header" dept. instead.
(Score: 2) by kaszz on Saturday May 09 2015, @12:32AM
I got news! If you don't pay attention then things tend to screw up. People in this area is supposed to handle maths without a digital nanny. But can't handle to write programs without it? Faulty programmer I'd say. You can write perfectly alright C software if you pay attention and THINK ahead. Keep internal structuring clean and well thought out. Think what's going to happen if you do something. Avoid complexity unless necessarily.
If happen to need to write a quick startup code in userland. Then perhaps a scripting language is the better choice. So choosing the right tool is also part of the job.
(Score: 2) by el_oscuro on Saturday May 09 2015, @02:57AM
I know it is a C++ class, and technically not part of native C. Almost all compilers I have used in the last 25 years support C++ classes, so why not use them. Almost all C vulnerabilities I have seen involve buffer overflows, almost always from faulty memory management of strings. Using the string class avoids that entirely, making it much safer. For example:
Notice that there is no memory management code at all in this example? Since the string class allocates buffers automatically, there is nothing to buffer overflow. It hash functions to convert to native C strings (also managing buffers) so you can use it in existing C code. Besides being much safer, it is also one of the most powerful string libraries in any language.
SoylentNews is Bacon! [nueskes.com]
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @03:36AM
But C++ isn't hip and cool. C++ isn't trending. Rust is all of those things.
(Score: 2) by maxwell demon on Saturday May 09 2015, @05:27PM
So effectively you agree that C should die, you just want it to be replaced by C++, not Rust?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1, Disagree) by dingus on Saturday May 09 2015, @06:12PM
C++ is the logical heir of C.
(Score: 2) by CirclesInSand on Monday May 11 2015, @01:11AM
Sure, until someone comes along and writes
string whatever = "x" + "y";
And before you say that's user error, I'll cut you off and say: there is no such thing as user error. That is just an excuse that bad designers use.
(Score: 2) by naubol on Saturday May 09 2015, @03:49AM
It could be argued that the most important piece of software in the world is written in C and that wrapping it in Rust would enhance the potential for problems, not decrease them. When considerations like optimizing call stacks come into play and the million platform issues in compiled code which have to be dealt with by hand in order to avoid massive performance penalties in the kernel... Rust isn't going to cut the mustard.
C is ugly and C could have done better, but we need a to the metal language with C's flexibility and the advantages to replacing C in some of the world's most important software would have to be monumental to overcome the disadvantages.
(Score: 3, Insightful) by jmorris on Saturday May 09 2015, @06:48AM
So some random butthole is ranting that the world should drop C and adopt Rust. A language that is in beta, large portions of the documentation are blank pages awaiting content, many of the non-blank pages need help, there are zero books available to help fill in the gaps. O'Reilly shows that they will have one out near the end of the year though... but that is the only hit searching Amazon.
Why is this a topic for serious discussion instead of some fun snarking? I just hope the butthole isn't working anywhere that does stuff that really matters.
And after reading a fair amount of the available docs... nope, don't like the idea much. But even if I did like it, far too new to use for anything serious yet. Give it five years, then lets see if there is any uptake, any good books and 3rd party libraries and other tools. At that point serious people might consider using it for a few of serious jobs C currently excels at. And in twenty years it might even be a pimple on C's ass in terms of installed base. The world is still using Fortran and Cobol, C ain't going anywhere in our lifetime.
(Score: 2) by PizzaRollPlinkett on Saturday May 09 2015, @10:17AM
Article rants about C as clickbait, then just fizzles out - mentioning some niche language the author just discovered which is the greatest thing ever. Why Rust? Why not D, or some other niche language? No substance to the article.
(E-mail me if you want a pizza roll!)
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @05:08PM
Real men don't eat quiche, and
Real programming languages aren't niche
(Score: 2) by maxwell demon on Saturday May 09 2015, @05:33PM
I agree, we should go back to FORTRAN. Not this newfangled Fortran with modules, pointers and even OOP features. No, good old ignore-everything-too-far-to-the-right FORTRAN.
Long live the alternate entry point!
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @05:50PM
The FORTRAN I remember (loooong ago) was terrible with character strings, and it didn't even have block structure. Other than that, I didn't mind it; good for numerical stuff.
(Score: 0) by Anonymous Coward on Saturday May 09 2015, @07:44PM
I've been reading about D for a decade, and love the ideas of its feature set. It seems truly to be what C++ should have been.
I just regret not having the time to investing in writing something non-trivial with it, to try it out.
(Score: 1) by dingus on Saturday May 09 2015, @06:09PM
Seriously, its syntax is terrible and its advantages are slim. You can get the same safety by just running your code through a static analyzer.
Anyway, it's not hard to write safe C++. I'm sure there are a billion libraries that solve everything Rust does but with little mangling of syntax.
(Score: 2) by hendrikboom on Saturday May 09 2015, @11:52PM
What do I think? Why, C and C++ are obsolete languages, and, as expected, we're still running and writing software in the because of decades of tradition and ocmpatiility requirements,
And we're still trying to make them secure bu designing similar but allegedly better language.
Take something that was designed to be secure and efficient in the first place and has had decades of use as a secure language. These languages exist. I'm baffled why they are so ignored.
May I suggest Modula 3 ? Which, by the way, was *not* designed by Niklaus Wirth. [wikipedia.org]
-- hendrik
(Score: 1) by bram on Monday May 11 2015, @03:23AM
C dangerous?
Ha... C++ is the real danger.
OOP C++ programs tend to get unnecessary complex (the language is very complex to begin with) that it will create much more subtle bugs than C ever will.