I am saying something very simple that seems to have caused your head to explode. It is: you could write n+1map in Python using Twisted, or Ruby using EventMachine, or Erlang, and probably end up faster (not because of the language, but because you'd design for speed and the language doesn't matter) than nmap is in C.
This isn't a controversial statement. Nobody thinks nmap is the fastest possible scanner. To argue that n+1map should be written in C, you have to make a case for what aspect of a port scanner benefits from C. Which is why I pointed out: nmap doesn't even look I/O bound; it looks timer-bound. And in most cases, neither I/O-bound nor timer-bound programs benefit greatly from locality, cheaper copies, or (within reason) optimized memory allocation and layout.
I believe the problem is that you seem to be saying c should only be used when performance matters. They think the language choice is irrelevant and shouldn't have even been mentioned. Or so I believe.
For my part, I am an avid C programmer; it's my first language, and virtually the only one I used through the '90s. And I will say: you should avoid writing in C unless you need to. The cases I can come up with off the top of my head where it's necessary:
* When performance matters and can be gained through writing C code --- for instance, if you're compute-bound, or if you need fast access to data structures.
* When building incremental improvements to large C codebases --- ie, writing a loadable kernel module.
* When you're deploying in small-footprint environments.
What are the other cases where C makes sense?
I brought up the C thing not because I want to take potshots at what is probably my favorite language, but because a majority of the developers on HN don't write C, and you'd hate for them not to take a crack at competing with nmap because they had a faulty belief that they'd need to use C.
C is a bad choice for a new port scanner started in 2011. I've already written comments here justifying that statement. If you really think I'm wrong, it might be fun to hash out why. (I've got a fairly decent background in nmap's problem domain, for what it's worth.)
I don't have a problem with C, although if I had to do it I would use C++ for object-oriented support and more or less guaranteed portability. Possibly also to compile in a lua interpreter. That said, I'm not a domain expert and was responding to the question of whether nmap should have been coded in C rather than what the best language would be for something started NOW.
I don't know what the best alternatives would be and while I doubt I can contribute much to the discussion, I've read your other posts on security with interest and would be interested to hear which language you'd pick and why.
Personally, I think Lisp is a fantastic language to write a scanner in; you can express async state machines in it naturally, and most Lisps have very good foreign interfaces, which would allow you to just call into libpcap. Lisp is also good for DSLs --- look how Seibel did the little expression language for binary formats in his Lisp book; that's exactly the problem statement that drove me to make my own dumb language in '97 to express packet formats.
Virtually any language will work for this (which is why you should avoid C). About the only thing I'd steer you clear of is a JVM language. The JVM is ordinarily a win, but here, where you want the path-of-least-resistance to getting pcap into your program, it's a bit of a pain. So scratch Scala from the list. Other than that, have fun.
