[coldtea]

Lots of languages ARE faster than C, including older languages than C, like Fortran and Forth.

Being faster than C is not anything special in itself.

Most things being equal (typed, optimized, compiled, no runtime etc) C is mostly faster when it does something with a lower overhead than some other language (e.g. a specially written hashmap algorithm targeted to some program vs C++ std map type), not because of its primitives being faster.

[protomyth]

Fortran especially. Forth seems to depend on processor characteristics. I seem to remember that Ada compilers routinely produce faster code than C compilers.

[snuxoll]

C has very loose semantics that make it difficult for a compiler to reason about code, as the saying goes, C is often little more than portable assembly. There's a reason that CLion was a big deal when JetBrains announced it, reasoning about C/C++ code is HARD.

[protomyth]

If I wasn't more interested in Agent oriented languages, it might be interesting to see what could be done to design a new language built for performance. I would imagine you'd start with the Ada side of the house and work your way back to more pleasing syntax.

[PeCaN]

Ada and Rust are both significantly easier to perform aliasing analysis on, so frequently you can get much better code. Both languages have slight overhead for bounds checking and such, but you can turn it off (at least in Ada) if it's a problem (hint: it isn't).

Same reason Fortran is fast actually: it just disallows pointer aliasing entirely¹, meaning you get none of the flexibility of C pointers (heck, you don't even have pointers, basically), but if you're multiplying matrices it flies.

¹ I recall newer Fortrans have pointers, but as I'm not a Fortran programmer I don't actually know.

[steveklabnik]

You can call get_unchecked() instead of [] to elide the bounds checking at any place that does it in Rust.

[mirsadm]

As someone mentioned below, C can almost be seen as a portable assembly. Given enough time and optimization it will always be as fast as the hardware allows. I guess my point was it is meaningless to say "faster than C" because it always depends on too many factors.