In Linux you can redirect the stdout to the the socket outside of your program, no programming required. You can test and develop everything with stdout and let the same unmodified file run in the web server. See traditional CGI, that's how dynamically generated web pages were easiest to implement long ago:

http://computer.howstuffworks.com/cgi3.htm

The server opens the socket, redirects the stdout to his socket while calling your program fully unmodified.

You open network sockets in Linux and redirect stdout to them? It's possible with curl I guess, but generally people don't do that as it's hard to send the data in the right format. Mostly people will use a tool to access network services.

As for serving files, you'd normally let nginx or apache take care of the sockets for you and not use output redirection.

In Plan9 it's actually viable to use network sockets as files which is pretty nice, but for Linux it's not really how people do it.

> but for Linux it's not really how people do it.

Please explain that to all the people who wrote CGI scripts for years. Seen the link at all?

CGI scripts are dead though. It turns out it wasn't a good way to do it. It's better to use a nice new invention like Apache or Nginx to handle the sockets for you and then use frameworks specifically designed to handle HTTP responses as piping HTML through std inputs is difficult and error prone.

The ability of a language to easily write to std out is simply not important anymore apart from shell scripting which is mostly used these days for setting up the runtime environment and building other languages to handle the grunt work.

I don't know of any companies that still pipe std output directly to sockets anymore, but I guess there must be some. If your company still does this then a language feature like that makes sense. For most people, having the ability to write code that can directly write to sockets without piping through a shell is better practice.

I wouldn't say they are totally dead. They are great for relatively quick/dirty code.

The major advantage that CGI gives you is the fact that you get a new, clean process on each request. This means you have fewer and simpler failure cases. This can be helpful when you have a line of business web application though it is certainly suboptimal for public-facing scalable systems.

I wouldn't say cgi is dead. It still has a role to play. It is not the ideal way for doing many things though. I.e. they are no longer the go-to tool, but rather one tool for relatively lower-volume applications where performance matters less than some other considerations.