4 ms·

Is it me or is this essay really an incoherent mess? As much as I would like to agree with the author's stern verdict (and I am saying this as a systems program

Is it me or is this essay really an incoherent mess? As much as I would like to agree with the author's stern verdict (and I am saying this as a systems programmer with more than 20 years experience) I cannot make out the central argument.

jillesvangurp 5y ago
The central argument is that C/C++ is not worth the trouble for new code and that using it "correctly" is a theoretical thing that even experts struggle with. C/C++ programmers keep on insisting that they've found ways to do it right, finally. Some C/C++ programmers seem to believe that, unlike everybody else, they actually have the combination of wisdom, skills, and discipline to not fall into this trap. At this point that seems rather foolish. The author's main argument is that other languages that exclude categories of bugs that keep on popping up in the C/C++ world are good enough at this point to be used for essentially all system programming stuff. Apple, Google, Microsoft, etc. employ the best people that money can buy them. And they've each started actively discouraging the use of C/C++ for new stuff. Google actually created Go for this reason and they are now also using a lot of Rust lately. Apple created Swift to get rid of object C. And MS has been trying to move to C# (which they created) for the last two decades to put a stop to all the embarrassing issues they had with their native stuff. They too seem to like Rust lately. And obviously they each have to own up in public regularly about cases where, "oops, we did it again" despite having spent the last few decades to avoid having to do that so regularly. The usual suspects are bits of C/C++ doing things wrong with memory and bounds checking because their programmers made a mistake. It seems leaving this to humans to do "right" just is not good enough at this point. The article gets a bit messy with a rant on stateful vs. stateless and a few other things. But the main argument with that seems to boil down to the notion that depending on a lot of stuff like databases, memory caches, etc. that are often implemented using C/C++ is neither fast (because of network latency) nor safe (because of the above mentioned bugs and security issues). It's true and it's why alternatives to these infrastructure components written in other languages are a thing. They are plenty fast and in so far they are not, the network latency hides most of the issues to the point where you'd not notice much difference in terms of e.g. throughput or latency at the price of maybe slightly more CPU usage on servers that are mostly running nowhere even close to 100% CPU usage. Besides, adding more CPUs is cheap. Dealing with security problems is not. And of course using Rust for things that really need to be fast is a thing. There's growing amount of projects that are about creating drop in replacements for C/C++ things that have existed for a very long time where the goal is to actually improve their performance and safety by re-implementing them in Rust. It's the argument the article does not make. But it seems that with Rust, you can have your cake and eat it in terms of performance. So, why bother with C/C++ for new stuff? Why risk security bugs when the main argument of better performance simply does not hold true anymore? It's a solid argument. But I agree the article does a weak job of making it.
- deleted 5y ago
  [deleted]
- PaulDavisThe1st 5y ago
  > Apple created Swift to get rid of object C. But even Apple still notes that you should not write audio processing code in Swift, and if you use Objective C for this purpose, to avoid the Objective parts of it.
  - pjmlp 5y ago
    If I recall correctly from WWDC sessions, they note to prefer value types and avoid any kind of allocations, while the samples where shown in Swift.
- gravypod 5y ago
  > unlike everybody else, they actually have the combination of wisdom, skills, and discipline to not fall into this trap I'm constantly reminded of the NPC in Half Life 1 who says something like "Take me with you, I'm the one man who knows everything!" I know many programmers who think their one way of writing C++ will not cause any issues. None of them are 100% correct as I can always find a bug that a higher level language could have prevented and I'm not an "expert" in C++. I just know enough to be dangerous.
  - ncmncm 5y ago
    And, you only know programmers who know no more than you.
    - gravypod 5y ago
      This isn't a "know more" or "know less" than me thing. This is being-a-human thing. I've never written a large amount of C++ without a similar mistake creeping in. Humans make mistakes.
      - ncmncm 5y ago
kayodelycaon 5y ago
It reads like the notes for an article. It says everything the author is thinking but doesn’t give the context necessary to understand their thinking.
- ncmncm 5y ago
  Anywhere somebody says "C/C++" in the context of system programming, you can stop reading right there without missing out on anything. tl;dr: C and C++ have cooties, use literally anything else. Nothing to see here.
  - pjmlp 5y ago
    > C/C++ projects and build systems in Visual Studio https://docs.microsoft.com/en-us/cpp/build/projects-and-build-systems-cpp?view=msvc-170 https://docs.microsoft.com/en-us/cpp/build/projects-and-buil... > IBM Open XL C/C++ for AIX and XL C/C++ for AIX documentation library https://www.ibm.com/support/pages/ibm-open-xl-cc-aix-and-xl-cc-aix-documentation-library https://www.ibm.com/support/pages/ibm-open-xl-cc-aix-and-xl-...

