• Ephera@lemmy.ml
    link
    fedilink
    arrow-up
    3
    ·
    29 days ago

    The inherent problem with this kind of solution is that if you don’t break backwards compatibility, you don’t get rid off all the insecure code.

    And if you do break backwards compatibility, there’s not much reason to stick to C++ rather than going for Rust with its established ecosystem…

    • mox@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      29 days ago

      Given how long and widely C++ has been a dominant language, I don’t think anyone can reasonably expect to get rid of all the unsafe code, regardless of approach. There is a lot of it.

      However, changing the proposition from “get good at Rust and rewrite these projects from scratch” to “adopt some incremental changes using the existing tooling and skills you already have” would lower the barrier to entry considerably. I think this more practical approach would be likely to reach far more projects.

      • LANIK2000@lemmy.world
        link
        fedilink
        arrow-up
        0
        arrow-down
        1
        ·
        29 days ago

        There’s been plenty of interop options between C++ and just about anything for decades. If languages like D, that made it piss easy, weren’t gonna change people’s minds, nothing can. Ditching C++ is the only way forward.

    • anti-idpol action@programming.dev
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      28 days ago

      wake me up when Rust fixes its’ supply chain attacks susceptibility (solid stdlib and rejecting external crates, including transitive deps