6 ms·

The worst thing about these kinds of articles is the troves of junior programmers that never touched systems programming with a stick before but will read this

The worst thing about these kinds of articles is the troves of junior programmers that never touched systems programming with a stick before but will read this on hackernews today and sit in the office tomorrow lecturing seasoned coders how they´re dumb for not having seen the light and using an unsafe language. This is how stupid cargo cult gets made, guys. It's easy to repeat some talking points that you found on the rust homepage or another internet forum, but doing that does not make you an enlightened programmer! Do c/c++ for 10 years, like the author, and then you're qualified to comment about the topic. If you're new to this, try to put your time into actually learning about these topics and not just blindly repeating other peoples opinions. Please don't say things like "c/c++ is unsafe and should not be used" without understanding it first. And try to consider for a moment that a humongous part of the critical software in the world is written in it. It is the industry standard for all things embedded and low level. Consider that maybe the reason for that is not that everybody outside of hacker news is stupid. The thing is, I'm not even saying the author is wrong (I don't think he is). I'm just saying that circulating these kinds of opinion posts here and then applauding each other for being such brilliant rust fanboys is not helpful.

pjmlp 9y ago
Fact 1, the article doesn't mention Rust a single time. Fact 2, mostly safe systems programming languages exist since ESPOL (1961), 10 years older than C, and with a great linage of attempts of safe systems programming outside AT&T walls, so plenty of alternatives are available So as someone with more than 10 years of C and C++ experience, among other programming languages, before focusing on Java and .NET, I find these kind of articles valuable because they are the proof there isn't such thing as the 10x C developer that never does mistakes.
- ccommsxx 9y ago
  I feel you're missing my point. The article doesn't mention rust but my comment was phrased in the context of the current rust craze on HN. As I said, I agree with you and the author that all of us do inevitably make mistakes. I also agree that the c-family of languages makes it somewhat more easy to shoot yourself in the foot in a bad way than others. I'm not saying innovation on safe languages is bad, or that using safe languages is bad. My disagreement with you and the sibling is probably on the point of whether one can learn something useful about the limitations and pitfalls of c-family languages by reading a single-page all-opinion post about it. You and the sibling appear to believe so, I do not. I don't think we will come to a complete agreement on this, but I certainly understand and respect your and sibling's view.
  - skybrian 9y ago
    There's a broader question of when to investigate a technology yourself versus learning from others. A new programmer could spend ten years programming in [some language] or they could learn from other people to avoid it, and possibly save themselves a lot of time. Yes, that means you're just following the bandwagon, but sometimes that's efficient. I would share the link, though, rather than making my own assertions, and be open to other arguments from more experienced people.
  - deleted 9y ago
    [deleted]
  - pjmlp 9y ago
    The main issue I have found out during all these years of advocating safe practices in C and C++, specially among C developers given that the C++ community does care about type safe programming, is that they land in deaf hears. Currently, writing blog articles re-explained what is bad and should be avoid seem a waste of effort, given that even respectable researchers like DJB get ignored.
