• Ephera@lemmy.ml
    link
    fedilink
    arrow-up
    38
    arrow-down
    3
    ·
    12 hours 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
      13
      arrow-down
      1
      ·
      edit-2
      7 hours 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
        2
        arrow-down
        1
        ·
        5 hours 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.

        • FizzyOrange@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          2 hours ago

          Interop between Rust and C++ is pretty bad actually - I can understand wanting to avoid that.

          However I still agree. I can’t see opt-in mechanisms like this moving the needle.