Perl has access to socket programming primitives. You can essentially do ''everything'' you can do in C (with often the same function names).

I had to do some hardcore (200+ 6KB UDP messages/sec across 6 sockets) networking. It had to run 24x7 and there was no room for memory leaks. Naturally I prototyped it in Tcl (plus TclX and the TclUDP extension).

But Tcl is slow. To satisfy a caching requirement, I queued the messages in a Tcl list and used Tclx's lvarpush and lvarpop to store/fetch the messages. That was an order of magnitude slower than the same algorithm in Perl (using push and shift on arrays).

Still, the Perl app wasn't any faster. ''The network is the bottleneck''. But, more interestingly, I had to implement some common Tcl idioms (involving fileevent, after and non-blocking/non-buffering puts) in Perl. And, that is where I learned how well thoughtout the Tcl I/O system was.

As a side note, I added a very slim "udp_read" C function to my app to compare it with going through the channel based Tcl read proc (as TclUDP does). Not much performance improvement was gained by doing that.

In the end, Perl did allow me to tweak a few more things (but I could easily do that with a couple of Tcl extensions). Perl networking is much richer (without having to go to C). However, after struggling with partial writes (using syswrite) and mucking with IO::Select to get it to act like the Tcl event loop, I've come to appreciate the things Tcl does for me.

The lesson learned: Perl has better low level networking access, but the Tcl code contains a lot of idiomatic functionality that you'll find yourself hand-coding in Perl (and to less effect). See [POE].

-- [Todd Coram]  ''Once again, it looks like my Tcl prototype will make it into production without the often obligatory C rewrite!''