Good start, but needs more explanations I think. If I was totally new I wouldn't understand what this stuff is.
Actually, I am totally new, but I've seen talks and read various tutorials, so I can understand the concepts presented here.
I think this stuff is really important and people really should become aware of how do handle blocking IO in Go. Maybe then people will finally realize that things like Node (and Twisted, and Tornado, etc) are not really a good way to handle blocking IO after all.
I'm very excited about Go, and I don't understand why it's not catching up yet with the startup crowd.
> If I was totally new I wouldn't understand what this stuff is.
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?
> Maybe then people will finally realize that things like Node (and Twisted, and Tornado, etc) are not really a good way to handle blocking IO after all.
Wow, that's one big strawman to set on fire.
Of course evented systems "are not really a good way to handle blocking IO", nobody's ever claimed that, quite the opposite. There's a reason why the IO layers have to be provided by the evented runtime or patched (and replaced by non-blocking versions) on the original one. Here's how you handle blocking IO in an evented system: you bloody fucking don't.
For the outlined case, a node user would use child_process[0] which is non-blocking and provides all the tools you should need (I'm sure there are libraries out there providing an even nicer interface to sub-processes).
> 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.
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.
I found this post to be extremely, gratuitously aggressive and pointed, completely out of proportion to hasenj's. Nor is this the kind of social issue I expect to drive this kind of instant hot anger. Even if he is completely wrong, that isn't necessary.
I didn't learn anything about node's technical side but I did learn something about the community side
I don't know why author thinks that blocking IO is a "One of the most frustrating things when you start with go" because from the very beginning of leaning Go most articles, tutorials and books tells that golang uses goroutines to achieve concurrency. I've started learning golang a few weeks ago and the fact that all IO is blocking was the most nicest part of the language. I mean you dont need to wrap your code in deeply nested callbacks as you do in node.js, and your code is always look straightforward. In fact IO is only looks blocking, AFAIK, go uses epoll/kqueue under the hood for IO operations.
Not sure what the original expectation was. How else would an operation, that by definition continuously writes to stdout until interrupted be anything but blocking... until the process was killed?
9 comments
[ 2.9 ms ] story [ 27.9 ms ] threadActually, I am totally new, but I've seen talks and read various tutorials, so I can understand the concepts presented here.
I think this stuff is really important and people really should become aware of how do handle blocking IO in Go. Maybe then people will finally realize that things like Node (and Twisted, and Tornado, etc) are not really a good way to handle blocking IO after all.
I'm very excited about Go, and I don't understand why it's not catching up yet with the startup crowd.
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?
> Maybe then people will finally realize that things like Node (and Twisted, and Tornado, etc) are not really a good way to handle blocking IO after all.
Wow, that's one big strawman to set on fire.
Of course evented systems "are not really a good way to handle blocking IO", nobody's ever claimed that, quite the opposite. There's a reason why the IO layers have to be provided by the evented runtime or patched (and replaced by non-blocking versions) on the original one. Here's how you handle blocking IO in an evented system: you bloody fucking don't.
For the outlined case, a node user would use child_process[0] which is non-blocking and provides all the tools you should need (I'm sure there are libraries out there providing an even nicer interface to sub-processes).
[0] http://nodejs.org/api/child_process.htm
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/
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.
No, this is not an introduction to a language/platform, this is an introduction to a very specific problem/detail of a language/platform.
> Node's only purpose is to "fix" blocking I/O.
By getting rid of it.
> If you think Node's approach is a good way to handle blocking IO, good for you.
Are you trying for a daftness award?
No, you are nitpicking on the word "handle". Alright, let's change that to "deal with the problem of IO blockage". Happy now?
You know full well what I mean, and I can't interpret your attitude as anything other than trolling.
I didn't learn anything about node's technical side but I did learn something about the community side
Not sure what the original expectation was. How else would an operation, that by definition continuously writes to stdout until interrupted be anything but blocking... until the process was killed?