[sovande]

The '!?' was aimed at Mr. defunkt who said that

   nginx relies heavily on system calls at the expense of portability

Its a oxymoron as you cannot expect a C application that mostly do network and disk i/o not to use syscalls. That said, the author of nginx does an admirable job of reducing the numbers of syscalls and make the application as efficient as possible. In this context a syscall i.e. a kernel call is heavy and something one want to minimize.

The blog post on the other hand was talking about using syscalls from Ruby. I can understand Ruby programmers who wrinkle their nose at this. If you want your Ruby application to be portable then using, for instance, fork is not the best idea. In fact, programing anything long lived such as a server in Ruby is not the best idea. The GC in 1.8.x leaks memory over time and it is a common case that Ruby servers has to be restarted often as they consume all memory on the machine they run on. Adding fork on top of this is bad. A fork will copy the whole Ruby interpreter into the new process and you will end up with a lot of top-heavy processes - not a good idea unless you sell RAM. Basically, using Ruby as a systems programming language and for applications that are long lived is a bad idea.

[tyler]

Nonsense. My multitudes of small web services, many of which have been running months without a restart and while taking up no more memory than they did at the start say you're wrong. Even if there are some obscure bugs, and there undoubtedly are, that doesn't make ruby an unsuitable language for systems programming.

[ealar]

My only reply to this: Ram is free. You are optimizing the wrong thing.