- fnl 9y ago
  There is a big difference between modern C++ (C++11 ff.) and even the most current iteration of C. The two languages might have been quite similar back in the day when "C with classes" was created, but they have diverged significantly since then. Therefore, I think it is wrong to consider C a "proper subset" of C++, as often is claimed, or even to treat them as equals. In other words, the real fallacy of the original post is throwing C and C++ into one pot, as if it were all the same - something I consider could not be further from the truth, even back in the C++98 days. A part of that problem is that persons having a (possibly incomplete) understanding of only one of the two languages (on top) believe they can apply that understanding to the other language, too, without having to learn the correct idiomatic usage of the other [1]. And that situation is made even worse by posts that claim to only have to point out some "gotchas" you need to be aware of to understand the other language, particularly coding in C after picking up some C++. Just to name the most critical changes in C++ over C: RAII, abstractions (objects/polymorphism/templates/generics), I/O, error handling, and namespaces/encapsulation. However, not even keywords work the same (fe., `const` and `typedef`). Finally, when C code breaks, it typically is closely related to one of those features that would have tooling in C++ to avoid the issue (in particular, containers to avoid resource leakages in connection with more advanced error and I/O handling techniques). In other words, I pretty much agree with the GP about the hyperbole of the linked blog entry, and would only let the original post "stand" if it had some kind of significant `C != C++` distinction. I can agree with anyone who thinks that coding in C is probably a Bad Idea today unless you must due to maintaining legacy code-bases, while I think that C++11 has greatly changed the issues you have to look after when coding in C++, making it a lot more safer - and IMO quite fun - to use. [1] https://olvemaudal.com/2011/10/10/deep-c/ https://olvemaudal.com/2011/10/10/deep-c/ (note that all C++ issues in the post can be avoided by using proper modern C++, like "naked" `new` usages and such) [minors edits after the post for spelling corrections and readability - but no semantic changes]
  - pjmlp 9y ago
    I kind of agree with you, back in the day during the C vs C++ flamewars, I was always in the C++ side, and still am if you follow my comment history. However a big part of the problem, which you kind of refer to, when talking about lack of understanding between C and C++ differences is that, at least on enterprise space, many use C++ compilers for writing what is mostly C-like code. Do you know why most MFC classes have an Afx prefix? Microsoft created a C++ framework similar to OWL in abstraction capabilities, but the test group of early adopters said it was too high level and they just wanted a thin wrapper around Win32, hence Afx was reborn as MFC. [0] I like modern C++ very much, and it is true that many of the "modern C++" concepts were already available on C++98, the problem is getting developers to actually use it, specially old school devs when working in companies where CI builds, static analyzers or sanitizers aren't part of the culture. Which is the situation I see most of the time across many enterprise customers. [0] http://cs.sookmyung.ac.kr/class/00891/C++/mfc-faq/ http://cs.sookmyung.ac.kr/class/00891/C++/mfc-faq/
irundebian 9y ago
No, you can also learn from experiences of others instead of doing mistakes for yourself.
simias 9y ago
Beginners will feel overconfident and some will even try to teach more experienced coders how to do things "right" regardless of these types of articles. We've all been there and we probably still are in some fashion. I don't see how that diminishes the value of TFA though. Any kind of guidelines can be "abused" by taking it to the extreme without actually taking the time to consider if it actually makes sense. Also while I do have significantly more than 10 years of experience in C I think it's silly to say that you can't criticize the language if you can't recite the K&R by heart. You don't need to know all the intricacies of C's aliasing rules to peruse the long list of CVEs caused by faulty memory handling. The world of computing changed drastically over the past decades, for a given application maybe C or C++ was a great choice in the 90's, doesn't mean there's no better alternative now. People telling everybody to ditch C like it never existed and rewrite everything in Rust or Go are silly and are probably the junior coders you're talking about who lack real world experience. Doesn't mean that the opposite reaction of "if it ain't completely broke don't fix it" is any more clever.
- ccommsxx 9y ago
  Well, I agree with you on practically everything you said. Just for the record, I never intended to imply that somebody should not criticize their tools until they fully mastered them and I certainly don't claim to have done so. I just (tried to) say that I don't like it when others recite opinions from some blog post without even a basic understanding of the issues at hand as I find it leads to a very superficial discourse. I also didn't mean to imply that new projects should be done in C/C++ for the sake of historical reasons or something similar. In fact, I actually recently started working on a new project, written in rust (!) in an industrial setting. Part of the reason for my original comment is that I found there was _a lot_ of cult in content related to rust, in their marketing material and on rust-related posts on HN. While I really like some parts of the language, this aspect of the rust community is really turning me off at the moment and I hope it will get better over time.
  - alfiedotwtf 9y ago
    Let's say you're a fresh grad and looking at options for you future dev career: Option 1. Spend the next 5 years learning the ins and outs of C++, where it can bite you, where it can go wrong, all the intricate edge cases, etc... and you'll come out a better C++ programmer. Hopefully after 5 years of hard concentration, you may be able to write safe code (I still haven't met a C++ programmer that hasn't been burned by segfaults in production). Option 2. Spend a single month learning Rust. Play with it for another month or even two just to be sure. Hopefully after the 3rd month, they'll be 100% certain that their code won't break because of errors that are above their pay grade. I've done programming for over 12 years. x86 assembly and C for the earlier years. Then I realised that higher level languages gave me the power to code confidently without causing the errors that I was constantly seeing without explanation. After many years of HLL I wanted to go back down to the metal... after everything that I knew, "C or C++, not even once". Rust gives me the confidence to "compile once, run safe everywhere".
