Handling blocking IO in Go
kanwisher.com
kanwisher.com
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 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).
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:
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?