== Why a netcat-like program is a good test of a language When I talked about [[my first Go experience GoFirstExperience]], I mentioned in passing that a netcat-like program is actually not a bad test program for a language (or for certain sorts of libraries in, eg C). Today I feel like explaining that. To start with, it's not an empty and artificial challenge; a netcat-like program does something meaningful and practical (although it may not be necessary if you already have netcat). The problem itself touches many levels of a language and its library, since it has to interact with standard input and output, deal with command line arguments, look up hostnames and ports, make network connections and talk over them, and deal with buffering and byte input and output. It also involves some level of network concurrency, either through real concurrency (as in [[Go http://golang.org/]]) or through the equivalent with _select()_, _poll()_, or the like. There are also some subtle and taxing aspects to the problem, such as _shutdown()_, that test whether the language (and library) designers were paying attention or thought it worthwhile to expose the entire underlying system API. (In a low-level language like C you'll also wind up exploring things like memory allocation and any safe buffer handling libraries that are available. If you're working with _select()_ et al you can also extend the problem to playing around with nonblocking IO, again if the language gives you access to this.) Of course there are many aspects to a language and its libraries beyond relatively low level networking, so this problem doesn't come anywhere near to exploring all of a language and its libraries. Still, I've found that it covers a lot of ground that's interesting to me personally and the whole experience is a good way of seeing what the language feels like. Some people will want to write HTTP-based test programs instead because that's more directly relevant to them. I'm the kind of cynical person who wants to see the low-level plumbing in action too, partly because I think it's more revealing of the language's core attitudes. Since the web is so pervasive and important, my feeling is that everyone doing a new language environment is going to make sure they have good HTTP support (assuming they care about such usability at all). And if a language doesn't have either high-level HTTP support or good low-level networking support, well, that tells me a lot about its priorities.