4 ms·

Yes. I understand the argument. It's only been reiterated on HN hundreds of times now. > it removes the last excuse of C/C++ Odd way of looking at it. I never

by chjj 5y ago

Yes. I understand the argument. It's only been reiterated on HN hundreds of times now. > it removes the last excuse of C/C++ Odd way of looking at it. I never ask myself "what _excuse_ can I give myself for using this tool"? I'll continue using C and I don't need an excuse. I prefer C.

UncleMeat 5y ago
But do your users prefer C? For software engineering to be a professional discipline, we really need to make choices based on the product outcome rather than based on what feels fun to program.
- chjj 5y ago
  I imagine they do. If they didn't, they wouldn't be using it. They would instead be using some equivalent piece of software written in a trendy language.
  - UncleMeat 5y ago
    The large majority of users cannot make well informed security risk decisions like this. Engineers should do the right thing and help these users. In the same way, I can't make some meaningful risk assessment for using a bridge or riding an elevator. Civil Engineers don't just get to say "well, if users are concerned about the safety of my bridge then they can make a different choice so I'm going with the stuff I personally like working with." Why do Software Engineers get away with this? Outside of small hobbyist projects, the industry has an obligation to provide users with safe software.
    - chjj 5y ago
      Right. So in your opinion, is it irresponsible to write a project intended for production in C or C++?
      - pjmlp 5y ago
        I bet if liability was a common thing in software delivery, those languages wouldn't be the first option after a couple of lawsuits.
        UncleMeat 5y ago
        Yeah can you imagine if it actually mattered if companies made choices that they knew were inevitably going to lead to zero-click exploits on internet-enabled devices? Somebody sitting down to write a media decoder in C today knows that this means a steady stream of exploits harming their customers.
      - UncleMeat 5y ago
        I believe that it is irresponsible to 1. Start new projects intended for production that have nontrivial security threats in C or C++ 2. Not have a plan to categorically prevent memory safety errors in legacy codebases over the next decade or so, whether that be by transitioning to new languages or by applying rigorous hardware-level memory tracking

by chjj 5y ago

UncleMeat 5y ago

But do your users prefer C? For software engineering to be a professional discipline, we really need to make choices based on the product outcome rather than based on what feels fun to program.

chjj 5y ago
I imagine they do. If they didn't, they wouldn't be using it. They would instead be using some equivalent piece of software written in a trendy language.
- UncleMeat 5y ago
  The large majority of users cannot make well informed security risk decisions like this. Engineers should do the right thing and help these users. In the same way, I can't make some meaningful risk assessment for using a bridge or riding an elevator. Civil Engineers don't just get to say "well, if users are concerned about the safety of my bridge then they can make a different choice so I'm going with the stuff I personally like working with." Why do Software Engineers get away with this? Outside of small hobbyist projects, the industry has an obligation to provide users with safe software.
  - chjj 5y ago
    Right. So in your opinion, is it irresponsible to write a project intended for production in C or C++?
    - pjmlp 5y ago
      I bet if liability was a common thing in software delivery, those languages wouldn't be the first option after a couple of lawsuits.
      - UncleMeat 5y ago
        Yeah can you imagine if it actually mattered if companies made choices that they knew were inevitably going to lead to zero-click exploits on internet-enabled devices? Somebody sitting down to write a media decoder in C today knows that this means a steady stream of exploits harming their customers.
    - UncleMeat 5y ago
      I believe that it is irresponsible to 1. Start new projects intended for production that have nontrivial security threats in C or C++ 2. Not have a plan to categorically prevent memory safety errors in legacy codebases over the next decade or so, whether that be by transitioning to new languages or by applying rigorous hardware-level memory tracking