Live data from Hacker News

Go as an alternative to Node.js for Very Fast Servers

techblog.safaribooksonline.com

21–30 of 147 posts

Re: Go as an alternative to Node.js for Very Fast Servers

#21
post #18
post #6

The fact that Node.js is being used in this equation says a lot about how much impact and penetration it has achieved in a rather short while. Personally I hope that Go does just as well, if not a lot better. I am a bit of a fan of both.

I think it says more about the bias of the writer, he seems to assume that Node would be the default choice and that something like erlang/scala/clojure/go would be alternatives. That may be true for someones sideline project.

If he's a HN reader, he's probably assumed that Node is the default choice these days, based on the articles that come up.

Re: Go as an alternative to Node.js for Very Fast Servers

#22
post #11

I run node/express for most of my web servers and each takes up about 10-15mb RAM. They're very basic no fluff. Anyone know what comparable mem footprint in Go?

Here's a quick paste from a server of mine: ps aux | grep api ubuntu 15720 0.0 0.1 107024 6136 pts/0 Sl 15:13 0:00 bin/api_server

IIRC ps displays the resident size in KiB, so you're looking at 6 MB for a Go process. Not terrible for a high-level language.

Re: Go as an alternative to Node.js for Very Fast Servers

#24
post #12

I have never understood the focus on speed as a selling point for Node. It may well be very fast, but it seems to me that the primary selling points would be the ability to share code between client and server and that you can start coding server side without learning a new language if all you know is JavaScript.

Compared to Python and Ruby, node.js is quite fast by the simple virtue of having a JIT (in the most common implementation anyway; of course there are JITs for Python and Ruby but they aren't the mainline implementation).

Re: Go as an alternative to Node.js for Very Fast Servers

#25

Node: Everyone knows JavaScript, there's a massive community, there are tons of libraries, and you get very good performance Go: No one knows this language, there's a small-but-growing community, there are enough libraries to get a lot done, and you get even better performance Java: They are paying me (money!) to write in this language

The Go community on Reddit is already bigger than the Node community: http://www.reddit.com/r/golang (3730) http://www.reddit.com/r/node (3581)

Re: Go as an alternative to Node.js for Very Fast Servers

#26
post #23

[deleted]

> Shouldn't that be "Go-lang" because we all agreed to call it Golang? I might be missing something.

I'm the one missing something, because I'm not sure who 'we' are, or when 'we' all supposedly agreed to this.

In any case, you should probably inform the authors of the spec, because they apparently missed this memo too[0]!

[0] http://golang.org/ref/spec

Re: Go as an alternative to Node.js for Very Fast Servers

#27
post #4

I've been using Go a lot lately. It's difficult to overstate just how much simpler it makes writing highly-concurrent server-type programs. Entire classes of bugs, issues, and puzzles just vanish.

I've been using Go a lot recently as well, and it's rapidly become my go-to language (no pun intended) for a lot of problems, even when concurrency is not involved. The biggest thing Go gives me is that it's really easy to manage code bases that grow organically - refactoring a project that grows from 50 LOC to 5000 LOC is almost painless in Go - no other language that I've seen has dealt with this aspect of code dev…

What about Go makes it easy to manage and refactor large codebases? I don't do much Java, but whenever I've watched someone use Eclipse for refactoring, I question why I'm still using vim, because it is just magic and does everything for you.

Re: Go as an alternative to Node.js for Very Fast Servers

#29
post #4

I've been using Go a lot lately. It's difficult to overstate just how much simpler it makes writing highly-concurrent server-type programs. Entire classes of bugs, issues, and puzzles just vanish.

I've been using Go a lot recently as well, and it's rapidly become my go-to language (no pun intended) for a lot of problems, even when concurrency is not involved. The biggest thing Go gives me is that it's really easy to manage code bases that grow organically - refactoring a project that grows from 50 LOC to 5000 LOC is almost painless in Go - no other language that I've seen has dealt with this aspect of code dev…

"The biggest thing Go gives me is that it's really easy to manage code bases that grow organically"

Very interesting to hear. Any chance you could expand on this a bit more?

Re: Go as an alternative to Node.js for Very Fast Servers

#30
post #22

Earlier quoted context omitted.

Here's a quick paste from a server of mine: ps aux | grep api ubuntu 15720 0.0 0.1 107024 6136 pts/0 Sl 15:13 0:00 bin/api_server

IIRC ps displays the resident size in KiB, so you're looking at 6 MB for a Go process. Not terrible for a high-level language.

Yep, just ran ps_mem.py (http://www.pixelbeat.org/scripts/ps_mem.py) and here's my entire server. Not a busy one, but it lets you see what a running api server and accompanying programs look like.

    Private  +   Shared   =  RAM used	Program

    184.0 KiB +  31.5 KiB = 215.5 KiB	atd
    240.0 KiB +  55.0 KiB = 295.0 KiB	cron
    240.0 KiB +  68.0 KiB = 308.0 KiB	upstart-socket-bridge
    304.0 KiB +  72.0 KiB = 376.0 KiB	upstart-udev-bridge
    392.0 KiB +  79.0 KiB = 471.0 KiB	sudo
    696.0 KiB +  26.0 KiB = 722.0 KiB	dhclient3
    604.0 KiB + 189.0 KiB = 793.0 KiB	getty (6)
    940.0 KiB +  49.0 KiB = 989.0 KiB	dbus-daemon
    660.0 KiB + 366.0 KiB =   1.0 MiB	udevd (3)
    1.0 MiB +  71.0 KiB   =   1.0 MiB	rsyslogd
    1.1 MiB +  35.5 KiB   =   1.1 MiB	redis-server
    1.0 MiB + 122.5 KiB   =   1.2 MiB	init
    964.0 KiB + 733.0 KiB =   1.7 MiB	polkitd
    1.4 MiB + 823.5 KiB   =   2.2 MiB	console-kit-daemon
    2.5 MiB +   1.1 MiB   =   3.6 MiB	nginx (5)
    1.3 MiB +   3.2 MiB   =   4.6 MiB	sshd (5)
    5.4 MiB +  75.5 KiB   =   5.5 MiB	api_server 
Post reply on HN