catdog 9y ago
> Do c/c++ for 10 years, like the author, and then you're qualified to comment about the topic. If you're new to this, try to put your time into actually learning about these topics and not just blindly repeating other peoples opinions. Please don't say things like "c/c++ is unsafe and should not be used" without understanding it first. I don't think you need 10 years to understand enough to be qualified to comment. Like it or not people make mistakes, even the most seasoned coders do. C does its best to turn every little oversight into a potential entry in the CVE database. > And try to consider for a moment that a humongous part of the critical software in the world is written in it. It is the industry standard for all things embedded and low level. That is a valid excuse to use it but it doesn't mean that shouldn't be changed. What you see quite often is people defending using C less because of leveraging the existing ecosystem but because "it's so beautifully simple" and this "experienced coder can do it right" elitism. > This is how stupid cargo cult gets made, guys. It's easy to repeat some talking points that you found on the rust homepage or another internet forum, but doing that does not make you an enlightened programmer! > The thing is, I'm not even saying the author is wrong (I don't think he is). I'm just saying that circulating these kinds of opinion posts here and then applauding each other for being such brilliant rust fanboys is not helpful. Nobody talks specifically about rust here, it's just a new promising language which is designed to fit inside the territories where C/C++ are prevalent and seems to have some traction. Rust is simply a non-theoretical opportunity to shift to something better.
- ccommsxx 9y ago
  You took my post as saying "all systems code should be written in C and that should always stay that way because people don't make mistakes". However, that is not at all what I said (also see other replies). What I said was that one should not blindly make the opposite (false) reverse assumptions, which are that "code should not be written in C/C++ because they are 'unsafe'" or "all code written in 'safe' languages is 'safe'" (both for a hand-wavy definition of safe). The point that I tried to make was that if you do not have a good understanding of C++, you're probably not qualified to comment on the matter of some alternative being safer/better than it or not. And also that just blindly repeating other's opinions is not a path to understanding in this case. I realize that the linked article didn't say or do that, but my comment was clearly not directed at the author of the post, but at the community of this forum (just look around in this thread to find some of the group-think I'm referring to).

pjmlp 9y ago

Fact 1, the article doesn't mention Rust a single time. Fact 2, mostly safe systems programming languages exist since ESPOL (1961), 10 years older than C, and with a great linage of attempts of safe systems programming outside AT&T walls, so plenty of alternatives are available So as someone with more than 10 years of C and C++ experience, among other programming languages, before focusing on Java and .NET, I find these kind of articles valuable because they are the proof there isn't such thing as the 10x C developer that never does mistakes.

ccommsxx 9y ago
I feel you're missing my point. The article doesn't mention rust but my comment was phrased in the context of the current rust craze on HN. As I said, I agree with you and the author that all of us do inevitably make mistakes. I also agree that the c-family of languages makes it somewhat more easy to shoot yourself in the foot in a bad way than others. I'm not saying innovation on safe languages is bad, or that using safe languages is bad. My disagreement with you and the sibling is probably on the point of whether one can learn something useful about the limitations and pitfalls of c-family languages by reading a single-page all-opinion post about it. You and the sibling appear to believe so, I do not. I don't think we will come to a complete agreement on this, but I certainly understand and respect your and sibling's view.
- skybrian 9y ago
  There's a broader question of when to investigate a technology yourself versus learning from others. A new programmer could spend ten years programming in [some language] or they could learn from other people to avoid it, and possibly save themselves a lot of time. Yes, that means you're just following the bandwagon, but sometimes that's efficient. I would share the link, though, rather than making my own assertions, and be open to other arguments from more experienced people.
