I can't stop thinking about node.js.
node.js is Google's V8 JavaScript engine tied together with some non-blocking IO libraries. Those libraries include DNS, TCP, HTTP and file access.
Now, I've been dreaming about a good server-side JavaScript solution for quite a while. JavaScript is an excellent language, and chances are you're using it already on the client side. Why not use it on the server side also? That's not the main reason that node's author (Ryan Dahl) chose it though. He chose it because JavaScript is already very callback-centric, and node is designed to use callbacks in place of multi-threading. Whenever you do something that might take a little while (like hitting the network or disk), you set it up and then pass it a callback. Your callback will know how to handle the data that gets returned. Meanwhile, code keeps executing. This is much better than having one thread running for each connection, because those threads are usually waiting for the network or the database or even disk. When you have all those idle threads you pay a penalty in context-switching and memory overhead.
If you still need more convincing, check out Ryan's slides from his JSConf.eu talk (PDF). They're very readable slides.
It's still early days for node.js. The project (what do you even call it - a server, I guess?) can serve up HTTP very well, but it doesn't give you a framework by itself. Consequently there are frameworks popping up all over for it, following all the patterns of frameworks implemented for other languages. One thing the server is genuinely missing is database support. A PostgreSQL binding is in the works, which sounds great to me. MySQL might be harder because it doesn't have a non-blocking library, but who needs MySQL when you have Postgres? :-P
