The argument I was given was that memory-safe languages like Rust, Go, etc is that it frees up the d

The argument I was given was that memory-safe languages like Rust, Go, etc is that it frees up the developer to actually concentrate on solving the problem.

Having the language/compiler do bounds checking, Allocation/Deallocation, type safety, etc means that I don't have to, and like most programmers, I am lazy so I'm quite happy for the system to do things for me!

To write 'safe' code in C/C++ is possible - but it means that you need to constantly be aware of what you are doing with your allocations. That can get tiring and at some point something is going to slip through.

One of the dangers I can see is that developers can then get complacent and don't think about their memory management at all - as even in memory safe languages that are going to be some bits that are not memory-safe.

Static and Dynamic Application Security Testing (SAST & DAST) can help but even they are not going to find every issue and even then I have seen them throw up false positives occasionally.

Organisations such as the NSA are advising organisations to move to more memory-safe langauges
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
Was this page helpful?