It's the normal compilation flag for performant code.

The word "danger" is scary, but it's simply disabling debugging code: debug assertions, full stacktraces, extra safety checks.

I suppose the makers of Nim named that flag for a reason - giving up memory safety by disabling bounds/overflow checks should be never be the default for networked software in a production setting, so benchmarking in that mode would paint an unrealistic picture.

What you want are comparable compiler flags across languages, say "optimized for performance, yet retaining safety" and "go as fast as possible and disable all brakes". Which, to be fair, is the default for C anyway, but this is not a desirable default. I'm sure you can similarly game Rust bechmarks by using "unsafe".

"disable all brakes" is misleading. All the basic memory safety stays, static typing is still there, non-debug assertions are still checked.

Removing debugging features is reasonable for such benchmarks, especially if comparing with languages that don't have them.

Another poster claimed it disables bounds checks, you claim it still offers basic memory safety. That sounds like a contradiction to me.

I'm sure Rust also has a way to disable bounds/overflow checks for speed. Do benchmarks utilise it?

Rust doesn’t have a compiler flag for this, instead it has separate functions that don’t do the checking. E.g. Vec has a .get_unchecked function.

Such functions can only be used in an unsafe block, and should only be used if bounds checking is handled elsewhere such that it would be impossible to cause an out of bounds error at runtime.

It’s also often possible to get rust to elide bounds checks by using iterators, which often don’t need them as they know the length up front.

Rust should be able to elide more checks than most other languages without impacting safety.

That's the assumption, but that doesn't mean it's the case. Certainly bounds checks are impossible to prove at compile-time.

What language are you talking about?

leaving (e.g.)runtime overflow checks turned on in the Nim code would not be a realistic comparison against C

If you're going into production with Nim code and execution speed is a top concern, you're probably going to remove all the safety belts after thoroughly testing, valgrind'ing, etc., i.e. you're probably going to opt for -d:danger instead of -d:release. But maybe not, depends on the project I guess.