> If you were "totally new" and didn't even know about go and goroutines, why would you even click on that link and expect to understand what it's talking about

> If you were "totally new" and didn't even know about go and goroutines, why would you even click on that link and expect to understand what it's talking about? That doesn't even make any sense. You're objecting about why a person would read an introduction to a language/platform if they're not familiar with it. > Of course evented systems "are not really a good way to handle blocking IO", nobody's ever claimed that, quite the opposite. Oh really? That's all Node.js claims to do. What's Node's tagline? "Evented I/O". Node's only purpose is to "fix" blocking I/O. Go on, read what the homepage says: http://nodejs.org/ http://nodejs.org/ Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. Notice how it doesn't sell itself as "javascript on the server side" or anything like that. It sells itself on two points: - A platform that runs on top of Google's V8 (fast) - It fixes I/O blockage by using events and callbacks (aka evented I/O) In other words, it's all about scalable backend services. If you think Node's approach is a good way to handle blocking IO, good for you. I happen to think it's a terrible approach. And I think there is a much more viable alternative out there for backend developers who have performance concerns: whether it's related to IO blockage, or the general slowness of interpreted languages.