Chess engines and memory safety

I just realized chess engines may be one of the last applications for programming languages that aren't memory safe.

Why? Memory safety inherently requires checks for attempts to read/write out of the program's allocated memory bounds. Unfortunately, this slows down the program.

All else being equal, a faster chess engine is stronger. Memory-safe engines will never be stronger than memory-unsafe engines.

China is rolling out 7nm geometry ... cpu doesn't matter anymore ...

Ok?

And I thought this thread was about the memory safety of humans, which is affected by the use of engines who do all the hard work for you in finding the critical positions, examining every move and highlighting every blunder.
And while engines are super useful to prepare stuff and to get a quick glance at the position, a nice instructor for people analyzing, too much engine-esque play just spoils the fun: Be it cheating, never ending prep, the dubious forest of 2+2=5 which is lit up by the terminators, the potential trap of falling for the engine's approval - only listening to it instead of working on the game, with or without it.
Romantic chess has long gone, but adjournments have only been gone for what? 30 years? That's a fast developement.

Ever heard of rust?

@IndianDefense said in #5:
> Ever heard of rust?

Yes, the red flaky stuff that pains many engineers working with iron.

Fine, for real, we know that assembly is much faster than Rust (well duh). Rust is able to edge out C in terms of performance in some cases, though testing with different C compilers allows the C code to be slightly faster if the fastest compiler is chosen.

Make sure your test C code makes full use of SSE and AVX.

Please do not start a language war. I didn't start this thread with that intention.

@IndianDefense said in #5:
> Ever heard of rust?
Sarcasm, right?