• 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   ( @mox@lemmy.sdf.org ) OP
      link
      fedilink
      32
      edit-2
      1 month 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.

      •  TehPers   ( @TehPers@beehaw.org ) 
        link
        fedilink
        English
        4
        edit-2
        1 month ago

        If you’re hoping for the standard lib to have things built on evolving standards and ecosystems like HTTP clients, then I doubt that will ever happen. There are plenty of examples of why that would be a terrible idea (urllib, std::regex, etc).

      • Probably not going to happen. I will say that it’s less bad than you might think, because there is more-or-less an unofficial extended stdlib, i.e. high-quality, widely used libraries which are maintained by people in the Rust team.

        But yeah, I’m involved in a somewhat larger project and we’ve cracked 1000 transitive dependencies a few weeks ago, and I can tell you for free that I don’t personally know the maintainers of all of those.
        If this was more of a security-critical project, there’s probably a dozen or so direct dependencies that we would have implemented ourselves instead.

      •  Rogue   ( @Rogue@feddit.uk ) 
        link
        fedilink
        3
        edit-2
        1 month ago

        This has been one of my biggest frustrations while learning Rust. I’m coming from .NET which has an incredible wealth of official System and Microsoft libraries all of which are robust and well documented.

        Rust on the other hand has the bare minimum std library, with everything else implemented by the community. There isn’t even a std async library. It’s insane.

        Even the popular community libraries are severely lacking in documentation or inexplicably unmaintained.

        Rust has a ton of potential but it desperately needs some broad funding to align the fundamentals to a decent standard.

  • I’ve done a bit of C++ coding in my time. The feature list of the language is so long at this point that it is pretty much impossible for anyone new to learn C++ and grok the design decisions anymore. I don’t know if this is a good thing or not to keep adding and extending or whether C++ should sail into the sunset like Fortran and others before it.

      • Don’t get me wrong. There is still a time and a place for Fortran. And this will also likely always be the case for C++. But I’m not sure it is entirely wise to choose it if you’re creating a new project anymore.

    •  tal   ( @tal@lemmy.today ) 
      link
      fedilink
      English
      121 month ago

      The feature list of the language is so long at this point that it is pretty much impossible for anyone new to learn C++ and grok the design decisions anymore.

      Even if it is possible, it’s a high bar. The height of that bar matters in bringing new people in.

      I have seen decades of would-be “C++ killers” come and go. I think that in the end, it is C++ that kills C++. The language has just become unusably large. And that’s one thing that cannot be fixed by extending the language.

      • I have seen decades of would-be “C++ killers” come and go. I think that in the end, it is C++ that kills C++.

        I think you’re right.

        I am, admittedly, a card carrying member of the C++ curmudgeon club. But I would gladly gravitate to a sexy new C++ subset for my projects, if one gains some momentum.

        I do a lot with goLang, right now, instead.

        But I would adore joining with a community effort to choose reasonable safe default C++ libraries for a bunch of use cases, if one gained the traction to cover my own use cases.

    • C++ innovates often first and adapts it into mainstream. And its kind of a swiss-army knife. You don’t need to use and learn everything, just pick what you need. Unless you need to get into an old existing code base…

      Just an idea: The language could be divided into multiple standard levels, where each level has more features and functionality. It would be essentially a “restricted”, “standard” and “full” version of the language, where full is basically what it is now and the others are constrained versions with less functionality (no multiple inheritance and what not rules). But at this point, if you don’t use the language in its full, why bother with it at all? Just thinking a bit…

      • You don’t need to use and learn everything, just pick what you need.

        I used to think the same, but now I think you should at least skim through everything. Reason being otherwise you may reinvent the wheel a lot, and there are many use-cases where you really don’t want to do that (but C++ makes it so easy, I was constantly tempted to just do what I want and not look for it being already available)

        • This gets even more complex if you’re using a toolkit of some sort. C++ has a batteries-included way of doing something, then STL has another, and Qt yet another… Etc.

  • I’m a bit skeptical that a borrow checker in C++ can be as powerful as in rust, since C++ doesn’t have lifetime annotations. Without lifetime annotations, you have to do a whole program analysis to get the equivalent checks which isn’t even possible if you’re e.g. loading dynamic libraries, and prohibitively slow otherwise. Without that you can only really do local analysis which is of course good but not that powerful.

    Lifetime annotations in the type system is the right call, since it allows library authors to impose invariants related to ownership on their consumers. I doubt C++ will add it to their typesystem though.

  •  samc   ( @samc@feddit.uk ) 
    link
    fedilink
    English
    221 month ago

    The big downside is that, for backwards compatibility, the default must still be unsafe code. Ideally this could be toggled with a compiler flag, rather than having to wrap most code in “safe” blocks (like rust, but backwards).

    One potential upside that people don’t seem to be discussing is that the safe subset could also be the place to finally start cutting down the bloat of C++. We could encourage most developers to write exclusively in the safe subset, and aim to make that the “much smaller and cleaner language” trying to get out of C++.

  • Is this going to be re-posted every month?

    Anyway, I’ve come to know since then that the proposal was not a part of a damage control campaign, but rather a single person’s attempt at proposing a theoretical real solution. He misguidedly thought that there was actually an interest in some real solutions. There wasn’t, and there isn’t.

    The empire are continuing with the strategy of scamming people into believing that they will produce, at some unspecified point, complete magical mushrooms guidelines and real specified and implemented profiles.

    The proposal is destined to become perma-vaporware. The dreamy guidelines are going to be perma-WIP, the magical profiles are going to be perma-vapordocs (as in they will never actually exist, not even in theoretical form), and the bureaucracy checks will continue to be cashed.

    So not only there was no concrete strike back, it wasn’t even the empire that did it.