Imagine your shock when you build your craptastic app in C++ and wonder why it's not any faster than a scripted app. I'll give you a hint ahead of time: most bottlenecks aren't processing time, they're DB or IO limited.
Not strictly true. In the bigger companies, everyone knows that DBs (which is really just a special case of I/O) and I/O are slow (we tend not to hire them if they don't - one of my favoured systems & arch. interview questions[1] is on memory/storage hierarchies). The more interesting problem is what ELSE you've traded off to eliminate I/O on the common path - and in many languages it turns out to be memory fragmentation and/or garbage collection time. In Java, stop-the-world GC pauses of multiple seconds are not unheard of, and it's no fun being Oracle's test bed for undocumented GC features. It's also no fun when you find out you can't restart your multi-gigabyte heap JVM because the underlying OS has fragmented RAM so badly it can't alloc that heap in a single contiguous chunk.
This is something newbies repeat to justify their choice of a piss poor implementation. Sure with 10 users hitting your Rails app it might perform the same as Nginx with a custom C handler talking to a database written in C, but increase the load and soon your handing Amazon thousands a month on ec2 nodes while I am still on a small Linode. The funny thing is because of code gen and experience I can probably write my app faster than you dicking around with framework after framework