Static typing + no callbacks make Go vs Node a no-brainer, IMO. I'm doing mainly iOS work these days but I've been brainstorming ideas that require a server component just so I can use Go for something.
What do you mean by "no callbacks"?
To boldly go where Node man has gone before
101–110 of 124 posts
Re: To boldly go where Node man has gone before
#102Node 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.
[deleted]
Re: To boldly go where Node man has gone before
#103Earlier quoted context omitted.
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 I wanted a specific tag or release, I would just download that revision in the GOPATH directories, and refer to the package directly, instead of through the github URL.
[deleted]
Re: To boldly go where Node man has gone before
#104Earlier quoted context omitted.
You might like Perl too. Edit: haha I love how people downvote this like i'm being sarcastic. Down with Perl, that horrible language with a community and modules 100x larger than Node!
I don't understand the attitudes either. While I enjoy writing Javascript for Node, when other Node users tell me they hate Perl, I can do nothing but give them a blank stare. So you want an environment that is easy to program in a functional style with closures and first class functions. Has a large ecosystem, including hundreds (thousands?) of packages to do asynchronous IO. Is easily extensible and can fall back o…
For the curious, I recently took some simple examples I'd seen in node.js
https://github.com/semmypurewal/node-talk-examples/
and translated them to Perl.
https://github.com/sciurus/anyevent-plack-examples
If you're interested in functional programming, I've learned a lot from the parts I've read of Higher-Order Perl.
Re: To boldly go where Node man has gone before
#105I 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 re…
Out of curiosity, how were you running PHP?
Re: To boldly go where Node man has gone before
#106Static typing + no callbacks make Go vs Node a no-brainer, IMO. I'm doing mainly iOS work these days but I've been brainstorming ideas that require a server component just so I can use Go for something.
What do you mean by "no callbacks"?
You can do non-blocking I/O without the nested callbacks you have to use for everything in Node. You just fire off a block to a goroutine and then code sequentially there.
Re: To boldly go where Node man has gone before
#107Node 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…
This. What attracted me was the fact that Javascript on the server. Javascript for the client, and Javascript for the database (MongoDB) seemed much more appealing than 3 separate languages. (Normally a PHP/MySQL dev)
Re: To boldly go where Node man has gone before
#108Earlier quoted context omitted.
What do you mean by "no callbacks"?
You can do non-blocking I/O without the nested callbacks you have to use for everything in Node. You just fire off a block to a goroutine and then code sequentially there.
In the short term:
https://github.com/laverdet/node-fibers
In the long term:
Re: To boldly go where Node man has gone before
#109Earlier quoted context omitted.
You can do non-blocking I/O without the nested callbacks you have to use for everything in Node. You just fire off a block to a goroutine and then code sequentially there.
In the short term: https://github.com/laverdet/node-fibers In the long term: http://wiki.ecmascript.org/doku.php?id=harmony:generators
Both look useful, but aren't exactly well-supported by the library ecosystem. In Go, faux-blocking I/O is standard, and all the libraries support it; it's not something bolted on as a handy afterthought.
Re: To boldly go where Node man has gone before
#110This test shows Node handling 100 requests simultaneously just as easily as handling them separately. However Go's memory usage increases by about 5X. So what happens when you reach 1000 simultaneous requests? Which will perform better then? I think this is called "selection bias."
Not only that, but Node actually got faster as simultaneous connections increased while keeping a completely stable memory footprint. The benchmark showed the opposite of what the author claimed -- Node scaled effortlessly. Its performance was completely stable and predictable under load, whereas Go's wasn't.
Not to knock Go -- it's a beautiful language, and absolutely faster than Javascript for most purposes (and will no doubt increase in stability and speed as time goes on). But this post had some pretty flawed analysis of the benchmark presented.