Can I get a rebuttal to my points along with the downvotes, though?
Is someone disputing that CPU intensive tasks should be moved off the webserver?
Have you personally had experiences where your honest-to-$deity webserver bottleneck was the CPU? I'd be incredibly surprised. In most cases I'd guess you're underprovisioned and/or badly architected.
* This is where we come to somberly discuss interesting things.
1. Your networking pipe into the server is slow.
2. You don't have a reverse proxy in front of the webserver to buffer the slow connections.
3. You don't make decisions about what information to show the user in the webserver; your UI isn't tailored for the particular user whose request you're servicing.
4. You haven't made productivity trade-offs to move work from the developer to the computer.
Google's webservers (for Search) are CPU-bound, and I can guarantee that they are neither underprovisioned nor badly architected, and CPU-intensive tasks are moved off the webserver (the total amount of CPUs for webservers is miniscule compared to the number of CPUs used for the indexing & serving system). But Google has the fastest fiber networks in the world, a massive load-balancing infrastructure, its philosophy is to serve each user only the HTML/JS that they need (to cut latency), it relies heavily on A/B tests & experimentation, and it invests significantly in developer-productivity tools so that all the bookkeeping for the last two points are done by computers rather than humans.
99% of cases, your bottleneck will be I/O.
In the 1% of cases where your webserver's bottleneck is the CPU, you have much bigger problems than using a hipster ;) language: you're doing it wrong (tm) on an architectural level:
(a) Your processor-intensive/long-running tasks need to be in seperate worker processes and
(b) you need more webserver instances.
I usually try to avoid absolute statements, but I think this may be accurate:
The only CPU-intensive thing your web server code should ever do, is hash passwords.