On the one side I really like c and c++ because they’re fun and have great performance; they don’t feel like your fighting the language and let me feel sort of creative in the way I do things(compared with something like Rust or Swift).

On the other hand, when weighing one’s feelings against the common good, I guess it’s not really a contest. Plus I suspect a lot of my annoyance with languages like rust stems from not being as familiar with the paradigm. What do you all think?

  • @[email protected]
    link
    fedilink
    English
    -4
    edit-2
    4 months ago

    I’m going to advocate for C here: the sheer simplicity, fast compile times, and power it gives you means it’s not a bad language, even after all these years. Couple that with the fact that everything supports it.

    Rust, while I don’t actually know how to write it, seems much more difficult to learn, slower to compile, and if you want to do anything with memory, you have to fight the compiler.

    And memory bugs are only a subset of bugs that can be exploited in a program. Pretending Rust means no more exploitation is stupid.

    • @[email protected]
      link
      fedilink
      124 months ago

      And memory bugs are only a subset of bugs that can be exploited in a program. Pretending Rust means no more exploitation is stupid.

      This is facile.

      According to Microsoft, about 70% of security bugs they see are memory safety issues.

      Yes: if you introduce memory safety, there’s still those 30% of security bugs left. But, well, I’d rather worry about 30% of issues than 100%…

      Similarly, I use libraries that eliminate SQL injections unless you really go out of your way.

    • @carpelbridgesyndrome
      cake
      link
      English
      104 months ago

      In cases where bugs have been counted they tended to make up the majority of vulnerabilities. Chrome, Firefox, and Windows reported that around 70% of security vulnerabilites were memory corruption. Yes a subset, but the majority of the worst subset.

      • @[email protected]
        link
        fedilink
        English
        04 months ago

        I’ve also heard that unsafe Rust is even more dangerous than C. I guess that’s probably something to do with the fact that you’re always on your toes in C vs Rust? I don’t know. But if you need to do any sort of manual memory management you’re going to need unsafe Rust.

        • @IAm_A_Complete_Idiot
          link
          64 months ago

          No, rust is stricter because you need to think a lot more about whether weird edge cases in your unsafe code can potentially cause UB. For ex. If your data structure relies on the Ord interface (which gives you comparison operators and total ordering), and someone implements Ord wrong, you aren’t allowed to commit UB still. In C++ land I’d venture to guess most any developer won’t care - that’s a bug with your code and not the data structure.

          It’s also more strict because rusts referencing rules are a lot harder then C’s, since they’re all effectively restrict by default, and just turning a pointer into a reference for a little bit to call a function means that you have to abide by those restrictions now without the help of the compiler.

        • @carpelbridgesyndrome
          cake
          link
          English
          44 months ago

          The thing is the whole c program is unsafe. In rust individual parts are marked unsafe. This means auditing should be easier. Also being always on your toes isn’t really viable. Breaking down the program into safe vs unsafe is probably an improvment

        • @[email protected]
          link
          fedilink
          English
          34 months ago

          Unsafe code should be a very, very small part of any Rust codebase. Lots of major libraries have a policy against including any unsafe code at all, because 99.9% of the time you can do just as well with safe cost. The major exception is when you need to call C code.

        • Rustmilian
          link
          fedilink
          English
          1
          edit-2
          1 month ago

          I’ve also heard that unsafe Rust is even more dangerous than C.

          Utterly Untrue :
          It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked.

    • @[email protected]
      link
      fedilink
      English
      94 months ago

      I’ve written quite a bit of Rust and a lot of C and C++ code. I’ll take Rust over C or C++ for any task, including ones where memory safety isn’t a concern. Yes, there’s a learning curve, but overall it’s just more pleasant to use. Now that I’m used to it, writing C++ code feels just as much like fighting the compiler as Rust ever did.

    • Jelloeater
      link
      fedilink
      English
      5
      edit-2
      4 months ago

      You’re in the wrong place if you want to pitch C over Rust 😅

      • @[email protected]
        link
        fedilink
        English
        5
        edit-2
        4 months ago

        The… programming community?

        I might adopt Rust, I have no hard feelings against it, I just like not fighting with the compiler and having the fastest execution possible.

        But hey, even Lemmy needs some hot takes to keep it lively.

    • @[email protected]
      link
      fedilink
      24 months ago

      Zig is a pretty interesting alternative to C

      Pretending Rust means no more exploitation is stupid.

      I guess? Are you alluding to someone or something in particular?

    • @[email protected]OP
      link
      fedilink
      24 months ago

      Maybe it’s just because I haven’t had to deal with the scenario yet but does compile time really matter? I mean for small programs it seems it’s almost instant on modern machines and for large programs I would assume, if it exists, that you would be using the equivalent of make so you would only be recompiling the small changes made.

      • @fruitycoder
        link
        34 months ago

        Compile times are a barrier. How much of hurdle that really is depends on the project and dev. Like readability, accessabilty, friendlyness, license and userbase it all adds up to who can work on the project.

        I know in the DevX space the rule of the thumb is you want to have devs see results of a commit before the urge to check their phone/other tabs wins over because that context switching is timly for them.