A good programmer will write good code in any language. A bad programmer will write bad code in all of them.
And that is the key insight. The Rust fanatics think that they can magically change that, like countless other morons in the history of coding. It never was a tool problem and, unless we get AI that can code well one day, it never will be a tool problem. It is a problem of insight and skill. What I really din't get is how these people can ignore all the evidence. In all other engineering fields, it is well known that the primary safeguard against problems is a competent engineer and that everything else just helps to improve efficiency, and can only moderately improve safety and certainly cannot replace insight and understanding. Just some larger faction of the coders believe in their technological field is completely different and that eventually there will be a "silver bullet" (Brooks, 1975), that finally will make coding an activity where they do not screw up. Well, of course they will continue to screw up, because they are mistaken about where the core problem is.
C++ is also a much worse language than C. Its design is overly complex, its performance when you really use OO is problematic, the access rights are a mess, it suffers massively from the "second system effect", etc. You can basically only use it as an example how to not design a language. IMO C++ should definitely not be used by anyone. Going from C++ to Rust, I can see why people mistakenly believe Rust is their salvation. They flee a disaster area for something that works moderately well. And probably a lot of them believe the marketing lies that come with Rust and think they can now finally produce good code. Competent C coders do not care though.
Rust has done one thing EXTREMELY well - hype. Like almost all languages, Rust won't normally have buffer overflows. They've hyped that so much it would make PT Barnum blush, acting like that's something special.
The only way you get buffer overflows these days is if you turn OFF the standard warnings, and use deprecated functions, while writing C. So Rust's "claim to fame" really just comes down to "on one very specific point, it's safer than C used to be back in the 1980s".
I've looked at Rust enough to know I don't want to use it any more than I want to wipe my ass with a cheese grater. I don't have to test that out to know it's not a good idea. They have done a phenomenal job of hype, though, comparing it to 1980s C. Guess what - C in 2018 also isn't 1980s C, every modern language is safe from buffer overruns assuming a competent programmer.
I fully agree on this. And I do write software in C, including, for example, some long-running pretty large multi-threaded demon recently for a customer. You only code buffer overflows in C these days when you are reckless or incompetent. The problem the Rust fanatics cannot see is that reckless or incompetent people will write bad Rust code too. The bugs will just be much harder to find than buffer overflows, which are pretty easy to find with modern tools. Fuzzing, higher compiler warning levels, looking for use of known-to-be-unsafe library functions (strcpy, e.g.), code-review of candidate code snippets, etc. all work well.
Getting rid of buffer-overflows in a language causes as much and possibly more problem than it solves and just makes some people think they can write complex code in Rust "safely". Not so. For example, botched access right handling in business code (something I see regularly when reviewing code) is a much worse problem than a buffer overflow and Rust can do exactly nothing about that. It is hard to find, but if somebody finds and exploits it, there is no warning. No crash to indicate something went wrong. The promises made by the Rust propaganda are mostly lies, often not directly, but in what is implied.
Rust does not turn a bad coder into a good coder. It does make bad coders much more dangerous, because now the bad coder cannot make some obvious mistakes anymore that would nicely point out their lack of skill. Now the bugs become subtle and the code runs just fine when somebody attacks them. The problem really is that the designers of Rust do not understand code security at all and that the "leadership" behind Rust probably believes they can now hire even cheaper coders than the incompetent bunch they were using before. Buffer overflows in code are a problem, but much more and much more importantly they are a symptom of bad coders.
Now, I am well aware that Rust does some other things and some of them are quite interesting for assessing code quality. They are a complete fail at improving code quality, because they miss the root-cause entirely. What Rust essentially does is allow bad coders to hide longer.
Dude, just search any software engineering journal. Unsafe languages make for more bugs. The design of the tool determines safety and performance as much as training, if not more.
I read these papers. For a while. Then I stopped, because that is not actually what matters. Counting bugs is pretty worthless, even when you only do reliability and resilience. With security, it is basically completely meaningless. This is not the only area where counting-metrics give meaningless numbers.
Having used a fancy assembler, I agree. C is in a whole different class, because with that fancy assembler, most of what you do is find out about the target CPU and and low-level I/O. And you do that again for every hardware architecture. With C you just need to know the coding model of the language and the language itself is way more powerful than even the most souped-up assembler. Sure, there are a few fine details in C where being able to do any assembler variant is really helpful in understanding then, but that does not make C some kind of assembler at all.
I do agree that this guy is an idiot. He carters to all the coders that fancy them bad-ass but that cannot write solid C code and blame the tool for that.
You overlook that the language brings in a very small part of the difficulty of any software project. And, incidentally, depending on the application pretty much every tool is "unsafe". The advantage of C is that the incompetent coders fail early and obviously.
Oh please... Rust is for people that want to be more productive with their time at the expense of some additional system resources. For the majority of software projects it is a good deal.
Nonsense. That is just the propaganda the Rust fanatics put out.
Yes. At least "-Wall" and when some warning is really not an error (it happens), tell the compiler explicitly to ignore the thing at the specific place where it happens.
And that is just the point. Kernels, drivers, high-performance software all are inherently unsafe. The only thing that can make them save is coders that really know what they are doing. These seem to be slowly dying out and the mediocre ones that follow want their safe space instead.
Programming languages, in general, need to be human proofed. We have a ton of empirical data to support this for decades.
No, you do not. Sure, when you let incompetents write advanced things, it will lead to them making harder to find bugs. But that is something else entirely. Now go back to play with VB or JavaScript.
Nonsense. It is "if it is not broken, do not fix it." C is not broken and the majority of the kernel is already written in it. It is just a tool that requires you to know what you are doing. But that applies to kernel development anyways. Rust is for morons with delusions that do not have what it takes but think they can write advanced code anyways. They cannot. The language is not the main difficulty here.
Incidentally, the believers in "just use this great new tool and all your problems will be solved" have been around forever, and they have been just as stupid way back as they are today. Brooks already had a chapter on it: "There is no silver bullet." Yet time and again, some people with little understanding of what matters claim that their pet-tool is that silver bullet.
That is basically the thing that applies to C code and has applied to it from the beginning. In the hands of somebody that knows what they are doing, C is not more dangerous than any other language.
These were pre-college people that thought they were getting a good quality continued education. They got ripped off at a time where they did not yet have toe education needed to see that. The problem is that the scam is not that obvious and that in addition there is no good alternative. Any good college or university education pays for itself, we see that in Europe. But in the US, except for some few elite institutions, they seem to be primarily interested in separating the students from their money. The problem with that is that it is just another instance of the short-term view capitalism that has gotten so prevalent. Capitalism with a strategic view does not support such scams, but in a world were enterprises only look at the next quarter and planning for 3 years is already called a long-term strategy (it is not. Long-term is 10 years and beyond), everything goes to hell pretty quick and this is just one instance of the problem.
You also overlook that you make this choice basically once in life, with no 2nd chance to get it right. That is a strong reason why this scam works in the first place.
Slashdot Mirror
A good programmer will write good code in any language. A bad programmer will write bad code in all of them.
And that is the key insight. The Rust fanatics think that they can magically change that, like countless other morons in the history of coding. It never was a tool problem and, unless we get AI that can code well one day, it never will be a tool problem. It is a problem of insight and skill. What I really din't get is how these people can ignore all the evidence. In all other engineering fields, it is well known that the primary safeguard against problems is a competent engineer and that everything else just helps to improve efficiency, and can only moderately improve safety and certainly cannot replace insight and understanding. Just some larger faction of the coders believe in their technological field is completely different and that eventually there will be a "silver bullet" (Brooks, 1975), that finally will make coding an activity where they do not screw up. Well, of course they will continue to screw up, because they are mistaken about where the core problem is.
C++ is also a much worse language than C. Its design is overly complex, its performance when you really use OO is problematic, the access rights are a mess, it suffers massively from the "second system effect", etc. You can basically only use it as an example how to not design a language. IMO C++ should definitely not be used by anyone. Going from C++ to Rust, I can see why people mistakenly believe Rust is their salvation. They flee a disaster area for something that works moderately well. And probably a lot of them believe the marketing lies that come with Rust and think they can now finally produce good code. Competent C coders do not care though.
Rust has done one thing EXTREMELY well - hype. Like almost all languages, Rust won't normally have buffer overflows. They've hyped that so much it would make PT Barnum blush, acting like that's something special.
The only way you get buffer overflows these days is if you turn OFF the standard warnings, and use deprecated functions, while writing C. So Rust's "claim to fame" really just comes down to "on one very specific point, it's safer than C used to be back in the 1980s".
I've looked at Rust enough to know I don't want to use it any more than I want to wipe my ass with a cheese grater. I don't have to test that out to know it's not a good idea. They have done a phenomenal job of hype, though, comparing it to 1980s C. Guess what - C in 2018 also isn't 1980s C, every modern language is safe from buffer overruns assuming a competent programmer.
I fully agree on this. And I do write software in C, including, for example, some long-running pretty large multi-threaded demon recently for a customer. You only code buffer overflows in C these days when you are reckless or incompetent. The problem the Rust fanatics cannot see is that reckless or incompetent people will write bad Rust code too. The bugs will just be much harder to find than buffer overflows, which are pretty easy to find with modern tools. Fuzzing, higher compiler warning levels, looking for use of known-to-be-unsafe library functions (strcpy, e.g.), code-review of candidate code snippets, etc. all work well.
Getting rid of buffer-overflows in a language causes as much and possibly more problem than it solves and just makes some people think they can write complex code in Rust "safely". Not so. For example, botched access right handling in business code (something I see regularly when reviewing code) is a much worse problem than a buffer overflow and Rust can do exactly nothing about that. It is hard to find, but if somebody finds and exploits it, there is no warning. No crash to indicate something went wrong. The promises made by the Rust propaganda are mostly lies, often not directly, but in what is implied.
Rust does not turn a bad coder into a good coder. It does make bad coders much more dangerous, because now the bad coder cannot make some obvious mistakes anymore that would nicely point out their lack of skill. Now the bugs become subtle and the code runs just fine when somebody attacks them. The problem really is that the designers of Rust do not understand code security at all and that the "leadership" behind Rust probably believes they can now hire even cheaper coders than the incompetent bunch they were using before. Buffer overflows in code are a problem, but much more and much more importantly they are a symptom of bad coders.
Now, I am well aware that Rust does some other things and some of them are quite interesting for assessing code quality. They are a complete fail at improving code quality, because they miss the root-cause entirely. What Rust essentially does is allow bad coders to hide longer.
Thanks, at least one person gets it.
No. Unlike you, I have actual insight.
You "well known fact" is not a fact. It is just something you believe.
And if you believe that, you just clearly indicated that you are not worth talking to.
Ah, the old "you don't know it until you try it" fallacy so dear to fanatics of all kinds.
Dude, just search any software engineering journal. Unsafe languages make for more bugs. The design of the tool determines safety and performance as much as training, if not more.
I read these papers. For a while. Then I stopped, because that is not actually what matters. Counting bugs is pretty worthless, even when you only do reliability and resilience. With security, it is basically completely meaningless. This is not the only area where counting-metrics give meaningless numbers.
Having used a fancy assembler, I agree. C is in a whole different class, because with that fancy assembler, most of what you do is find out about the target CPU and and low-level I/O. And you do that again for every hardware architecture. With C you just need to know the coding model of the language and the language itself is way more powerful than even the most souped-up assembler. Sure, there are a few fine details in C where being able to do any assembler variant is really helpful in understanding then, but that does not make C some kind of assembler at all.
I do agree that this guy is an idiot. He carters to all the coders that fancy them bad-ass but that cannot write solid C code and blame the tool for that.
You overlook that the language brings in a very small part of the difficulty of any software project. And, incidentally, depending on the application pretty much every tool is "unsafe". The advantage of C is that the incompetent coders fail early and obviously.
Oh please... Rust is for people that want to be more productive with their time at the expense of some additional system resources. For the majority of software projects it is a good deal.
Nonsense. That is just the propaganda the Rust fanatics put out.
Yes. At least "-Wall" and when some warning is really not an error (it happens), tell the compiler explicitly to ignore the thing at the specific place where it happens.
No, most are related to incompetent coders. Compiler optimizations are more interesting though, so they get more press.
Looks to me like these people just want their "safe space" in the kernel, where nobody tells them off for having coded something stupid.
And that is just the point. Kernels, drivers, high-performance software all are inherently unsafe. The only thing that can make them save is coders that really know what they are doing. These seem to be slowly dying out and the mediocre ones that follow want their safe space instead.
> it's not 'child proofed'
Programming languages, in general, need to be human proofed. We have a ton of empirical data to support this for decades.
No, you do not. Sure, when you let incompetents write advanced things, it will lead to them making harder to find bugs. But that is something else entirely. Now go back to play with VB or JavaScript.
I like that! Very appropriate.
Unfortunately, the believers in silver bullets will not die out.
Nonsense. It is "if it is not broken, do not fix it." C is not broken and the majority of the kernel is already written in it. It is just a tool that requires you to know what you are doing. But that applies to kernel development anyways. Rust is for morons with delusions that do not have what it takes but think they can write advanced code anyways. They cannot. The language is not the main difficulty here.
Incidentally, the believers in "just use this great new tool and all your problems will be solved" have been around forever, and they have been just as stupid way back as they are today. Brooks already had a chapter on it: "There is no silver bullet." Yet time and again, some people with little understanding of what matters claim that their pet-tool is that silver bullet.
If you ask that, then you do not understand the target application.
That is basically the thing that applies to C code and has applied to it from the beginning. In the hands of somebody that knows what they are doing, C is not more dangerous than any other language.
On the plus-side, they have far better CPU-CPU interconnect than Intel and always had.
Indeed. And this partially explained why Intel was ahead of AMD speed-wise. They played fast and loose and f*** the customer.
These were pre-college people that thought they were getting a good quality continued education. They got ripped off at a time where they did not yet have toe education needed to see that. The problem is that the scam is not that obvious and that in addition there is no good alternative. Any good college or university education pays for itself, we see that in Europe. But in the US, except for some few elite institutions, they seem to be primarily interested in separating the students from their money. The problem with that is that it is just another instance of the short-term view capitalism that has gotten so prevalent. Capitalism with a strategic view does not support such scams, but in a world were enterprises only look at the next quarter and planning for 3 years is already called a long-term strategy (it is not. Long-term is 10 years and beyond), everything goes to hell pretty quick and this is just one instance of the problem.
You also overlook that you make this choice basically once in life, with no 2nd chance to get it right. That is a strong reason why this scam works in the first place.