Comment by jandrewrogers
9 months ago
> I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games but they would be for a web site or an enterprise database.
Even for database engines specifically, modern C++ is essentially as safe as Rust and significantly more ergonomic. Rust's safety features can't reason about the case when all of your runtime objects live in explicitly paged memory with indefinite lifetimes and no fixed memory address, which is the norm in database kernels. You have to write the same code to make handling these objects safe and correct in Rust that you have to write in C++. You can't use normal pointers and allocators for this even if you wanted to.
Rust's safety is designed more for normal dynamic memory applications.
> modern C++ is essentially as safe as Rust
This isn't even close to being true. I think memory safety isn't as important for games as it is for most software (though it is still quite important for multiplayer games!). But even if you write the most modern C++ possible I guarantee you are going to spend some of your time debugging segfaults, memory corruption and heisenbugs. Don't try and claim "I don't write bugs". Everyone does.
That assertion was specifically qualified in the context of database engines, for which it is true. I definitely write bugs but I haven't seen a segfault or memory corruption in years. That is more of a C thing than a C++ thing.
It is kind of difficult to have a segfault or memory corruption with explicitly paged object memory, since there can't be any pointers and these complex objects are bound-checked at compile-time. If you care about performance and scalability, you don't need to concern yourself with multi-threading as an issue either. The main way you'd expect to see memory corruption is if you try to read/write a page in the middle of a DMA operation to the same memory, and Rust doesn't help you with that either (though this would be just a normal logic bug in the scheduler).
It is pretty easy to avoid segfaults and memory corruption in modern C++ if the software architecture doesn't allow you to create the conditions under which those are likely to occur.
So you're saying if you write your database engine in C++ you're not going to see any segfaults?
https://jira.mariadb.org/browse/MDEV-14248?jql=text%20~%20%2...
4 replies →
This kind of extends to embedded/low level systems programming as well - the assumption that memory can only change as an effect of program execution just does not hold true there. What's the value of tracking mutability and data ownership when a DMA engine can just decide to overwrite the memory you supposedly have exclusive access to?