3 ms·
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
by STRML 13y ago
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 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.
- bradfitz 13y agoIt 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.
- test-it 13y agoHave 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.
- bradfitz 13y agoThis answer sums up my feelings best: http://stackoverflow.com/questions/7479276/what-is-the-main-difference-between-net-async-and-google-go-light-weight-thread 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.
- test-it 13y agoVery 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.
- dragonwriter 13y ago> 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.)
- deleted 13y ago[deleted]
- wolf550e 13y agoYou meant to reply to test-it, but instead it looks like you're teaching a member of the Go team how Go works.
- STRML 13y agoNode-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 http://alexeypetrushin.github.io/synchronize/docs/index.html