Go as an alternative to Node.js for Very Fast Servers
techblog.safaribooksonline.com
Go as an alternative to Node.js for Very Fast Servers
1–10 of 147 posts
Re: Go as an alternative to Node.js for Very Fast Servers
#2Node: 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
Re: Go as an alternative to Node.js for Very Fast Servers
#3Node: 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
[deleted]
Re: Go as an alternative to Node.js for Very Fast Servers
#4I'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.
Re: Go as an alternative to Node.js for Very Fast Servers
#5While JavaScript drags the scars of its hasty standardization around with it, Go was designed very thoughtfully from the beginning, and as a result I find that it’s a pleasure to write.
This is very true. Go is a pleasure to write. In fact, it's such a pleasure then when you hit something that wasn't really well designed it's horrid.
Re: Go as an alternative to Node.js for Very Fast Servers
#6The 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.
Re: Go as an alternative to Node.js for Very Fast Servers
#7Node: 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
Yes, but at what point does go transition from obscurity to PG's "python paradox"?
http://www.paulgraham.com/pypar.html
It sure seems Scala's in this "python paradox" land now. My guess is that you need some startups make it big using Go to evangelize it. Google using it is interesting, but I'm not sure it makes it "cool".
Though, I'm not sure Java was ever a language you could use as a skillset filter. Hm.
Re: Go as an alternative to Node.js for Very Fast Servers
#8I'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 development so well.
Re: Go as an alternative to Node.js for Very Fast Servers
#9I played around with a go server to do some simple scaling numbers - looking at possibly using go to implement a large-number-of-idle-connections notification server.
I found the (good) result that I could spawn a new goroutine for each incoming connection with minimal (~4k) overhead. This is pretty much what you'd expect since a goro just needs a page for it's stack if it's doing no real work. I had something like 4 VMs each making ~30k conns (from one process) to the central go server with something like 120k conns.
I found one worrying oddity however. Resource usage would spike up on the server when I shut down my client connections (e.g. ctrl-C of a client proc with ~30k conns).
Reasoning about things a bit, I think this is due to the go runtime allocating an OS thread for each goro as it goes through the socket close() blocking call. I think it has to do this to maintain concurrency. So I end up with hundreds of OS threads (each only lives long enough to close(), but I'm doing a lot at the same time).
Can anyone comment:
- is this guess as to the problem likely to be correct?
- is this "thundering herd" a problem in practice?
- are there ways to avoid this? (Other than not using a goro-per-connection, which I think it the only idiomatic way to do it?)
My situation was artificial, but I could well imagine a case that losing, say a reverse proxy, could cause a large number of connections to suddenly want to close() and it would be a shame if that overwhelmed the server.
Re: Go as an alternative to Node.js for Very Fast Servers
#10Node: 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
Yes, but at what point does go transition from obscurity to PG's "python paradox"? http://www.paulgraham.com/pypar.html It sure seems Scala's in this "python paradox" land now. My guess is that you need some startups make it big using Go to evangelize it. Google using it is interesting, but I'm not sure it makes it "cool". Though, I'm not sure Java was ever a language you could use as a skillset filter. Hm.
Pretty much anything Google does is cool. Probably same could be said about Amazon, Facebook et al.
Depends a lot on your interpretation of "Cool" though.