[Kylotan]

The cost of code maintenance is not constant across all languages. It's much easier to maintain something written in a modern language like Python than to dig into a C app, especially apps that have to do low level things like manage their own intrusive linked lists (and sometimes use 'last' and 'prev' interchangeably - thanks, Smaug people).

The original discussion was specifically about someone choosing to start up with a Diku. I would certainly hope that there are alternatives, and that maybe some of them are good, but unfortunately they have much less traction with the community. And I still wouldn't recommend anyone uses C; I'd suggest C++ as an absolute minimum for application development.

You talk as if other languages are inherently slow, and that C is inherently fast. Yet the libraries and runtimes that other languages use to get their work done are typically written in C, and written and tested by highly skilled people. These skilled people know full well how to use C, and yet choose not to where possible.

It's far faster, for example, to use a Python dict for object lookups based on a name than it is to do a linear search in a linked list in C for an object with that same string. Of course, someone with sufficient skill could write something broadly equivalent to a Python dict in C for your mud - after all, the Python dict is written in C. But Python already has it there for you. It's quicker both in terms of development time and in execution time. If you invest the extra development time you have a chance of coming close in terms of speed, a tiny outside chance of beating it in speed, but you'll never get that initial time back. Is it worth it?

Same thing goes for networking - why have a naive select() loop in C when you have a platform-independent equivalent that uses more efficient alternatives like poll() or event-driven I/O in Python? Why hand-code your own 25-line bubble-sorts as you see in Smaug when you can use the list sort() method in Python and get a more efficient mergesort algorithm into the bargain? This is the problem with low level code machismo - people write code that does the wrong thing quickly and think that they're saving on some mystical overhead.

If what you want to do is "write an extensible and maintainable MUD server" then C is almost never the right tool these days. Almost every other mainstream language does it better. They have strings, they have containers, they have standard libraries that would condense about 50% of a typical Diku MUD into a few one-liners. C was the right tool when Diku started out so this is no criticism of the original authors. But we've learned a lot about how to write software since then, we've developed new tools that make it quicker, easier, and safer, and we have much better computers to run it on.

Today that is almost extortionate considering Google App Engine will give you 25% (of a 1.2 GHz processor) for free. If a host wants to charge $8 for various other maintenance costs, that's fine, but to pay $8 to share a server with 50 other games, none of which are allowed as much memory as even trivial desktop apps use today, then you're paying over the odds. Not that I think the CPU usage argument is a good one for choosing C, for the inefficiency reasons stated above. Admittedly you'd have trouble running a Python or Java server in 15MB but I think that's just an unreasonable expectation on the part of the hosts and that it's not worth enduring all the other pains of programming text applications in a systems language to cut a few megabytes of RAM.