On a single thread, C is certainly fast. And for a reasonable amount of effort is probably the fastest, yes. However, a discussion board is likely to have many users in parallel. It is hard to get accurate figures, but online communities can number a few hundred simultaneous users.
The problem is that using a thread per user is often a Real Bad Idea when you get into the hundreds of users, especially as many are: (a) read-only, and (b) often accessing exactly the same data.
What you really want is to divide the threads by activity, rather than by user. C is not really very good at this, because there's really no good way to represent objects and applications. C is flat and monolithic. An activity-based system is heirarchical and potentially distributed.
For a distributable, heirarchical system, you're looking more at SISAL and Occam, but there aren't that many good compilers for those out there.
Another consideration is that a message system needs to serve all the users at a reasonable speed, so you're also wanting some real-time characteristics. You don't want one user to lock the system up, or even have the potential for doing so.
Finally, you don't want the crashing of a single unit of the software to take down everything. You want fault-tolerance. C is about as intolerant as you can get, and it can be a real problem to write handlers for every possible signal in every possible component. And then have a health monitor, to allow for untrappable signals, so you can restart something.
Really, you want something that makes it: (a) easy to handle real-time, exceptions and errors, and (b) makes it possible to handle this centrally, efficciently and as transparently as possible.
If you don't, then you have to rely on adding all the hooks in every place that might need them, no more and no less. Few coders claim to be perfect, so a library or language feature that deals with all this is a Very Good Idea.
For robust code, you're more likely to be looking at a more modern, probably high-level, language. Those tend to have good quality exception handling. If it is targetted at engineers, then it may well also take care of the real-time properties.
So, what you end up with is something like this:
For the raw, underlying servlets/service modules, you're wanting a highly parallelizing language that supports process mobility, low-cost communication and low-cost threading.
For the framework that actually drives all of this and connects the bits together, then you're probably looking at a mugh higher level language. Speed isn't important, as it doesn't actually do any "work" on data, it is purely managerial.
What you want is something that'll work just fine on a single box in your basement, or be extended to the sort of cluster room that systems like Slashot inhabit, WITHOUT having to change anything. Changes add the risk of bugs, so should be carried out to add features or debug, but never for structural changes.
(If the structure changes enough to force a change in the code, then there's a good chance you've had to make enough non-trivial modifications that it's basically a new program. That is a Bad Design.)
Design should be scalable, no matter what the userbase and no matter what the change in hardware. It should be aware enough that it can provide the best service for the users given the number of users and the hardware available to it.
Smart software is good software. Dumb software, these days, is stupid.
[ Parent ]