At the end of the day, what is real time anyway? The sounds I hear and the light I see have taken time to get to me... all of experience is touched by some form of latency ;)
Does that meet the criteria of realtime computing? If not, is Google wrong?
"Event-driven" or "non-blocking" is probably a better fit, here. Or "web scale", because then people know you're just making up crap about the new hotness.
However, I wish you and L'Académie Française the best of luck. ;)
Two demos available so far: https://www.socketracer.com and http://ssdashboard.com.
Also interesting that AOL is officially putting money in the project, and with the intention to keep it under the MIT license.
* Brunch: http://brunchwithcoffee.com/
* Zappa: https://github.com/mauricemach/zappa
* Coffeemate: https://github.com/coffeemate/coffeemate
Of course, SocketStream's use of websockets to deliver all content (after an initial payload) is a very different, very opinionated approach. I also like the look of API namespacing, which allows client and server code to be structured analogously without having to use `requires` at the top of every file (one of Node's weaker points, as Ryan Dahl would be the first to tell you). It all sounds very well thought-out, and I can't wait to see where this framework goes from here.
I must say, I'm excited for this to become more robust, but I appreciate their candor in telling me why I shouldn't use it in production yet. Back to old fashioned socket.io I guess (or maybe NowJS).
I read about it on Twitter from a socket.io contributor, so I guess it's safe to publish this.
 here's a racing game demo, powered by SocketStream: https://www.socketracer.com. Impressive
I was curious how this system scaled beyond one node and thus a single point of failure. I then saw it used Redis. Hooray, they relocated the single point of failure.
But hey, Redis is really really fast, right? That's definitely within the spirit of node.
Even while I'm developing?
Imagine the confusion when you're working with or contributing to two different libraries that have different indentation or documentation standards. Now make the language different, and mix and match different syntaxes for different languages. Should modules in JS accept patches in coffee? What about vice versa?
Not to mention that coffeescript then becomes an additional dependency, and while in itself that's not bad, I still consider less unnecessary dependencies a positive aspect to a library/framework.
Edit: Why downvoted? Is this not a valid concern?
Disclaimer - I'm still in the pub, What I'm trying to say is, I understand JS, I'm still happy to code in js, but I like teh coffeescript. Let's learn to speak to each other
To reiterate, I actually love coffeescript, but I see the fragmentation as overall hurting the JS developer community.