1
15
16

Go vs Node.js for servers (self.golang)

Keithによる前の投稿

I've been advocating Go to a friend who's in a position to make this choice. I googled for "Go vs Node.js" articles, but there's surprisingly little on the web comparing the two (and what's there is pretty bad and uses bubble sort as a basis for comparison).

Basically, unless you're going to get a lot of value out of being able to reuse code on the client and the server, I just don't see any reason to choose Node.js over Go for the types of things you'd use Node.js for.

That's how it appears to me, but I'm looking for reasonable counterarguments so I can help my friend make an informed decision that's not just based on my biases. Thanks!

all 13 comments
sorted by:
best
best
トップ
新着
注目
論争中
古い順

[–]kingnebula 38 ポイント39 ポイント 前

I have used both in production. I have been using Node.js for about 3 years now (I was a very early adopter. "JAVASCRIPT ALL THE THINGS!!!").

I have also been using Go for about a year now. I can tell you first hand, if you go with Go (see what I did there?), you will save yourself MASSIVE amounts of headache.

Javascript is very fast. Yes this is true, V8 is very fast... however, only if you are benchmarking a simple benchmark. As soon as you start adding in complex application logic all that performance goes out the door because the virtual machine has a very difficult time correctly inferring the type and thus not being able to optimize. But if your application consists of a tight loop, it will be fast.. so its got that going for it :D

Node.js: Callback hell. Must I say more? With Go, you can have each connection use a different Goroutine and use "blocking" IO AND still have better performance than Node.js. Why? because you aren't really blocking, while some IO operation is being performed on that goroutine, the scheduler does work on other goroutines/connections. So you get all the benefits of non-blocking IO without callback hells. There is absolutely NO REASON to have callback spaghetti when you can simply let the runtime take care of the nauseating details.

In my 3 years of full time node.js development, I have honestly only had ONE occasion where I used the same 4 lines of code both in the server and in the client. I shit you not. There is no merit to the claim that you use the same code on the server and on the client. SURE... if you were writing a simple game and you wanted to replicate the game logic on the server to make sure nobody is cheating... it might be useful. But really ask yourself if you want to perform complex logic on the same thread that everybody else that is trying to reach the server is waiting on. No, you don't.

Ohh and did I mention Node.js isn't really all JavaScript? A good portion of the pakcages on NPM are also written in Coffeescript. Hope you don't mind learning another language to deal with a package you depend on. So much for using the same language for both server and client!

