Now if you're going to attack rust freely, why don't

I go on c++?
According to chrome, 70% of all its bugs are from the smart developers like you that think keeping 2 variables A and B relient on each other is a good idea, because no developer down the line will forget it and mess up
https://www.chromium.org/Home/chromium-security/memory-safety/

Also what about some string manipulations? Or installing a package? Installing a package can't be that hard, right? Wait are you telling me that I just spent 4 hours on writing build scripts and this 2 packages just don't want to work together? Wait companies hire build developers to write the build scripts? What about my app that has huge async nature, it can't be that I have to use OS api and impl everything for every OS, there has to be some lang level runtime, no? Why do I need to write my tests in python? This is the frustration I have always met whenever I worked on c++ projects, and the things rust just does right. Giving all of this benefits to save memcpy that the program spends less then 2% of its lifetime on? This ignores how much I love the rust trait system, and hate c++ oop system, where a class is more a riddle than an API

I think issues like this are in large part because of: * Global allocator * Lack of bounds checks * RAII hiding the details that beginner developers need

Yep, that's my experience with C++ too, it's terrible, I'm not saying that you'd use C++ for everything, just the critical hot path where performance mather

You do realize that this 1 memcpy problem where c++ is smartly preallocating memory at the destination isn't going to make that much of a difference for anything but your carefully crafted example that abuses it to the max?

That's not what the optimization is I think

That's literally what it's: A example() { A value; ..... // func body return A; } If A impl move contrcutor c++ will allow it self to preallocate A at the calling function and avoid memcpy at the return

preallocating stack space for copies is necessary no matter what you do

Ahh right, for return values!

In c++ the function aboves uses the memory from the destination is what I mean by preallocating

yep, makes sense

Why do you think these bugs occur so frequently in C/C++?

I have read some OpenSSL source whenever exploits were found in that codebase, and the only conclusion I can draw from that is that the exploits occur because the codebase is so horrible

Being 70% of all reported bugs sounds frequently, no? And also my personal experience. I don't think I've ever compiled a big and complex program in c++ and it just worked clean of bugs. In rust it's not rare

Did I miss understood this question? I think that trusting people to manage their own memory is just a bad idea. It doesn't work in big projects and fails the test of time. It's also an endless loop, many times fixing a memory problem opens a new one. The rust borrow checker isn't my favorite feature of rust, but it does this amazing job of promising you that if this is "safe rust" (no unsafe keywords), and it compiles, it's clean of them

Why do you think it works in some domains with the same languages? gamedev, aeronautics, embedded, firmware, ...

I think it depends a lot on the strategy people end up picking, and I think traversing structures to individually free many small allocations is a terrible way to do it

In what aspect? For firmware I'd always choose c/c++. This environment is naturally unsafe, you won't get a better expeirence with rust, in fact quite the opposite, would be forced to put unsafe all over the code and fight the compiler for the things neither of you can guarntee but just have to believe is the case. It does seem like some enthusiastics are working hard to build a better rust environment for this, claiming rust async system fit very naturally embedded systems and can prevent the need for a RT OS https://embassy.dev/. I haven't tried myself but I'm hopeful. Gamedevs don't give a shit. It'll take bevy years to reach the scale of something like unreal, but gamedevs wouldn't bother anywhy. They wouldn't learn to design their games in a safer way, and they don't want to fight the compiler. Gamedevs will even abuse UB if it works. Who loses from a vuln in games either way? It's not like the game runs on their machine, and if it crashes the player will just start the game again

This is also a great point. Gamedevs are excellent at doing this, in fact they're so good at pre-allocating huge mem areas they'll allocate much more than needed if it means simpler code, and it actually works to prevent bugs that would be critical (as oppose to vuln that need to be exploited)

I have no hope for Rust async + embedded lol, but what I mean is; why do you think memory safety bugs are much fewer in C/C++ in embedded and games?

Also works with the OS since memory is used in a linear fashion most of the time, so it's easy for the OS to conserve physical memory if the game doesn't use everything

They aren't, they just not as issue as compared to, idk, a server that serves millions of users that can freely exploit its vulnerabilities

They really are fewer

Ye, it's a great approach that solves many problems and gamedevs abuse it to the limit

Maybe for gamedev the answer is very simple