Maybe I'm showing my allegiance to my platform of choice, but the subtle dig on nodejs wasn't warranted on slide 25 (http://talks.golang.org/2013/oscon-dl.slide#25). As everyone's pal `substack` will tell you, use streams! Instead of explicit buffering, handling backpressure, etc., it's as simple as:
readable.pipe(writable);
Additionally the link to `http-proxy` on slide 30 is misleading; 60% of that file is comments, and about 50% of what's left is websocket support, with the rest being header parsing & redirect parsing. The actual proxying bit is very simple and straightforward, and if you don't need every feature `http-proxy` offers you can do it yourself with streams in < 10 lines.
It wasn't a dig on nodejs. It was a dig at event-based programming, on which I've wasted years of my life in many languages. Node.js isn't unique in that regard.
As I mentioned in my talk, that code looks like fine Node.js code.
But it's still event-based, and the flow isn't readable. In the actual presentation I went through the code to show how control flow jumps around. I picked a Javascript project (and the top hit I got from a search) because people know Javascript.
Websocket support doesn't matter. In Go, you can also just io.Copy(websocket, src).
Have you by any chance seen the async keyword in C# 5.0? It allows one to write event-based code without callbacks obscuring the control flow. From what I've heard Python is in the process of copying this feature. Iced Coffescrip does something similar also.
It's good for C#, but still a language wart that could be built-in. I like that Go only has one set of APIs for everything, not the sync way and the async way.
It's sad that C#, which started out as a fixed-up Java, is now growing its own warts.
I haven't yet tried Go, but I don't see how it could match the performance of C# API with a single function. C#'s async methods offload any IO to the process IO completion port threads, thus freeing the current thread to do more work.
Go generally uses synchronous functions, but a function in Go can be the subject of a "go" statement (sharing the name of the language should give an importance of how central this feature is), which causes the function to be executed as a goroutine (that is, asynchronously using an M:N threading model.)
I haven't yet tried Go, but I don't see how it could match the performance of C# API with a single function. C#'s async methods offload any IO to the process IO completion port threads, thus freeing the current thread to do more work.
Node-fibers allows a similar thing with a pretty raw syntax. At least one clever programmer has painted over it and introduced await/defer in Node without any JS pre-processing [1].
If you enjoy CoffeeScript, Iced CoffeeScript does a great job of this too.
Comments
Maybe I'm showing my allegiance to my platform of choice, but the subtle dig on nodejs wasn't warranted on slide 25 (http://talks.golang.org/2013/oscon-dl.slide#25). As everyone's pal `substack` will tell you, use streams! Instead of explicit buffering, handling backpressure, etc., it's as simple as:
readable.pipe(writable);
Additionally the link to `http-proxy` on slide 30 is misleading; 60% of that file is comments, and about 50% of what's left is websocket support, with the rest being header parsing & redirect parsing. The actual proxying bit is very simple and straightforward, and if you don't need every feature `http-proxy` offers you can do it yourself with streams in < 10 lines.
It wasn't a dig on nodejs. It was a dig at event-based programming, on which I've wasted years of my life in many languages. Node.js isn't unique in that regard.
As I mentioned in my talk, that code looks like fine Node.js code.
But it's still event-based, and the flow isn't readable. In the actual presentation I went through the code to show how control flow jumps around. I picked a Javascript project (and the top hit I got from a search) because people know Javascript.
Websocket support doesn't matter. In Go, you can also just io.Copy(websocket, src).
I agree Stream makes Node.js code better.
Have you by any chance seen the async keyword in C# 5.0? It allows one to write event-based code without callbacks obscuring the control flow. From what I've heard Python is in the process of copying this feature. Iced Coffescrip does something similar also.
This answer sums up my feelings best:
http://stackoverflow.com/questions/7479276/what-is-the-main-...
It's good for C#, but still a language wart that could be built-in. I like that Go only has one set of APIs for everything, not the sync way and the async way.
It's sad that C#, which started out as a fixed-up Java, is now growing its own warts.
Of course, Go's not perfect either.
Go generally uses synchronous functions, but a function in Go can be the subject of a "go" statement (sharing the name of the language should give an importance of how central this feature is), which causes the function to be executed as a goroutine (that is, asynchronously using an M:N threading model.)
You meant to reply to test-it, but instead it looks like you're teaching a member of the Go team how Go works.
Very interesting.
I haven't yet tried Go, but I don't see how it could match the performance of C# API with a single function. C#'s async methods offload any IO to the process IO completion port threads, thus freeing the current thread to do more work.
Node-fibers allows a similar thing with a pretty raw syntax. At least one clever programmer has painted over it and introduced await/defer in Node without any JS pre-processing [1].
If you enjoy CoffeeScript, Iced CoffeeScript does a great job of this too.
[1] http://alexeypetrushin.github.io/synchronize/docs/index.html