With Go you get type safety. This CANNOT be overstated.. except to maybe ruby-ists(jk jk! don't shoot me). Also, you get a unified tool-chain for pretty much everything you need from formating to getting modules.

The one benefit you have with Node.js over Go is the massive number of packages available on NPM. But most of them are useless abandoned junk. So, even that is questionable.

Testing: Lets just say that in Node.js/Javascript you would have to write tests that check the type of a variable. tsk tsk tsk... This is the only way to properly test JS and make sure nothing crazy is going on. OR!!!! here is a revolutionary idea!! let the damn compiler do it for you! MIND BLOWN!!!

Anyway that is my two cents. I hope I didn't come across as a Node.js hater.. but having dealt with its warts and limitations for the past 3 years, I would only wish it on my worst enemy.

Good luck

[–]blitzkriegpunk 4 ポイント5 ポイント 前

Mmmmyip. @kingnebula knows what's up.

[–]WatchDogx 0 ポイント1 ポイント 前

Please use /u/kingnebula notation rather than twitter notation.

[–]pinpinbo 1 ポイント2 ポイント 前

Agreeing in all front. JS weak typing is horrible. Truthiness hell in all places.

The only time I ever shared logic between server and client is for: stringlib, datetimelib, numberlib, etc.

Callback hell is no joke, even in node.js land I use promise style code nowadays, via q.

In the mean time... Go's small memory footprint is no joke. 5mb RAM for websocket daemon. WTF, are you kidding me?? So awesome.

That said, I have encountered situation where goroutine is not cleaned up properly. But that's probably caused by my noobishness.

[–]campoy 5 ポイント6 ポイント 前

You might like this:

http://blog.safariflow.com/2013/02/22/go-as-an-alternative-to-node-js-for-very-fast-servers/

[–]Keith[S] 2 ポイント3 ポイント 前

This is funny, I'm watching you on FLOSS Weekly right now (well, I paused it to read the article...).

Thanks for the link.

[–]optymizer 2 ポイント3 ポイント 前

Some great answers here. I think I have some things I could share that you might find interesting. I'm the sole developer on a large and ambitious project. I created the first prototype in PHP, rewrote that in Nodejs, and then rewrote it again in Go.

Node.js advantages:

  1. [because of JS] native, arbitrary JSON handling, optional arguments, adding dynamic properties to objects makes objects much more expandable (you can keep adding properties to objects without affecting the rest of the code much).
  2. package management and versioning (npm is awesome)
  3. the idea that you could reuse some code on both client and server.

Node.js disadvantages:

  1. Installation. It's supposed to be easy, right? Not for my project. Some libraries I used required a C++ compiler. They're supposed to work with 'pure javascript', but the speed is unacceptable (the project uses heavy encryption). Installing on a Mac required Xcode, Xcode Tools, a Developer account, 2GB download, etc. It's just the worst installation experience, unless you can have all your libraries be in Javascript, in which case you can get away with requiring 'Node.js'.
  2. Callback hell. You can't tell what your code is doing anymore, especially if you have conditional execution of some callbacks in a loop based on the result of the first callback. It's extremely messy. Even with async.auto() and async.parallel(), it can get hairy. The last straw was when some callback changed a 'group' var that was shadowing a previous declaration, and it caused the final callback to never be fired. Hours and hours of debugging. So much fun. I don't like to lose control over what my code is doing, and callbacks and abstractions do exactly that - they remove you from the details, and sometimes, the devil is in fact in the details.
  3. Testing Javascript. What a mess. Young, unreliable libraries. You spend days just trying out libs to see if they work for you. You write your tests in one lib, the next day it's obsolete and unmaintained. Oops.
  4. Coffeescript. Like I need another abstraction and yet another build step, and another obstacle between the code and the debugger. I don't want to use it, but other libs are using it, so now you need to learn it to be able to read/edit/contribute/fix coffeescript stuff.

And then along came Go.

Go advantages:

  1. Do parallel stuff asynchronously, like in Nodejs, with no callback hell. Most of the time, you want to fire off these parallel jobs, and then block until the jobs are done. It makes no sense to return until those jobs are done. This is hairy in Javascript, and so elegantly done with Go channels.
  2. The syntax, the Go tools (building, testing, benchmarking, profiling, coverage) are fast and amazingly useful.
  3. Massively useful built-in library. Everything from HTTP to Elliptic encryption.
  4. Installation! Compile and ship. No dependencies.

Go disadvantages:

  1. Some things are slower than expected (the math/big library, JSON encoding/decoding)
  2. OOP is deeply engraved in most people's brains, and Go doesn't do that. I found that I can usually do it simpler without using OOP, but it takes effort and experimentation to get things right.
  3. Package management is fairly primitive, but it works. My biggest gripe is that I can't group files into subfolders, because then I have to declare them as being part of a different package. And you can't have package A require sub-package B, while sub-package B requires A, because it's a circular dependency. Nothing one can't work around, but packages in Nodejs are better designed.

[–]dkuntz2 0 ポイント1 ポイント 前

Go supports OOP... It uses composition instead of inheritance, but it has object-oriented paradigms...

Would you also make the claim that JavaScript doesn't support OOP because it's prototypical and not classical?

[–]drvd 4 ポイント5 ポイント 前

Go code is much more readable and lacks all these nasty JavaScript glitches. In Go there even is no need for a === comparison operator.

[–]divoxx 2 ポイント3 ポイント 前

They are completely different worlds. I don't think anyone that writes Go will advice to use Node though.

Being very simplistic, a few of the benefits of Go over Node would be: type safety, great concurrency without callback hell, and simpler deploys with static binaries.

[–]runtimeintrospection 0 ポイント1 ポイント 前

I really dislike Javascript, but Node is interesting. It's main selling point is that everything you write is automagically concurrent. Even in a language that implements concurrency well like Go, it is mental overhead. Not having to think about threads or alternatives to them at all is nice.

Also being able to use libraries like jQuery server-side and send DOM to the client is a nice advantage of working in straight Javascript.

[–]xionon 1 ポイント2 ポイント 前

Node's pseudo-concurrency is based an event loop and callbacks. I think you'll find that there's the same amount of mental overhead involved in dealing with callbacks or promises as there are with threads and message queues, but obviously it's a different type.

[–]aaronblohowiak 0 ポイント1 ポイント 前

Profiling node.js programs is a pain in the ass, especially as you have to track time usage through callbacks. With Go's builtin pprof toolset, you can easily locate performance (CPU OR Memory) problems.

When you do find performance bottlenecks, your optimization options are more limited in Node.js than what you can do with Go because Go exposes reference vs value semantics to the user -- and this extends to using embedded structs. Depending on what you are doing, leveraging better memory layout/access can greatly improve your performance.

Go's deployment story is better, but node's dependency management is better.

In general, Go is lower-level and that control comes at a cost of ramping-up and trading off some runtime flexibility. Go's type inference keeps the visual burden of types-in-code to a minimum (though it isn't HM.)