8 ms·

> Safe C++ is a really important project What makes you say this? It seems to me like we already have a lower-overhead approach to reach the same goal (a low-l

• steveklabnik 2y ago
  I am pro any movement towards memory safety. Sure, I won't stop writing Rust and start moving towards C++ for this. But not everyone is interested in introducing a second toolchain, for example. Also, as this paper mentions, Safe C++ can improve C++ <-> Rust interop, because Safe C++ can express some semantics Rust can understand. Right now, interop works but isn't very nice. Basically, I want a variety of approaches, not a Rust monoculture.
  • nicoburns 2y ago
    > But not everyone is interested in introducing a second toolchain, for example. Not that this invalidates your broader point about Safe C++, but this particular issue could also be solved by Rust shipping clang / a frontend that can also compile C and C++.
    • steveklabnik 2y ago
      I have long thought that rust needs to copy Zig here but nobody seems to want to do it, so…
      • anp 2y ago
        I’ve often joked that rustup with a little buildscript copy/paste to use the cc crate could be the fastest way to set up a C++ toolchain and project on lots of systems, but I also haven’t received much enthusiasm on the topic from people involved more with upstream.
        • citelao 2y ago
          I did that yesterday with a project: I took a Rust package that compiled a C project, then had the Rust project generate a C-compatible DLL that I could consume in dotnet. It was so much easier (for me; I am bad at build systems) that I plan to do that for future projects. There’s just something about `cargo run`…
      • evntdrvn 2y ago
        how about just having rustup bundle zig as part of its tooling… It would make getting Rust going on Windows ten times easier, among a bunch of other benefits.
      • sitkack 2y ago
        pip install rust Would be awesome!
    • estebank 2y ago
      On the one hand, I think that it would be a winning strategy. On the other, that effectively turns C++ part of the Rust language. And that is even before looking at the need to extend the Rust compiler to express things that the Rust language doesn't have/need but C++ does, like move constructors.
      • gauge_field 2y ago
        I am not sure if you understand the parent correctly (or I understand your reply). They mean shipping a different C/C+ frontend (e.g. Clang) together with Rust, which does not require any change in Rust frontend
      • steveklabnik 2y ago
        I don’t see how it would make C++ part of the language. Nothing in the Rust front end would need to know about C++. It’s a sub command that would passthrough clang. If you were worried about clang flag stability not being as stable as Rust, you could also include clang as part of llvm-tools. This would add an extra step to set up, but is still easier than today. Of course, in both cases there’s still the work of having rust up (or rustc, depending on the strategy) set up the sysroot. I’m not saying this is trivial to do, but it would make cross compilation so much better than today, and bring rust to parity with Zig and Go on this front.
    • gpderetta 2y ago
      Having Rust directly import C++ would be excellent, but you still need to assign semantics to non-annotated C++ to safely reflect it in safe Rust. You could import it as unsafe rust, but it would be quite gnarly.
• tptacek 2y ago
  This is a thread about a C++ language feature; it's probably most productive for us to stipulate for this thread that C++ will continue to exist. Practical lessons C++ can learn moving forward from Rust are a good reason to talk about Rust; "C++ should not be improved for safety because code can be rewritten in Rust" is less useful.
  • wyager 2y ago
    Actually, this subthread is about whether this is a "really important project"
    • tptacek 2y ago
      to the C++ language
  • pjmlp 2y ago
    Especially because many of us security minded folks do reach out for C++ as there are domains where it is the only sane option (I don't consider C a sane alternative), so anything that improves C++ safety is very much welcomed. Improved C++'s safety means that the C++ code underlying several JVM implementations, CLR, V8, GCC and LLVM, CUDA, Unreal, Godot, Unity,... also gets a way to be improved, without a full rewrite, which while possible might not be economically feasible.
• SubjectToChange 2y ago
  Things like web browsers will continue to have millions of lines of C++ code regardless of how successful Rust becomes. It would be a huge improvement for everyone if such projects had a tractable path towards memory safety
  • wyager 2y ago
    As this article discusses, it's not really viable that existing codebases will be able to benefit from safe C++ research without massive rewrites anyway
    • SubjectToChange 2y ago
      Yes, absolutely. But it is still easier and more practical for those codebases to write new functionality in a Safe C++ dialect than it would be to use Rust.
• akira2501 2y ago
  Cool. Do you mind if we have more than one approach?
  • wyager 2y ago
    Yeah, it does not matter to me, but that wasn't what we were talking about
• alilleybrinker 2y ago
  Not everything will be rewritten in Rust. I've broken down the arguments for why this is, and why it's a good thing, elsewhere [1]. Google's recent analysis on their own experiences transitioning toward memory safety provide even more evidence that you don't need to fully transition to get strong safety benefits. They incentivized moving new code to memory safe languages, and continued working to actively assure the existing memory unsafe code they had. In practice, they found that vulnerability density in a stable codebase decays exponentially as you continue to fix bugs. So you can reap the benefits of built-in memory safety for new code while driving down latent memory unsafety in existing code to great effect. [2] [1]: https://www.alilleybrinker.com/blog/cpp-must-become-safer/ https://www.alilleybrinker.com/blog/cpp-must-become-safer/ [2]: https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...
  • wyager 2y ago
    > Not everything will be rewritten in Rust. Yeah, but it's also not going to be rewritten in safe C++.
    • alilleybrinker 2y ago
      There’s likely some amount of code which would not be rewritten into Rust but which would be rewritten into safe C++. Migrating to a whole new language is a much bigger lift than updating the compiler you’re already using and then modifying code to use things the newer compiler supports. Projects do the latter all the time.
    • pavon 2y ago
      Why not? C++ has evolved over the years, and every C++ project I have worked on, we've adopted new features that make the language safer or clearer as they are supported by the compilers we target. It doesn't get applied to the entire codebase overnight, but all new code uses these features, refactors adopt them as much as possible, and classes of bugs found by static code scanning cause them to be adopted sprinkled through the rest of the code. Our C++ software is more stable than it has ever been because of it. Meanwhile, throwing everything away and rewriting it from scratch in another language has never been an option for any of those projects. Furthermore, even when there has been interest and buy-in to incrementally move to Rust in principle, in practice most of the time we evaluate using Rust for new features, the amount of existing code it must touch and the difficulty integrating Rust and C++ meant that we usually ended up using C++ instead. If features of Circle C++ were standardized, or at least stabilized with wider support, we would certainly start adopting them as well.
• School-Cotton 2y ago
  For new projects on mainstream architectures that don't have to depend on legacy C++ baggage, Rust is great (and, I think, practically always the better choice). But, realistically, C++ will survive for as long as global technological civilization does. There are still people out there maintaining Fortran codebases. (also, IDK if you already realized this, but it's funny that the person you're replying to is one of the most famous Rust boosters out there, in fact probably the most famous, at least on HN).
  • steveklabnik 2y ago
    I have realized this. Sean and I have talked about it. I became a Rust fan because of its innovations in the space. That its innovations may spread elsewhere is a good thing, not a bad thing. If a language comes along that speaks to me more than Rust does, I’ll switch to that. I’m not a partisan, even if it may feel that way from the outside.
    • pjmlp 2y ago
      Indeed, even if Rust disappeared tomorrow, I would assert that its biggest contribution has been to make affine type systems more understanable in mainstream, to the point several languages, including a few with automatic memory management, are adding such concepts to their type systems without having their communities running away in horror, rather embracing the experiment.
• jmull 2y ago
  > It seems to me like we already have a lower-overhead approach ... Rust Rewriting all the existing C++ code in Rust is extremely high-cost. Practically speaking, that means it won't happen in many, many cases. I think we want to find a more efficient way to achieve memory safety in C++. Not to mention, Rust's safety model isn't that great. It does memory safety, which is good, but it's overly restrictive, disallowing various safe patterns. I suspect there are better safe alternatives out there for most cases, or at least could be. It would make sense to consider the alternatives before anyone rewrites something in Rust.
  • steveklabnik 2y ago
    Folks who want to propose alternatives should do so! Right now, you’ve only got the two: profiles and Safe C++. There are also two that aren’t proposals. It have a semblance of a plan: “graft Hylo semantics instead of Rust semantics” and “scpptool.” Realistically, unless something else concrete and not “could be” is found at the eleventh hour, this is the reality of the possible choices.
    • jmull 2y ago
      Don't forget the comment above proposes another alternative, "rewrite it in Rust". The problem with such a proposal is that the cost is impossibly high for many, many cases. Effectively, across the entire existing C++ code base, you get "X% rewrite it in Rust plus (1-X)% do nothing at all", where X is probably a lot closer to 0 than 1. If your goal is to address as many vulnerabilities as possible, you might want to look for a better plan. I don't have a ready plan, but the general approach of incrementally improving the safety of existing C++ seems likely to be more effective than rewrites to me -- it could let the X in my formula move a lot closer to 1. Possibly one of the existing mechanisms for this is already better than "RIIR". Edit, I meant to add: For many, many things it's not the eleventh hour. For a lot of existing C++ code, no one has reached a final decision point. Many haven't really started at all and are at the 0th hour.
  • zozbot234 2y ago
    > It does memory safety, which is good, but it's overly restrictive, disallowing various safe patterns The "safe" patterns Rust disallows tend to not account for safe modularity - as in, they impose complex, hard-to-verify requirements on outside code if "safety" is to be preserved. This kind of thing is essentially what the "unsafe" feature in Rust is intended to address.