• FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    22
    arrow-down
    2
    ·
    7 days ago

    Doesn’t say anything you didn’t already know. Probably written with AI.

    Also the conclusion is wrong:

    Neither approach is universally superior.

    The Rust approach is obviously superior.

    • soulsource@discuss.tchncs.de
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      6 days ago

      I’m willing to bet that it’s AI. It soft-contradicts itself quite often, emphasising that C++ is “Performance First”, but then also claiming stuff like “Rust achieves memory safety with zero runtime overhead”.

      Edit: What I am trying to say is that I have seen text like this in LLM output quite often, if the LLM is mixing text from different sources in its training data.

      Also, there is just wrong stuff in the text itself, not only in the conclusion. For instance the claim that Rust’s type system makes data races impossible. They are easier to avoid, but there is nothing stopping you from writing data races… Here, for instance, have a data race in safe Rust

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        6 days ago

        That is not actually a “data race”. It is a race condition for sure, but a data race is a very specific thing - where two threads access the same location at the same time and at least one is a write.

        That could be unsafe in Rust because it might lead to reading “impossible values” like an enum that isn’t equal to any of its variants. Therefore safe Rust must prevent it or there’s a soundness hole.

    • BB_C@programming.dev
      link
      fedilink
      arrow-up
      3
      arrow-down
      2
      ·
      7 days ago

      The whole premise is wrong, since it’s based on the presumption of C++ and Rust being effectively generational siblings, with the C++ “designers” (charitable) having the option to take the Rust route (in the superficial narrow aspects covered), but choosing not to do so. When the reality is that C++ was the intellectual pollution product of “next C” and OOP overhype from that era (late 80’s/ early 90’s), resulting in the “C with classes” moniker.

      The lack of both history (and/or evolution) and paradigm talk is telling.