- deleted 9y ago
  [deleted]
- pjmlp 9y ago
  The main issue I have found out during all these years of advocating safe practices in C and C++, specially among C developers given that the C++ community does care about type safe programming, is that they land in deaf hears. Currently, writing blog articles re-explained what is bad and should be avoid seem a waste of effort, given that even respectable researchers like DJB get ignored.
fnl 9y ago
There is a big difference between modern C++ (C++11 ff.) and even the most current iteration of C. The two languages might have been quite similar back in the day when "C with classes" was created, but they have diverged significantly since then. Therefore, I think it is wrong to consider C a "proper subset" of C++, as often is claimed, or even to treat them as equals. In other words, the real fallacy of the original post is throwing C and C++ into one pot, as if it were all the same - something I consider could not be further from the truth, even back in the C++98 days. A part of that problem is that persons having a (possibly incomplete) understanding of only one of the two languages (on top) believe they can apply that understanding to the other language, too, without having to learn the correct idiomatic usage of the other [1]. And that situation is made even worse by posts that claim to only have to point out some "gotchas" you need to be aware of to understand the other language, particularly coding in C after picking up some C++. Just to name the most critical changes in C++ over C: RAII, abstractions (objects/polymorphism/templates/generics), I/O, error handling, and namespaces/encapsulation. However, not even keywords work the same (fe., `const` and `typedef`). Finally, when C code breaks, it typically is closely related to one of those features that would have tooling in C++ to avoid the issue (in particular, containers to avoid resource leakages in connection with more advanced error and I/O handling techniques). In other words, I pretty much agree with the GP about the hyperbole of the linked blog entry, and would only let the original post "stand" if it had some kind of significant `C != C++` distinction. I can agree with anyone who thinks that coding in C is probably a Bad Idea today unless you must due to maintaining legacy code-bases, while I think that C++11 has greatly changed the issues you have to look after when coding in C++, making it a lot more safer - and IMO quite fun - to use. [1] https://olvemaudal.com/2011/10/10/deep-c/ https://olvemaudal.com/2011/10/10/deep-c/ (note that all C++ issues in the post can be avoided by using proper modern C++, like "naked" `new` usages and such) [minors edits after the post for spelling corrections and readability - but no semantic changes]
- pjmlp 9y ago
  I kind of agree with you, back in the day during the C vs C++ flamewars, I was always in the C++ side, and still am if you follow my comment history. However a big part of the problem, which you kind of refer to, when talking about lack of understanding between C and C++ differences is that, at least on enterprise space, many use C++ compilers for writing what is mostly C-like code. Do you know why most MFC classes have an Afx prefix? Microsoft created a C++ framework similar to OWL in abstraction capabilities, but the test group of early adopters said it was too high level and they just wanted a thin wrapper around Win32, hence Afx was reborn as MFC. [0] I like modern C++ very much, and it is true that many of the "modern C++" concepts were already available on C++98, the problem is getting developers to actually use it, specially old school devs when working in companies where CI builds, static analyzers or sanitizers aren't part of the culture. Which is the situation I see most of the time across many enterprise customers. [0] http://cs.sookmyung.ac.kr/class/00891/C++/mfc-faq/ http://cs.sookmyung.ac.kr/class/00891/C++/mfc-faq/

irundebian 9y ago

No, you can also learn from experiences of others instead of doing mistakes for yourself.

simias 9y ago

Beginners will feel overconfident and some will even try to teach more experienced coders how to do things "right" regardless of these types of articles. We've all been there and we probably still are in some fashion. I don't see how that diminishes the value of TFA though. Any kind of guidelines can be "abused" by taking it to the extreme without actually taking the time to consider if it actually makes sense. Also while I do have significantly more than 10 years of experience in C I think it's silly to say that you can't criticize the language if you can't recite the K&R by heart. You don't need to know all the intricacies of C's aliasing rules to peruse the long list of CVEs caused by faulty memory handling. The world of computing changed drastically over the past decades, for a given application maybe C or C++ was a great choice in the 90's, doesn't mean there's no better alternative now. People telling everybody to ditch C like it never existed and rewrite everything in Rust or Go are silly and are probably the junior coders you're talking about who lack real world experience. Doesn't mean that the opposite reaction of "if it ain't completely broke don't fix it" is any more clever.

