News for hackers. Stuff that matters.
Re:To boldly go where Node man has gone before by xxbondsxx on Wednesday May 16, 2012 @02:47PM (#3983420)
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 well write a webserver in C if I'm only concerned with performance

Re:To boldly go where Node man has gone before by hack_edu on Wednesday May 16, 2012 @04:19PM (#3983818)
> 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 ecosystem is so immature, I'm blown away people trust it in production at all.

"So fix it and submit a Pull Request," you say? That doesn't help me when I'm trying to deliver on a deadline. I love contributing, but I often have more pressing things on my plate.

Re:To boldly go where Node man has gone before by zzaman on Wednesday May 16, 2012 @04:31PM (#3983881)
In my 6ish months of programming in Nodejs full-time, I have yet to run into a library that only runs on 0.4 only or requires my version of gcc to be patched and re-built. Which Node libraries were you trying to use?
Re:To boldly go where Node man has gone before by blantonl on Wednesday May 16, 2012 @06:31PM (#3984397)
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 by mbthomas on Wednesday May 16, 2012 @07:35PM (#3984640)
As a counterpoint, I built a relatively large system using Node (this was a couple months ago, to be clear) and had issues with several modules. mysql: cannot handle binary blob columns (this is just now being fixed in an alpha version of the library). mysql: very slow parsing of large responses. aws*: many half built / half broken libraries -- nothing that met our modest needs. request: (http request library) found several issues.

Node.JS has a great community that is writing many great modules, no doubt. But the community is very young and almost by definition many of the modules are immature.

This can be very enjoyable from an engineering perspective (you get to write and hack on things that you would not otherwise), but can also slow down the process of building things since you do end up having to reinvent the wheel at times.

Re:To boldly go where Node man has gone before by blantonl on Wednesday May 16, 2012 @08:01PM (#3984709)
In our case, it isn't a large system. Our node production environment serves up a smallish set of API/Ajax requests that are heavily used. With that, we've been able to eliminate more than a few Web servers that otherwise had to load the entire Apache/PHP stack just to serve a small 20-100 byte request.

With your response in mind - I don't see Node being mature enough (yet) to solely support an end-to-end large scale Web property. But, for serving up API content from Memcache/MySQL - it is blazing fast with minimal footprint. On our stack - we run Node right on our existing Apache Web servers (behind haproxy).

Re:To boldly go where Node man has gone before by paufernandez on Wednesday May 16, 2012 @02:56PM (#3983468)
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.

Re:To boldly go where Node man has gone before by jlarocco on Wednesday May 16, 2012 @03:13PM (#3983529)
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 something?

Re:To boldly go where Node man has gone before by vito on Wednesday May 16, 2012 @03:21PM (#3983563)
I hit this a while ago. The first thing I tried to install failed, because it depended on something that depended on something that moved its repository location (renamed itself from foo.go to foo).

It's a convenient hack but nothing more.

Re:To boldly go where Node man has gone before by zemo on Wednesday May 16, 2012 @07:21PM (#3984595)
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.
Re:To boldly go where Node man has gone before by paufernandez on Wednesday May 16, 2012 @03:27PM (#3983597)
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.
Re:To boldly go where Node man has gone before by ConstantineXVI on Wednesday May 16, 2012 @03:57PM (#3983719)
Kind of a clunky way to handle versioning though. In Lein (for example), adding

    [noir "1.2.0"]
ensures I'm always grabbing the same version. In Go, appears the only way to guarantee this is to check in the full source of the library alongside your own in your repo.
Re:To boldly go where Node man has gone before by jamii on Wednesday May 16, 2012 @04:22PM (#3983839)
I wish Leiningen would also handle bleeding edge dependencies as easily as rebar eg:

    {deps, [
      {quoted, "1.0.3",
        {git, "git://git.corp.smarkets.com/quoted.erl.git", {tag, "1.0.3"}}},
      {proper, ".*",
        {git, "git://git.corp.smarkets.com/proper.git", {branch, "master"}}}
    ]}.
Re:To boldly go where Node man has gone before by ConstantineXVI on Wednesday May 16, 2012 @05:34PM (#3984139)
This plugin[1] looks like what you're looking for.

[1] https://github.com/tobyhede/lein-git-deps

Re:To boldly go where Node man has gone before by jamii on Wednesday May 16, 2012 @07:26PM (#3984610)
"You will also need to manually add the checked-out project's dependencies as your own (the plugin simply checks out the code, it doesn't recursively resolve dependencies)."

I've seen this plugin before but its not particularly useful without dependency checking. It's a start though. I'll have to look at leiningen to see if it exposes hooks for that sort of thing.

Re:To boldly go where Node man has gone before by cageface on Wednesday May 16, 2012 @09:59PM (#3984993)
I also consider it a huge plus that Go produces a single, statically linked native binary. No fiddling around with directories of libraries and search paths required.
Re:To boldly go where Node man has gone before by KaoruAoiShiho on Wednesday May 16, 2012 @03:20PM (#3983561)
npm is awesome, this direct import doesn't seem like a feature, more like a lack of a feature.
Re:To boldly go where Node man has gone before by paufernandez on Wednesday May 16, 2012 @03:33PM (#3983620)
It works very well for me. If I want someone to install a Go program I've developed, in Ubuntu 12.04 they can just:

  $ sudo apt-get install golang
  $ go get github.com/pauek/garzon/grz
That's it, and it takes a few seconds.
Re:To boldly go where Node man has gone before by nilliams on Wednesday May 16, 2012 @04:06PM (#3983757)
That's great to quickly show someone a program, but not so great if they try it a few weeks later and get a non-stable version of your program, otherwise that definitely won't be it, they'll have to spend some time figuring out what went wrong.

If Go adds some method to specify a tagged version that could be pretty nice though.

I hope it goes without saying that there's no way this kind of hack (neat as it is) is a substitute for a proper package management system like npm (which is a very good package manager).

Re:To boldly go where Node man has gone before by substack on Wednesday May 16, 2012 @05:59PM (#3984263)
This is a nifty feature and npm can do something very similar:

    npm install git://github.com/substack/node-optimist.git
Re:To boldly go where Node man has gone before by KaoruAoiShiho on Wednesday May 16, 2012 @04:51PM (#3983957)
How's that any faster than

  npm install express
Not only do npm handle versioning for you, you also don't have to remember the host or username. Obviously Go is a younger community, and could make a package manager some day, but I'm puzzled by how you're comparing this positively with npm.
Re:To boldly go where Node man has gone before by paufernandez on Wednesday May 16, 2012 @05:44PM (#3984192)
It is faster because you don't have to install npm, the case I was explaining involves someone with no developing skills.

And I'm not saying this feature of Go is better than npm, I also use npm and I like it very much. What I like is the fact that Go comes already with this feature and I don't need anything extra.

Re:To boldly go where Node man has gone before by rje on Wednesday May 16, 2012 @07:58PM (#3984704)
I believe that npm is now included as part of all node distributions.
Re:To boldly go where Node man has gone before by KaoruAoiShiho on Wednesday May 16, 2012 @04:52PM (#3983963)
Oh I get it, you're talking about from a package developer's standpoint. Not having to register your package with a central directory does save a bit of time for you I guess.

But when installing packages, I have to say, npm is fantastic.

Re:To boldly go where Node man has gone before by baudehlo on Wednesday May 16, 2012 @05:59PM (#3984261)
You don't have to do this with npm either. You can provide a URL to a tarball or a git repository and npm will install from there.
Re:To boldly go where Node man has gone before by baudehlo on Wednesday May 16, 2012 @05:58PM (#3984254)
And npm ships with node, so this is no different.

Furthermore npm can install git URLs directly too, including tags and branches if you need a particular one. Just specify the url as the "version" in your dependencies section of package.json. Totally trivial.

Re:To boldly go where Node man has gone before by peterwwillis on Wednesday May 16, 2012 @03:43PM (#3983654)
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!

Re:To boldly go where Node man has gone before by m0shen on Wednesday May 16, 2012 @05:26PM (#3984101)
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 on code written in C. Finally, has a large and active community ( Madison NAPC is sold out )?

And Perl isn't even on your radar?

Re:To boldly go where Node man has gone before by sciurus on Wednesday May 16, 2012 @10:52PM (#3985139)
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.

http://hop.perl.plover.com/

Re:To boldly go where Node man has gone before by kisom on Thursday May 17, 2012 @07:35AM (#3986475)
It's not hip and exciting anymore and generations of poor Perl coders have everyone convinced Perl code must always look ugly.

I'm a fan of C and Python myself, but I always chuckle at all the Perl hate.

Re:To boldly go where Node man has gone before by m0shen on Tuesday May 22, 2012 @10:55AM (#4008098)
That should read: YAPC::NA
Re:To boldly go where Node man has gone before by erjiang on Wednesday May 16, 2012 @02:57PM (#3983470)
Go has a growing number of packages for things that you might want to interface with: http://go-lang.cat-v.org/pure-go-libs and http://golang.org/pkg/ There are already packages for most databases, data interchange formats, crypto, etc. that most people want to use.

Another draw of Go that you didn't mention is the language and toolchain design itself. I know Javascript better than Go, but would rather write servers in Go than JS.

Re:To boldly go where Node man has gone before by mkramlich on Wednesday May 16, 2012 @08:48PM (#3984831)
> one of the main draws to Node is the huge community and wealth of awesome modules.

If you think Node has a huge community and wealth of awesome modules wait til you to discover the older and more mature languages/platforms, like Python, C, Java, etc.

"What I like about Justin Bieber is the massive history of his career, spanning decades, and the broad range of his musical style across several genres." :)

Re:To boldly go where Node man has gone before by daliusd on Thursday May 17, 2012 @02:33AM (#3985757)
It is funny because I have chosen Node for one my project because I have not found easy way to do that in Python. I must say I really love Python - it is my favorite programming language. I could do the same project in Python but node.js looked slightly better and faster in this case.

Programming language is just a tool - one from many tools you can choose to make your projects and node.js have done some basic things better than Python (e.g. packaging). I have learned to love JavaScript and it is really good language now. Still there are projects I wouldn't choose node.js as my tool.