@fzrg \- you are overinterpreting benchmarks (which in the Nim versions are written by Nim beginners and/or poorly optimized) and also ignoring caveats and details in the very pages you yourself link to -- all toward the result of coming to inappropriately strong conclusions, repeating yourself, and ignoring rebuttals. While you seem earnest, I don't see how you hope to persuade people here with this trouble.
Rust is not safer as per your own initial comparison link and not safer than formally verified C as per mratsim's rebuttal. Rust is not faster as per Nim can also be "portable assembly" like C & Rust as per [this discussion](https://kornel.ski/rust-c-speed) you posted. [Here is a small, self-contained example](https://forum.nim-lang.org/t/6920#43384) and that thread more broadly discusses problems with at least some Nim code in that kostya benchmark. Most benchmarks are only informative when very cautiously interpreted and most very uncautiously interpreted. Once you allow near assembly-like non-portable code like SIMD intrinsics, which the benchmarks game started doing long ago, all benchmarks reduce to "exercises in patience of contributing devs". Rust people obviously have a lot of patience given how long they wait for compiles..C++ people as well. Based on that population bias of contributing dev people alone, one might expect "in the broad cultural ensemble" of these benchmark competitions to see more "won" by Rust and C++. This is not indicative of language traits in "more real" problem settings and that goes beyond memory & runtime metrics, whether it is how much `unsafe` shows up in Rust code or unsafe constructs in Nim or really anything. This issue is not even unique to measuring computer programs. See [Goodhart's Law](https://en.wikipedia.org/wiki/Goodhart's_law).