ccommsxx 9y ago
Well, I agree with you on practically everything you said. Just for the record, I never intended to imply that somebody should not criticize their tools until they fully mastered them and I certainly don't claim to have done so. I just (tried to) say that I don't like it when others recite opinions from some blog post without even a basic understanding of the issues at hand as I find it leads to a very superficial discourse. I also didn't mean to imply that new projects should be done in C/C++ for the sake of historical reasons or something similar. In fact, I actually recently started working on a new project, written in rust (!) in an industrial setting. Part of the reason for my original comment is that I found there was _a lot_ of cult in content related to rust, in their marketing material and on rust-related posts on HN. While I really like some parts of the language, this aspect of the rust community is really turning me off at the moment and I hope it will get better over time.
- alfiedotwtf 9y ago
  Let's say you're a fresh grad and looking at options for you future dev career: Option 1. Spend the next 5 years learning the ins and outs of C++, where it can bite you, where it can go wrong, all the intricate edge cases, etc... and you'll come out a better C++ programmer. Hopefully after 5 years of hard concentration, you may be able to write safe code (I still haven't met a C++ programmer that hasn't been burned by segfaults in production). Option 2. Spend a single month learning Rust. Play with it for another month or even two just to be sure. Hopefully after the 3rd month, they'll be 100% certain that their code won't break because of errors that are above their pay grade. I've done programming for over 12 years. x86 assembly and C for the earlier years. Then I realised that higher level languages gave me the power to code confidently without causing the errors that I was constantly seeing without explanation. After many years of HLL I wanted to go back down to the metal... after everything that I knew, "C or C++, not even once". Rust gives me the confidence to "compile once, run safe everywhere".

catdog 9y ago

> Do c/c++ for 10 years, like the author, and then you're qualified to comment about the topic. If you're new to this, try to put your time into actually learning about these topics and not just blindly repeating other peoples opinions. Please don't say things like "c/c++ is unsafe and should not be used" without understanding it first. I don't think you need 10 years to understand enough to be qualified to comment. Like it or not people make mistakes, even the most seasoned coders do. C does its best to turn every little oversight into a potential entry in the CVE database. > And try to consider for a moment that a humongous part of the critical software in the world is written in it. It is the industry standard for all things embedded and low level. That is a valid excuse to use it but it doesn't mean that shouldn't be changed. What you see quite often is people defending using C less because of leveraging the existing ecosystem but because "it's so beautifully simple" and this "experienced coder can do it right" elitism. > This is how stupid cargo cult gets made, guys. It's easy to repeat some talking points that you found on the rust homepage or another internet forum, but doing that does not make you an enlightened programmer! > The thing is, I'm not even saying the author is wrong (I don't think he is). I'm just saying that circulating these kinds of opinion posts here and then applauding each other for being such brilliant rust fanboys is not helpful. Nobody talks specifically about rust here, it's just a new promising language which is designed to fit inside the territories where C/C++ are prevalent and seems to have some traction. Rust is simply a non-theoretical opportunity to shift to something better.

ccommsxx 9y ago
You took my post as saying "all systems code should be written in C and that should always stay that way because people don't make mistakes". However, that is not at all what I said (also see other replies). What I said was that one should not blindly make the opposite (false) reverse assumptions, which are that "code should not be written in C/C++ because they are 'unsafe'" or "all code written in 'safe' languages is 'safe'" (both for a hand-wavy definition of safe). The point that I tried to make was that if you do not have a good understanding of C++, you're probably not qualified to comment on the matter of some alternative being safer/better than it or not. And also that just blindly repeating other's opinions is not a path to understanding in this case. I realize that the linked article didn't say or do that, but my comment was clearly not directed at the author of the post, but at the community of this forum (just look around in this thread to find some of the group-think I'm referring to).