Posted by charles_irl 8 hours ago
Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon.
The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen minute bagpipe dirge your lead single it doesn't really matter whether you use the colored vinyl.
Profiles and sanitizers just aren't sufficient.
I think there are plenty of people that must use C++ due to legacy, management or library reasons and they care about safety. But those people aren't going to join language committees.
These include:
1. bounds checked arrays (you can still use raw pointers instead if you like)
2. default initialization
3. static checks for escaping pointers
4. optional use of pure functions
5. transitive const and immutable qualifiers
6. ranges based on slices rather than pointer pairs
Can you be very specific about why?
Here's the argument for why profiles might work: with all of the profiles enabled, you are only allowed to use the safe subset of C++ and all of the unsafe stuff is hidden behind APIs whose implementations don't have those profiles enabled. Those projects that enable all profiles by default effectively get Swift-like or Rust-like protection.
Like, you could force all array operations to use C++ stdlib primitives, enable full hardening of the stdlib, and then have bounds safety.
And you could force all lifetime operations to use C++ stdlib refcounting primitives, and then have lifetime safety in a Swift-like way (i.e. eager refcounting everywhere).
I can imagine how this falls over but then it might just be a matter of engineering to make it not fall over.
(I'm playing devils advocate a bit since I prefer Fil-C++.)
Instead, for example, the lifetime safety profile (https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...) is a Rust-like compile time borrow checker that relies on annotations like [[clang::lifetimebound]], yet they also repeatedly insist that profiles will not require this kind of annotation (see the papers linked from https://www.circle-lang.org/draft-profiles.html#abstract).
Their messaging is just not consistent with the concrete proposals they have described, let alone actually implemented.
Firstly, you need composition. Rust's safety composes. The safe Rust library for farm animals from Geoff, the safe Rust library for cooking recipes by Alice and the safe Rust library for web server by Bert together with my safe program code adds up to my safe Rust farm foods web site.
By having N profiles, where N is intended to be at least five and might grow arbitrarily and be user extensible, C++ guarantees it cannot deliver composition this way.
Maybe they can define some sort of composition and maybe everybody will ship software which conforms to that definition and so eventually they get composition, that's not there today, so it's just a giant unknown at best.
Secondly, of the profiles described so far, most of them are just solving parts of the single overarching problem Rust addresses, for the serial case. So if they ship that, which already involves some amount of new work yet to be finished, you need all of those profiles to get to only partial memory safety.
Which comes to the third part. Once you start down this path, as they found, you realise you actually want a borrowck. You won't call it that of course, because that would be embarrassing. But you'll need to track reference lifetimes and you'll need annotation and you end up building most of the stuff you insisted you didn't want. For now, you can handwave, this is an unsolved static analysis problem. Well, not so much unsolved as you know the solution and you don't like it.
Your idea to do the reference counting everywhere is not something WG21 has looked at, I think the perf cost is sufficiently bad that they won't even glance at it. They're also not going to ship a GC.
Finally though, C++ is a concurrent language. It has a whole memory model which doesn't even make sense if you aren't thinking about concurrency. But to deliver concurrent memory safety without Fil-C's overheads you would want... well, Rust's Send and Sync traits, which sure enough have eerie twins in the Safe C++ proposal. No attempt to solve this is even hinted at in the current profiles proposal, and they would need to work one out and if it's not Send + Sync again they'd need to prove it is correct.
> Which comes to the third part. Once you start down this path, as they found, you realise you actually want a borrowck.
That's a bold statement. It might be true for some very loose definition of "borrow checker". See the super simple static analysis that WebKit uses (that presentation is now linked in at least two places on this HN discussion, so I won't link it again).
> Your idea to do the reference counting everywhere is not something WG21 has looked at, I think the perf cost is sufficiently bad that they won't even glance at it. They're also not going to ship a GC.
The point isn't to have ref counting on every pointer at the language level, but rather: if your prevent folks from calling `delete` directly (as one of the profiles does) then you're effectively forcing folks to use smart pointers.
Reference counting that happens by smart pointers is something that they would ship. We know this because it's already happened.
I imagine this would really mean that some references are ref counted (if you use shared_ptr or similar) while other references use some other policy.
> Finally though, C++ is a concurrent language. It has a whole memory model which doesn't even make sense if you aren't thinking about concurrency. But to deliver concurrent memory safety without Fil-C's overheads you would want... well, Rust's Send and Sync traits
Yeah, this might be an area where they leave a hole. Like, you might have reference counting that is only partially thread safe:
- The refcount of any object is atomic.
- The smart pointer itself is racy. So, racing on pointers can pop the protections.
If they got that far, then that wouldn't be so bad. The marginal safety advantage of Rust would be very slim at that point.
This is not the goal of profiles. It’s to be “good enough.” Guaranteed safety isn’t in the cards.
- Rust isn’t totally guaranteed safe since folks can and do use unsafe code.
- Exact same situation in Swift
- Go has escape hatches like it you race, but not only.
So most “safe” things are really “safe enough” for some definition of “enough”.
Profiles do not, even for code that is 100% using profiles, guarantee safety.
So, no matter what safe language we talk about, "safety" always has its caveats.
Can you be specific about what missing safety feature of profiles leads you to be so negative about them?
An entire program ported to Rust will call into unsafe APIs in at least a few places, somewhere down the call stacks.
But you'll still have swathes of code that doesn't ultimately end up calling an unsafe API, which can be trivially considered memory safe.
It’s not about specifics, it’s about the stated goals of profiles. They do not claim to prove memory safety even with all of them turned on.
Rust does a pretty good job formalizing what the safety guarantees are and when you can assume them. Other languages don't, but they also don't support safety concepts that C++ nominally does like safety critical systems. "Good enough" can be perfectly fine for a web service like Go while being grossly inadequate for HPC or safety critical.
And C++ code simply doesn't have the necessary info to make safety decisions. Sean explains it better than I can https://www.circle-lang.org/draft-profiles.html
E.g., the first case is "Inferring aliasing". He presents some examples and states, "The compiler cannot infer a function’s aliasing requirements from its declaration or even from its definition."
But why not?
The aliasing requirements come directly from vector. If the compiler has those then determining the aliasing requirements of those functions is straightforward.
Now, maybe there is some argument that a C++ compiler cannot determine the aliasing requirements of vector, but if that's the claim, then the paper should make it, and back it up.
The paper continues in the same vein in the next section, as if the lifetime requirements of map and min cannot be known or cannot bubble up through the functions that call them.
As written, the paper says almost nothing about the feasibility of static analysis of C++ to achieve safety goals for C++.
For example, given a deceleration
int* func(int* a);
Trying to solve this without recursively analysing a whole program at once is infeasible.
Rust's approach was to require more information to be provided by function definitions, but that's new syntax, and not backwards compatible, so not a palatable option for C++.
That's going to be a non-starter for 99% of serious C++ projects there. The performance hit is going to be way too large.
For bounds checking, sure I think the performance penalty is so small that it can be done.
Depends on how many times it's inlined and/or if it's in hot code. It can result in much worse assembly code.
Funny thing: C++17 string_view::substr has bound check + exception throw, whereas span::subspan has neither; I can see substr's approach being problematic performance- and code-size-wise if called many times yet being validated by caller.
See https://www.youtube.com/watch?v=RLw13wLM5Ko
Note that they also allowed other kinds of pointers so long as their use could be statically verified using very simple rules.
And then CISA suggested that "maybe we should stop using memory-unsafe languages." And this has some of the C++ committee utterly terrified; they need something that lets them tell the government that C++, today, is memory-safe. That thing is C++ profiles. It's not about actually making C++ memory-safe, it's about being able to check the box that C++ is memory-safe, and this is so important it needs to be voted into the standards yesterday and why are you guys saying mean things about C++ profiles...
C++ profiles is a magic solution to the problem. As one committee member noted, there's not enough description of profiles yet to even figure out if it can be implemented or not. Instead, it's just a vague, well, compile with -fsanitize=address, compile with fortify-source, use hardened malloc, that makes my code memory-safe, right? And for as long as profiles remains a magic solution to check a box, it will remain vaporware in practice.
One of the real risks I see in the C++ committee is that they seem to want to drive all of the implementers out of the room.
True. So many proposals have gone by over the years. Here's one of mine from 2001.[1] Bad idea. The layers of cruft in C++ have become so deep that it's a career just to understand them.
DARPA has something called the TRACTOR program, "Translate All C to Rust". It's been underway for a year, and they have a consortium of universities working on it. Not much, if anything, has come out. Disappointing.
Rust is probably too hard. I write 100% safe Rust, and there are times when I hit an ownership structure wall and have to spend several days re-planning. So far I've always succeeded without using "unsafe" or indices, but it drags down productivity.
Although object-oriented programming is out of fashion, classes with inheritance are useful. It's really hard to do something comparable in Rust. Traits are not that helpful for this.
Go is a good compromise. Safety at a minor cost in performance. Go is good enough for web back end stuff. Go has both GC and "green threads". This automates the problems that wear people down in C++ and Rust.
[1] https://www.animats.com/papers/languages/cppstrictpointers.h...
There is a common perception that Rust is less productive than competing languages, but empirical research by Google and others has found this to be wrong. Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower. You may spend a few hours struggling with the borrow checker, but that saves you countless days of debugging highly non-trivial defects, especially in a larger codebase.
> Although object-oriented programming is out of fashion, classes with inheritance are useful. It's really hard to do something comparable in Rust. Traits are not that helpful for this.
FWIW, "classes with inheritance" in Rust can be very elegantly modeled with generic typestate. (Traits are used as part of this pattern, but are not the full story.) It might look clunky at first glance, but it accurately reflects the underlying semantics.
I really don’t understand this perspective. The whole philosophy of Rust is one where you document why “unsafe” is safe. It is not and never has been a goal to make everything safe because that is an impossible goal to merge with high performance systems language because hardware itself is unsafe. It’s why the unsafe keyword exists. If that wasn’t the goal, unsafe wouldn’t.
You shouldn’t go out of your way to use unsafe, but between that and 2 weeks refactoring, I’ll take the unsafe and use tools like miri or ASAN to provide extra guards. Engineering is inherently about making practical choices.
And if you want to write like D...
Profiles cannot achieve the same level of safety as Rust and it's obvious to anyone who breathes. Profiles just delete stuff from the language. Without lifetimes reified as types you can't express semantics with precision enough to check them. The moment string_view appears, you're horked.
Okay, so you ban all uncounted reference types too. Now what you're left with isn't shit Rust but instead shit Swift, one that combines the performance of a turtle with the ergonomics of a porcupine.
There's no value in making things a little bit safer here and there. The purpose of a type system is to embed proofs about invariants. If your system doesn't actually prove the the invariant, you can't rely on it and you've made is a shitty linter.
Continue the safe C++ work outside the context of the C++ standards committee. Its members, if you ignore their words and focus on the behaviors, would rather see the language become irrelevant than change decades old practices. Typical iron law of bureaucracy territory.
With C++, my impression is that most implementers simply aren't interested. And, conversely, most people who might be interested enough to roll a new implementation have already moved to Rust and make better use of their time improving that.
There are lots of cool innovations C++ made that will just disappear from the Earth, forever, if C++ can't be made memory safe in the same sense Rust is. I mean, Rust doesn't even support template specialization.
I don't think it's too late for someone to fork both C++ and Clang and make something that's actually a good synthesis of the old and the new.
But yeah, the most likely future is one on which C++ goes the way of Fortran (which still gets regular updates, however irrelevant) and the energy goes into Rust. But I like to rage, rage, against the dying of the type based metaprogramming.
People have tried variants of this already: Carbon, for example. I don’t think anyone outside of Google uses it, though, and even within Google I suspect it’s dwarfed by regular C++.
I don’t think C++ will become irrelevant for a long time. Recent standards have added some cool new features (like std::expected), and personally I feel like the language is better than ever (a biased opinion obviously).
Memory management is still a huge elephant in the room, but I don’t think it’s becoming irrelevant.
This doesn't mean that it's not possible to achieve a safe subset of C++ that supports template specialization, but it suggests that we aren't going to see it any time soon.
Not that long ago tsoding was like "I should learn Fortran" and wrote a bunch of Fortran. Obviously from his perspective some things about Fortran are awful because it's very old, but it wasn't somehow impossible to do.
There are a few really amazing things which have been achieved in C++ like fmt, a compile time checked, userspace library for arbitrarily formatting variadic generic parameters. That's like man on the moon stuff, genuinely impressive. Mostly though C++ is a garbage fire and so while it's important to learn about it and from it we should not keep doing that.
Anecdotal, but that's hardly unique to C++. So even if C++ were to disappear overnight (which we all agree won't happen), this wouldn't be a burning-library-of-Alexandria moment.
To me the things which come to mind are either compiler magic (e.g. C printf) or they rely on RTTI (e.g. Odin and similar C-like languages) and neither of those is what fmt does, they're "cheating" in some sense that actually matters.
Great! What are you waiting for?
If you try to answer that question, you'll also find why other similar projects are not finding much traction yet.
So the claim is that the scpptool approach[1] can, while remaining closer to traditional C++, and not requiring the introduction of new language elements. Since the scpptool-enforced safe subset of C++ is an actual subset of C++, conforming code continues to build with your existing compiler. It just uses an additional static analyzer to check conformance.
For the 90% or whatever of C++ code that is not actually performance sensitive, the associated SaferCPlusPlus library provides drop-in and "one-to-one" safe replacements for unsafe C++ elements (like standard library containers and raw pointers). (For example, if you're worried about potentially invalid vector iterators, you can just replace your std::vector<>s with mse::mstd::vector<>s.) With these elements, most of the safety is enforced in the type system and not reliant on the static analyzer.
Conforming implementations of performance-sensitive code would be more restricted and more reliant on the static analyzer for safety enforcement. And sometimes requires the use of library elements, like "borrowing objects", which may not have analogies in traditional C++. But overall, even high-performance conforming code remains very recognizable C++.
The claim is that the scpptool approach is a straightforward path to full memory (and data race) safety for C++, and the one that requires the least code migration effort. (And again, as an actual subset of existing C++, not technically dependent on standard committees or compiler vendors for its implementation or deployment.)
[1]: https://github.com/duneroadrunner/scpptool/blob/master/appro...
From "The state of Rust trying to catch up with Ada [video]" https://news.ycombinator.com/item?id=43007013 :
> [awesome-safety-critical]
> rustfoundation/safety-critical-rust-consortium: https://github.com/rustfoundation/safety-critical-rust-conso...
You need to take off the "inherently unsafe" C root from C++, but it wouldn't be called C++ anymore by that point.
For example, their tooling prevents code like this:
if (m_weakMember) { m_weakMember->doThing(); }
if (RefPtr strongLocal = m_weakMember.get()) { strongLocal->doThing(); }
My interpretation of Geoff's presentation is that some version of profiles might work, at least in the sense of making it possible to write C++ code that is substantially safer than what we have today.
The most hopeful thing I saw in Geoff's talk was cultural. It sounds like Geoff's team wanted to get to safer code. Things went faster than expected, people landed "me too" unsolicited patches, that sort of thing. Of course this is self-reported, but assuming Geoff wasn't showing us a very flattering portrait of a grim reality, which I can't see any incentive for, this team sounds like while they'd get value from Rust they're delivering many of the same security benefits in C++ anyway.
Bureaucrats don't like culture because it's hard to measure. "Make sure you hire programmers with a good culture" is hard to chart. You're probably going to end up running some awful quiz your team hates "Answer D, A, B, B, E, B to get 100%". Whereas "Use Rust not C++" is measurable, team A has 93% of code in Rust, but team B scored 94.5% so that's more Rust, they win.
That's not true at all.
- The bounds safety part of it prevents those C operations that Fil-C or something like it would dynamically check. You can to use hardened API instead.
- The cast safety part of it prevents C casts except if they're obviously safe.
- The lifetime safety part of it forces you to use WebKit's smart pointers except when you have an overlooking root.
Those are type safety rules. It's disingenuous to call them heuristics.
It is true, however, that Geoff's rules don't go to 100% because:
- There are nasty corners of C that aren't covered by any of those rules.
- WebKit still has <10% ish code that isn't opted into those rules.
- WebKit has JITs.
You could compile your program with address sanitizer then it at least crashes in a defined way at runtime when memory corruption would happen. TCC (tiny C compiler initially written by fabrice bellard) also has such a feature I think.
This of course makes it significantly slower.
You’d possibly just be trading one problem for another though - ask anyone who’s had to debug a shared ownership issue.
What infuriates me about the C++ safety situation is that C++ is by and large a better, more expressive language than Rust is, particularly with respect to compile time type level metaprogramming. And I am being walked hands handcuffed behind my back, alongside everyone else, into the Rust world with its comparatively anemic proc macro shit because the C++ committee can't be bothered to care about memory safety.
Because of the C++ standards committee's misfeasance, I'm going to have to live in a world where I don't get to use some of my favorite programming techniques.
To be more precise, it's old Python. Recent versions of Python use a gc.
> And I am being walked hands handcuffed behind my back, alongside everyone else, into the Rust world with its comparatively anemic proc macro shit because the C++ committee can't be bothered to care about memory safety.
Out of curiosity (as someone working on static analysis), what properties would you like your compiler to check?
Have you worked much with SAL and MIDL from Microsoft? Using SAL (an aesthetically hideous but conceptually beautiful macro based gradual typing system for C and C++) overlay guarantees about not only reference safety but also sign comparison restriction, maximum buffer sizes, and so on.
But first: we need to take step-zero and introduce a type "r64": a "f64" that is not nan/inf.
Rust has its uint-thats-not-zero - why not the same for floating point numbers??
Why do we need to single out a specific value. It would be way better if we also could use uint-without-5-and-42. What I would wish for is type attributes that really belong to the type.
typedef unsigned int __attribute__ ((constraint (X != 5 && X != 42))) my_type;