Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To boldly go where Node man has gone before

blog.jgc.org

Post reply on HN
Print view View original

71–80 of 124 posts

Re: To boldly go where Node man has gone before

#71

Post by chc »

_ak wrote: post #64
chc wrote: post #9

Earlier quoted context omitted.

> So does Go's net/http module really provide basically exactly the same programming model as Node? If so, why use Node? Well, for starters, Go is much more awkward for working with JSON than JS is (which is to be expected since JSON is literally a subset of JavaScript). More importantly, Go lacks the ridiculously vibrant ecosystem for Web development that Node has — no NPM, no Connect, no Jade, no Stylus, etc.

So what exactly do you think is awkward about Go's way of working with JSON? Here's a code example from one of my current projects: type UploadProgress struct { Progress int `json:"progress"` } //... // variable progress is of type Progress if json_data, err := json.Marshal(progress); err == nil { w.Header().Set("Content-Type", "application/json") w.Write(json_data) } json.Unmarshal works the same way. IMHO, not exac…

Unless there's something I missed, json.Unmarshal works the same way iff you have a struct that matches the JSON data very closely. If the JSON data is a little more free-form, you're stuck with a map of interface{}. Having to muck about with types is just a little tedious compared to JavaScript where there aren't really any types and anything can concisely be converted to a string. (I did a little project involving JSON a while ago in Go, but I'm hardly an expert at the language, so if I missed something, I apologize for the misinformation.)

In retrospect, I think I may have overstated it a little bit, and I doubt this problem would crop up too often for most apps.

Re: To boldly go where Node man has gone before

#72

Post by chc »

kitsune_ wrote: post #41
kbd wrote: post #2

So does Go's net/http module really provide basically exactly the same programming model as Node? If so, why use Node? One thing the author didn't mention is that Go will use multiple cores in this example, whereas Node is single-threaded. Right?

I doubt it does. net/http looks like a basic http listener? As such, the comparison looks biased to me. Mind you, I don't know much about node.js or Go.

Isn't Node's http.Server also a basic HTTP listener? What's the distinction you're trying to draw?

Re: To boldly go where Node man has gone before

#73

Post by blantonl »

I consider myself a pretty conservative developer when it comes to the tools that I use, and mainly stick to the core LAMP stack for my deployments - MySQL, Apache, PHP etc. I've ventured down the path with MongoDB and currently use it for one special use case where the data served is static.

But for Node - I've really come to the conclusion that it is a great tool for back end API work, such as serving very short requests, Ajax calls, etc. Couple the ability to develop in Javascript while serving JSON makes Node a really nice place to develop in.

Plus, performance is off the charts for my API serving applications. On a dev instance I can serve close to 5500 reqs/sec for one of our APIs where PHP was at about 1000 req/sec. And the difference in memory usage is fantastic.

BTW, our production Node deployment is Node, with the memcache, mysql, mysql-pool, cluster, and express modules. I've been thrilled so far.

Re: To boldly go where Node man has gone before

#74

Post by blantonl »

hack_edu wrote: post #46
xxbondsxx wrote: post #7

Choosing Node.JS isn't just a performance / scaling decision for me -- one of the main draws to Node is the huge community and wealth of awesome modules. Socket.io, Now.js, cradle, redis, and dozens of other modules abstract away the tedious work and let me build functionality _really_ fast. Go is really promising but it won't win over the majority of casual developers until there's a community around it. I might as…

> one of the main draws to Node is the huge community and wealth of awesome modules. Socket.io, Now.js, cradle, redis Really? In my experience, all but the most mature modules are hardly beta-quality and in constant flux. Find a good module for your job? Too bad it only runs on 0.4. Find another to get around that; oops, too bad your version of gcc needs to be patched and re-built. The language and its entire package…

I'm using cluster, crypto, express, memcached, mysql, and mysql-pool in production and they have worked flawlessly for a node deployment that serves a pretty busy JSON API (200-300 reqs a sec on average).

Re: To boldly go where Node man has gone before

#76

Post by euroclydon »

arturadib wrote: post #60

Node is popular not only because it's very fast (yes, it's still pretty darn fast even if there might exist faster alternatives), but because it's JavaScript. That's an enormous advantage for startups as (a) the JavaScript hiring pool is much larger than most other languages (particularly in comparison to nascent ones, like Go), and (b) the ability to write client- and server-side code in the same language means smal…

I think any person who can write an application in Node could also do it in Go, plus if your having trouble attracting good developers, [edit] Go, not node [/edit] should make the position more attractive.

Re: To boldly go where Node man has gone before

#78

Post by josephcooney »

bdr wrote: post #29

The point of Node is that it uses JavaScript, and browsers only speak JavaScript. You have three choices: (1) use Node, (2) duplicate code client- and server-side, or (3) use server-side code that compiles to JS. Right now 3 is the least popular (and 2 is the most) but I think it will end up being the accepted solution in a couple years.

Or use a plug-in in the browser that speaks your language of choice.

Re: To boldly go where Node man has gone before

#79

Post by exogen »

"Easy to build, fast, scalable."

So which part of the test demonstrated that it was hard to build, slow, and/or not scalable?

If you're not impressed that JavaScript reached 80% parity with a statically typed, compiled language – well, sorry dude.

Anyway, nobody is begging you to be impressed. 99.999% of successful projects are built with technology that is completely unimpressive.

Re: To boldly go where Node man has gone before

#80

Post by zemo »

jlarocco wrote: post #17
paufernandez wrote: post #10

Earlier quoted context omitted.

As we are commenting here, the community is assembling by the minute... Go allows you to import "github.com/user/package" and will download and compile the code, so creating a new project is even easier than with node, no need to "npm install ..." first. For a taste of what's out there, see: http://go.pkgdoc.org/index .

The GitHub thing was neat the first time I saw it, but then I thought about it some more, and I'm not sure it's such a good idea. I couldn't find any way to specify a specific tag or revision, so it's basically always getting the bleeding edge developer build of the library code. That might be nice in some situations, but for getting work done I almost always want the most recent stable release. Am I missing somethin…

if the repository owners tags a commit with the tag Go1, it is used by Go. If there is no tag to specify which commit, the tip of master is used. In practice, most maintainers just keep master clean and do all development in a dev branch.
Post reply on HN