jillesvangurp 5y ago

The central argument is that C/C++ is not worth the trouble for new code and that using it "correctly" is a theoretical thing that even experts struggle with. C/C++ programmers keep on insisting that they've found ways to do it right, finally. Some C/C++ programmers seem to believe that, unlike everybody else, they actually have the combination of wisdom, skills, and discipline to not fall into this trap. At this point that seems rather foolish. The author's main argument is that other languages that exclude categories of bugs that keep on popping up in the C/C++ world are good enough at this point to be used for essentially all system programming stuff. Apple, Google, Microsoft, etc. employ the best people that money can buy them. And they've each started actively discouraging the use of C/C++ for new stuff. Google actually created Go for this reason and they are now also using a lot of Rust lately. Apple created Swift to get rid of object C. And MS has been trying to move to C# (which they created) for the last two decades to put a stop to all the embarrassing issues they had with their native stuff. They too seem to like Rust lately. And obviously they each have to own up in public regularly about cases where, "oops, we did it again" despite having spent the last few decades to avoid having to do that so regularly. The usual suspects are bits of C/C++ doing things wrong with memory and bounds checking because their programmers made a mistake. It seems leaving this to humans to do "right" just is not good enough at this point. The article gets a bit messy with a rant on stateful vs. stateless and a few other things. But the main argument with that seems to boil down to the notion that depending on a lot of stuff like databases, memory caches, etc. that are often implemented using C/C++ is neither fast (because of network latency) nor safe (because of the above mentioned bugs and security issues). It's true and it's why alternatives to these infrastructure components written in other languages are a thing. They are plenty fast and in so far they are not, the network latency hides most of the issues to the point where you'd not notice much difference in terms of e.g. throughput or latency at the price of maybe slightly more CPU usage on servers that are mostly running nowhere even close to 100% CPU usage. Besides, adding more CPUs is cheap. Dealing with security problems is not. And of course using Rust for things that really need to be fast is a thing. There's growing amount of projects that are about creating drop in replacements for C/C++ things that have existed for a very long time where the goal is to actually improve their performance and safety by re-implementing them in Rust. It's the argument the article does not make. But it seems that with Rust, you can have your cake and eat it in terms of performance. So, why bother with C/C++ for new stuff? Why risk security bugs when the main argument of better performance simply does not hold true anymore? It's a solid argument. But I agree the article does a weak job of making it.

deleted 5y ago
[deleted]
PaulDavisThe1st 5y ago
> Apple created Swift to get rid of object C. But even Apple still notes that you should not write audio processing code in Swift, and if you use Objective C for this purpose, to avoid the Objective parts of it.
- pjmlp 5y ago
  If I recall correctly from WWDC sessions, they note to prefer value types and avoid any kind of allocations, while the samples where shown in Swift.
gravypod 5y ago
> unlike everybody else, they actually have the combination of wisdom, skills, and discipline to not fall into this trap I'm constantly reminded of the NPC in Half Life 1 who says something like "Take me with you, I'm the one man who knows everything!" I know many programmers who think their one way of writing C++ will not cause any issues. None of them are 100% correct as I can always find a bug that a higher level language could have prevented and I'm not an "expert" in C++. I just know enough to be dangerous.
- ncmncm 5y ago
  And, you only know programmers who know no more than you.
  - gravypod 5y ago
    This isn't a "know more" or "know less" than me thing. This is being-a-human thing. I've never written a large amount of C++ without a similar mistake creeping in. Humans make mistakes.
    - ncmncm 5y ago

kayodelycaon 5y ago

It reads like the notes for an article. It says everything the author is thinking but doesn’t give the context necessary to understand their thinking.

ncmncm 5y ago
Anywhere somebody says "C/C++" in the context of system programming, you can stop reading right there without missing out on anything. tl;dr: C and C++ have cooties, use literally anything else. Nothing to see here.
- pjmlp 5y ago
  > C/C++ projects and build systems in Visual Studio https://docs.microsoft.com/en-us/cpp/build/projects-and-build-systems-cpp?view=msvc-170 https://docs.microsoft.com/en-us/cpp/build/projects-and-buil... > IBM Open XL C/C++ for AIX and XL C/C++ for AIX documentation library https://www.ibm.com/support/pages/ibm-open-xl-cc-aix-and-xl-cc-aix-documentation-library https://www.ibm.com/support/pages/ibm-open-xl-cc-aix-and-xl-...