I don’t like that “C++ isn’t memory safe”. It is. Users of that language are usually just not experienced or educated enough and therefore more mistakes happen.
I agree though, that other languages like Rust or Java can make it easier to prevent such mistakes.
In my experience, using smart pointers alone already solves 90% of memory issues I have to deal with. C++ improved a lot in that regard over the decades.
I’m very experienced with C++and I still feel like I’m juggling chainsaws every time I use it. And I’ve personally run into into things like use after free errors while working in Chromium. It’s a massive codebase full of multithreading, callbacks, and nonlocal effects. Managing memory may be easy in a simple codebase but it’s a nightmare in Chromium. Tools like AddressSanitizer are a routine part of Chrome development for exactly that reason. And people who think memory management is easy in C++ are precisely the people I expect to introduce a lot of bugs.
I agree that experienced users can write code that leaks less than in C, leaving aside the bottomless pit of despair that is undefined behaviour. But the the language isn’t memory safe, it doesn’t even prevent you from returning a reference to a local or helpnwitg iterator invalidation. you don’t have to jump through any hoops to enable making that mistake.
If a language prevents you from doing stuff like that, this always comes at a cost, since it has to do the work for you, almost always. This is additional overhead you can get rid of in C++ and therefore gain a lot of performance. But that again comes with more responsibility on the developer’s side and you might need to implement appropriate checks yourself where needed.
Rust prevents the things mentioned above in the compiler; there is no runtime cost for most of Rust’s safety measures. There is definitely a build time cost though.
You can unsafe your way around anything, but that’s on the dev.
I’m not just talking about performance costs.
For example, compared to C++, Rust comes with reduced flexibility and increased complexity in certain cases.
The borrow checker, for example, imposes strict ownership and lifetime rules, which can be difficult to work with, especially in complex data structures or when interfacing with existing systems. Sometimes, you have to significantly refactor your code just to satisfy these constraints, even when you know the code would be safe in practice. This can slow down development, require more boilerplate, and make certain patterns harder to express.
C++ gives developers more freedom but expects them to take responsibility. That tradeoff isn’t just about raw performance; it’s also about how much control and convenience the developer has.
You said performance, so I responded to that. You can dislike Rust, that’s fine, but a lot of the things you’re saying aren’t correct. C++ isn’t memory safe, the person responding before showed that pretty easily. Rust doesn’t perform slower than C++, I responded to that claim. Rust provides tools to be memory safe, but the existence of unsafe I’d argue makes it also not memory safe, but at least better than C/C++. It also has tons of undefined behavior, just like those two.
As for the personal opinion; you don’t have to like Rust. I actually have a very different view of the borrow checker and I don’t think I’ve ever “fought” it in a time when I was also doing something inherently safe. Every time I’ve had an issue with satisfying the borrow checker, which is rare, it’s been because I was doing something unsafe or interacting with C code, which Rust would argue is also unsafe. In my experience, it really eases the burden of programming actually and it makes debugging easier. It also makes design easier. As an example, I’ve been working on a very large C project recently and I ran into a bug where I was getting the wrong data printed out when I checked a value. After looking into it for like 15 minutes, I finally figured out that I had accidentally passed a stack pointer to a function that I wrote expecting a heap pointer. When the function went out of scope the data was garbage, but there was no crash and no compiler error. The borrow checker would have helpfully stopped me in my tracks there and saved that 15 minutes of debugging. The fact that it’s hard to implement your own efficient linked list or vector type has never been a problem for me really, especially not in comparison to the gains of not always having to keep ownership and lifetimes of pointers in my own head or in documentation that may go stale. I can’t express enough how helpful that is to my programming experience. C puts the burden of pointer lifetimes and ownership entirely on the developer. C++ makes that a bit better with the smart pointers at least, but those have some rules that aren’t enforced by the compiler but instead by convention.
Basically I find the phrase “fighting the borrow checker” to be shorthand for “I can’t write C or C++ in Rust and I want to”. They’re not the same language and the constructs are different
I don’t like that “C++ isn’t memory safe”. It is. Users of that language are usually just not experienced or educated enough and therefore more mistakes happen.
I agree though, that other languages like Rust or Java can make it easier to prevent such mistakes.
In my experience, using smart pointers alone already solves 90% of memory issues I have to deal with. C++ improved a lot in that regard over the decades.
I’m very experienced with C++and I still feel like I’m juggling chainsaws every time I use it. And I’ve personally run into into things like use after free errors while working in Chromium. It’s a massive codebase full of multithreading, callbacks, and nonlocal effects. Managing memory may be easy in a simple codebase but it’s a nightmare in Chromium. Tools like AddressSanitizer are a routine part of Chrome development for exactly that reason. And people who think memory management is easy in C++ are precisely the people I expect to introduce a lot of bugs.
I agree that experienced users can write code that leaks less than in C, leaving aside the bottomless pit of despair that is undefined behaviour. But the the language isn’t memory safe, it doesn’t even prevent you from returning a reference to a local or helpnwitg iterator invalidation. you don’t have to jump through any hoops to enable making that mistake.
If a language prevents you from doing stuff like that, this always comes at a cost, since it has to do the work for you, almost always. This is additional overhead you can get rid of in C++ and therefore gain a lot of performance. But that again comes with more responsibility on the developer’s side and you might need to implement appropriate checks yourself where needed.
Rust prevents the things mentioned above in the compiler; there is no runtime cost for most of Rust’s safety measures. There is definitely a build time cost though.
You can unsafe your way around anything, but that’s on the dev.
I’m not just talking about performance costs. For example, compared to C++, Rust comes with reduced flexibility and increased complexity in certain cases.
The borrow checker, for example, imposes strict ownership and lifetime rules, which can be difficult to work with, especially in complex data structures or when interfacing with existing systems. Sometimes, you have to significantly refactor your code just to satisfy these constraints, even when you know the code would be safe in practice. This can slow down development, require more boilerplate, and make certain patterns harder to express.
C++ gives developers more freedom but expects them to take responsibility. That tradeoff isn’t just about raw performance; it’s also about how much control and convenience the developer has.
You said performance, so I responded to that. You can dislike Rust, that’s fine, but a lot of the things you’re saying aren’t correct. C++ isn’t memory safe, the person responding before showed that pretty easily. Rust doesn’t perform slower than C++, I responded to that claim. Rust provides tools to be memory safe, but the existence of
unsafeI’d argue makes it also not memory safe, but at least better than C/C++. It also has tons of undefined behavior, just like those two.As for the personal opinion; you don’t have to like Rust. I actually have a very different view of the borrow checker and I don’t think I’ve ever “fought” it in a time when I was also doing something inherently safe. Every time I’ve had an issue with satisfying the borrow checker, which is rare, it’s been because I was doing something unsafe or interacting with C code, which Rust would argue is also unsafe. In my experience, it really eases the burden of programming actually and it makes debugging easier. It also makes design easier. As an example, I’ve been working on a very large C project recently and I ran into a bug where I was getting the wrong data printed out when I checked a value. After looking into it for like 15 minutes, I finally figured out that I had accidentally passed a stack pointer to a function that I wrote expecting a heap pointer. When the function went out of scope the data was garbage, but there was no crash and no compiler error. The borrow checker would have helpfully stopped me in my tracks there and saved that 15 minutes of debugging. The fact that it’s hard to implement your own efficient linked list or vector type has never been a problem for me really, especially not in comparison to the gains of not always having to keep ownership and lifetimes of pointers in my own head or in documentation that may go stale. I can’t express enough how helpful that is to my programming experience. C puts the burden of pointer lifetimes and ownership entirely on the developer. C++ makes that a bit better with the smart pointers at least, but those have some rules that aren’t enforced by the compiler but instead by convention.
Basically I find the phrase “fighting the borrow checker” to be shorthand for “I can’t write C or C++ in Rust and I want to”. They’re not the same language and the constructs are different
Every source I’ve seen has shown rust and c++ to be very similar in terms of performance.
It’s not just about runtime performance, but also about coding flexibility, and for example also reduction of boilerplate.
The good news is that the browser comes from Serenity OS which means it probably is lightweight and well written.