I dispute this. Please take a look at:
http://bstring.sf.net/ and
http://pcre.sf.net/ . With the combination of those two libraries, you
can make C comparable in functionality on strings to any scripting
language in existence.
bstring is awesome but it's still behind the functionality of most
modern scripting languages. e.g. there's no support for character
encodings, many of the lib functions are very specialized (there's
btrimws but no generalized strip/lstrip/rstrip that lets the user
select what characters to strip), and it lacks things like tab
expansion, console text justification, etc. I didn't even see a simple
reverse function but I might've missed it.
That's not necessarily a knock; if you're going with C, you probably
want a leaner API. But scripting languages tend to have tons of little
helper functions that can make life easier on the programmer.
But the C language typically offers better debugging tools. Scripting
language may offer a safer environment that insulates you from the
worst kinds of errors, but on the other hand they often drop things
like "type checking".
Python and Ruby are both much more strongly typechecked than C.
Whether static or dynamic typing is better is an argument that's been
had out a million times and is off-topic anyway (certainly if you're
used to one it takes a while to adjust to the other).
Like, performance and/or surviving a slashdot/digg effect?
We had no problems serving 300 pages/second from a python-based
solution when I was working at a large web company, and the servers
weren't breathing hard (We were, in fact, slashdotted but the traffic
spike just isn't very noticeable to a larger site). CPU usage was only
in the 10% range, we had 4 servers (moderately sized intel or amd
boxes) for redundancy but 1 was an offline backup. That was peak
traffic in special events; average peak daily was significantly lower.
CPUs are fast and putting together web pages isn't very
compute-intensive; the problem tends to be (1) the network being
saturated; (2) running out of file descriptors or other resources if
your server architecture is poor or (3) the database falling over,
again normally an architecture/design problem.
That said, the dynamic content server which had to serve several
requests for each page view was a custom C solution. It handled
probably 1500-2000 requests/second during peak special traffic with
next to no CPU usage, but it also had the luxury of having persistant
connections to the web farm (they obviously had to set up and tear down
TCP connections for most incoming web requests).
FWIW, it was entirely written in ANSI C except for network socket calls
and file descriptor passing so that it could be upgraded seamlessly
without losing connections to the web servers--all the logic for
parsing and processing a request and determining a response was
bog-standard. It was taken out of production some time this year but
by then had served several billion requests with no unscheduled
downtime.
So for certain types of web solutions, C can work very well indeed.