I have a friend at Intel who works on their realtime raytracing efforts and he swears by C/C++. Indeed, his arguments mirrors yours and go even farther. There's all sorts of magic you can play when you've got access to the actual bits and bytes. For starters, they do things like stash data in the low-precision bits of floats and the lower three bits of pointers. I wholeheartedly concur with his opinion that in raw performance terms, C/C++ is the fastest.

The problem with his argument and yours is that C is NOT faster for The Rest of Us because it it amounts to premature optimization just by virtue of using it. And because it takes so much effort to get C code to just work, the WHOLE program ends up being slower than the corresponding code in Haskell, OCaml, or perhaps even CLisp. Having worked my last job in a company where the programmers preferred C to C++ and C++ to Python, it startles me how utterly slow our system was. And ditto for the previous job.

At my first place, we had a streaming video server that had blindingly fast compression routines, but it was all held up by a UI loop that harked from the prototype days. Thus the argument that C/C++ is/are the best languages for fast code is moot. It is only the fastest if you've all the time in the world to write it.

People here are very critical of Jeff Atwood. I realize that he has some shortcomings, and is sometimes flat-out wrong about things, but I'd like to point out a couple of things in his defense:

1. His blog and podcasts are pretty entertaining, even if he is wrong sometimes.

2. He created Stack Overflow, which is a pretty nice site. At least, I like it.

3. He admitted and blogged about an extremely embarrassing oversight on his part today. Which takes some backbone.

That being said, I don't think we need a link to him on every single blog entry. This particular entry is more interesting from a Hacker News perspective though.

Wow. That's a display of humility and responsibility you just don't see very often. Though the original conflict was avoidable and unnecessary, an apology like this - for anything - shows real character. Kudos.

Don't let the title fool you. This isn't a shitty top 10 list.

He is so pretentious. He goes on about how great Open ID is and yet talks about how he has all these different passwords and uses a "throwaway" password for admin access to his application. Great. Then he posts something about how "brute for is for dummies" when using bad passwords is really what's for dummies.

This argument is as old as the hills. It's probably true in a lot of niche situations. But the fact is, most C code is faster than higher-level language code, because:

* C programmers have more freedom to arrange data in memory to exploit locality

* C data structures need less bookkeeping

* C programs manage memory manually, and so lack GC overhead

* C programs can easily swap in different allocators for different work sets

* C function calls are usually wired into the code, not indirected through (several layers of) tables.

That's to say nothing of bytecode interpretation overhead, which is probably a straw-man argument.

I buy the instruction scheduling argument for inner-loop numerical and vector scenarios, but even in performant code, that's usually less than 10% of the total, and from what I've seen, both C and HLL code tends to delegate that to machine-specific assembly libraries.

"I've talked about this exact sort of vulnerability several times on this very blog."

You talked about it but didn't implement it? Yikes.