Bad corner of the Lisp world? Socket libraries are the Skid Row of Common Lisp. The reason it's hard to create a good library comes from an interplay of 3 thin

Bad corner of the Lisp world? Socket libraries are the Skid Row of Common Lisp. The reason it's hard to create a good library comes from an interplay of 3 things: streams, lack of standard character representation, and lack of standard foreign function interfaces. The latter two are sort of advantages in that if they were standardized in 1989 or whatever, we would probably have wound up with something stupid involving DOS code pages and Fortran on VMS. Streams are convenient and most CL functions expect them. They're also a really inefficient way of using BSD sockets. Especially when your Lisp implementation's character encoding isn't UTF-8. So if you want to write fast network code in Lisp you basically need to use the raw POSIX FFI functions and byte arrays. Then you get into fun stuff like vectored I/O (which you may or may not be able to do depending on whether your GC moves arrays around), and event-based I/O (which people disagree as to how to do properly). But it's ok, because none of the existing socket libraries try to support this anyway, so you're back to calling POSIX functions via FFI. (I gave a presentation about this stuff last year: http://carcaddar.blogspot.com/2009/11/november-montreal-schemelisp-user-group.html http://carcaddar.blogspot.com/2009/11/november-montreal-sche...) If your socket library is dependent on any third-party libraries, pray that the latest versions will not completely change their interface and make your library fail to compile. Then multiply all this by the half-dozen or so Common Lisp implementations people expect to be supported. Just like Skid Row, this has been a recognized problem for many years (well over a decade for certain), and it's kind of hard to make it better. Flexi-streams over usocket is the best off-the-shelf solution, so you're probably doing the right thing.