[PhilipRoman]

It's actually pretty fast if written in a lean language like C/rust. See "cgit" for a good example. And if you want to distribute a program which talks HTTP, it's kind of the obvious choice - the alternative is each program packing it's own HTTP server, which needs a reverse proxy/SSL in front of it anyway.

[hnlmorg]

The bottleneck for most CGI requests wasn’t the language, it was the fork()ing for each request.

Granted there will be some CPU intensive services that will benefit from C but I still wouldn’t call CGI “pretty fast”.

That’s not to say I’d dislike CGI. I made a fair amount of money in my early career based on services written to use CGI. But the reasons why we had things like fastcgi, mod_perl, and the HTTP servers included in language frameworks was to mitigate the overhead of expensive process forking.

[PhilipRoman]

Interesting, I've never found fork particularly expensive, usually the bottleneck turned out to be setting up language specific runtimes. I would certainly never write CGI in a language like python where startup takes significant time.

[hnlmorg]

Yeah, that’s true too.