<p>Don't get me wrong, iojs is a cool project. But as far as I can tell Go does about the same thing as iojs without callback hell and dealing with an interpreted language. </p>
<p>I haven't studied either of these all that intensively. This is just what it seems like to me. </p>
<p>When would you choose one over the other? </p>
<hr/>**评论：**<br/><br/>albatr0s: <pre><p>No, there is no reason.</p></pre>ThisAsYou: <pre><p>That's what I keep coming too.</p>
<p>With Go out of the picture, iojs is awesome. I'm also glad they both exist (competition!) but Go seems vastly superior.</p>
<p>Only downside is there isn't a new framework for Go every other second... /s</p></pre>hoffentlich: <pre><p>Go will offer you a superior development experience.</p></pre>Saucysauce: <pre><p>Well, I think the best answer (for you) is : Go try both!</p>
<p>For me, I use Go for systems stuff, and Node for stateless services and web stuff. But I'm using Go for more and more services and Node just for web stuff. Eventually, I'll probably just be using Go.</p></pre>ThisAsYou: <pre><p>I've used both a little. I've made a url shortener in iojs, and played some with Go (haven't had much time this semester :/)</p>
<p>Anyway, Go has a much better coding experience (code completion is great for shitty programmers like me :p) Sure TypeScript is a thing, but then it's still JS in the end. The thing about Go is it's compiled. ONE binary to deploy. It's also faster, which can make a big difference with large-scale deployments.</p></pre>Saucysauce: <pre><p>Well, I might not completely agree with your reasons for choosing Go, but I think Go is a sound choice :) Honestly, I'd pick anything and invest in it more. It's hard to go wrong being a polyglot programmer.</p></pre>ThisAsYou: <pre><p>I didn't choose it JUST because I wanted code completion. That was just a nice touch.</p>
<p>The main reason I'm leaning towards it is because it seems like it would scale better, and have better performance per-node compared to Node.</p>
<p>When I'm paying for servers to host my projects, I want to get the most per $ as I can. So that's why I've been looking at Go after learning a bit of Node.</p></pre>Saucysauce: <pre><p>Agreed, sorry, wasn't meaning to imply your choice was simplistic :)</p>
<p>Well, performance is super-complex. Personally, I focus on time-to-deliver the project, then I optimize. But it's good to know <em>you can optimize</em>, and I'd say Go is better for that.</p></pre>ThisAsYou: <pre><p>Time-to-deliver is certainly an important factor. But with personal projects you have a lot more flexibility, which is the situation I'm in.</p>
<p>I currently have a url shortener in "production" at work which is using iojs. It works and all, but I really want to rewrite it in Go, especially since Go is much faster. That and my callback mess makes me feel disgusted :p</p>
<p>Go's easy concurrency and parallelism is really cool to me. Being able to spawn a goroutine for every request and have concurrency without callbacks is awesome. Oh and don't forget.... SINGLE BINARY to deploy!</p>
<p>Being able to go back to deploying a binary after messing with scripting languages and things like Java is really refreshing.</p>
<p>At first Go seemed really lame to me after getting used to OO in C#. But after learning some node OO doesn't seem quite as important.. </p></pre>Saucysauce: <pre><p>Ahhhh, well yeah, for personal projects, do whatever seems interesting :)</p>
<p>As an "old timer" (does 2 decades of programming make you an old timer? I feel like one), I will say that I was gung-ho about OO and used to be a bit of a bigot about objects in general. Age and wisdom have taught me that everything has it's place, and very few things are universal, so I totally agree that OO isn't as important as others may tell you.</p></pre>ThisAsYou: <pre><p>That said, OO can definitely be good for something. But as you say, there is no one size fits all in programming. </p></pre>Saucysauce: <pre><p>Absolutely. I still think OO is great for many applications (or applications that have only one view of their data model). But system-level work? Go is better.</p></pre>iends: <pre><p>This comment makes zero sense. </p>
<p>Go is an object oriented language. </p></pre>JuicyMeJacKanoff: <pre><p>I was in a similar position, go go and you won't ever go back!</p></pre>ThisAsYou: <pre><p>That's what I'm thinking :) What made you choose Go at the time?</p></pre>xsolarwindx: <pre><p>Yes, if you need to complement your thick glasses, scarf, starbucks coffee and macbook pro while looking like you're doing something useful.</p></pre>ThisAsYou: <pre><p>I don't get it? I don't have any of those things...</p></pre>nerdwaller: <pre><p>I think they are joking that Node is vogue, and hipster types are stereotyped to do all those things.</p>
<p><em>edit</em> I think I took you way too literally. Just got out of a long meeting about boring things. My apologies.</p></pre>ThisAsYou: <pre><p>No you're good. I took him too literally (I get the joke now.)</p>
<p>For some reason I thought I asked why you would use Go over iojs, meaning he was making Go the hipster language, so I was confused (as I see Go as a better language without much bias yet.)</p>
<p>I should really go to sleep earlier... </p></pre>nerdwaller: <pre><p>I could see where that could be the interpretation, arguably Go could be considered more hipster, but not sure I want to go down that rabbit hole of labeling things just to do it.</p>
<p>Go is great, node has uses as well. I personally prefer statically typed back ends, though I do have a Node server up so others in my small organization can contribute.</p></pre>ThisAsYou: <pre><p>You're probably right, Node deffinitly has more traction....</p>
<p>But anyway, I do tend to agree with you on static typing. While working with iojs, I ran into a LOT of undefined vars because of my compile time checks (which I'm sure could be motivated by linters or even TyoeScript) but having real static types is really nice. </p></pre>010a: <pre><p>Ironically it seems like, nowadays, Go has begun attracting the vogue hipster types. </p></pre>nerdwaller: <pre><p>Agreed, it'll always happen with something new that is good, the real problem is when people flock away from something good just because it's too "hipster" or for that matter too "mainstream"</p></pre>ptman: <pre><p>Go json encoding is apparently a bit slow because of the amount of reflection. If you do lots of json encoding/decoding, iojs may perform better</p></pre>ThisAsYou: <pre><p>Source?</p>
<p>That is unfortunate if it's true. But surely it would get better in the future right?</p></pre>dgryski: <pre><p>If you're encoding/decoding known types there are faster ways to use json. Go's code generation tools make it easy to construct packages like <a href="https://github.com/pquerna/ffjson" rel="nofollow">https://github.com/pquerna/ffjson</a> which are 2x-3x faster than using reflect. There are other serialization options that are even faster depending on your use case: <a href="https://github.com/alecthomas/go_serialization_benchmarks" rel="nofollow">https://github.com/alecthomas/go_serialization_benchmarks</a></p></pre>Effetto: <pre><p>The only cool feature of the 'server-side javascript' thing is that it opens the gates of isomorphic applications but I have yet to see actually usage of it in serious +mid-size applications.</p></pre>ThisAsYou: <pre><p>PayPal and Netflix are pretty big.</p>
<p>I still think Go is better, but Node is definitely in large-scale production use.</p></pre>Effetto: <pre><blockquote>
<p>PayPal and Netflix are pretty big.</p>
</blockquote>
<p>I was referring to the isomorphic feature. Yes node.js is large-scale ready itself.</p></pre>ThisAsYou: <pre><p>I'm completely blind today apparently <em>sorry.</em></p>
<p>What are these isomorphic features you speak of? What does that do?</p></pre>docsavage: <pre><p>Here's an <a href="http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/" rel="nofollow">article on isomorphic javascript</a>, and I agree with the Effetto -- the only reason I'd use node/iojs is for isomorphic apps, probably in React world. You could also remove running your own server like Google AppEngine and go with <a href="http://aws.amazon.com/lambda/" rel="nofollow">Amazon Lambda</a>. Lambda may allow non-javascript executables now, but initially it was focused on server-side javascript.</p></pre>ThisAsYou: <pre><p>Okay that is pretty cool. </p></pre>mwholt: <pre><p>I was going to say that with Node you don't have to worry about memory synchronization but that's not entirely true all of the time, even though Node is single-threaded.</p></pre>ThisAsYou: <pre><blockquote>
<p>Node is single-threaded</p>
</blockquote>
<p>Another thing that makes Go better...</p></pre>thraxil: <pre><p>I would only chose node/iojs if there were some existing domain specific JS library that I could leverage by putting a thin web shim on top of it and that would be very difficult and time consuming to port to Go. Even then, I'd try to contain that to as small a microservice as possible and build the rest of the system in a better language.</p>
<p>Other people seem to choose node because they already know JS, like it, and want to get something running without learning a new language for the server side. Fair enough.</p></pre>ThisAsYou: <pre><p>Yeah for current JS people, I can see it being appealing. But for anyone looking to use a new language, Go seems far superior. </p></pre>dpa: <pre><p>Node developer here. I would use node for web apps. Express is great, the stream pattern is insanely useful, ecosystem is vibrant. Add in promises, generators or use highland.js to avoid callback hell and node may become fun and fast to code in. </p></pre>ThisAsYou: <pre><p>Node/iojs definitely has a much larger web-ecosystem. But you can use something like React with Go.</p>
<p>Something I don't like about JS is how there is a new framework every other day.</p>
<p>Node is great, don't get me wrong. But as someone who is still in the learning phase, Go seems like a better language in general. Hopefully Go will get some good web frameworks though...</p></pre>afrobee: <pre><p>This a <a href="http://www.reddit.com/r/programming/comments/32jn2a/gotchas_from_two_years_with_node/cqc2hq5" rel="nofollow">great insight</a> about Nodejs true nature that one should consider commented by u/jerf</p>
<blockquote>
<p>Node is fundamentally cooperatively multitasking. We got rid of cooperative multitasking decades ago in our OSes, and apparently we raised a generation of programmers so unaware of the issues that not only did they embrace a cooperatively-multitasking environment on their server, of all places, they actually thought the cooperative multitasking was a feature and some sort of step forward.Further, observe this is not some sort of political statement or something that can be dismissed with more rhetoric. This is simply a truth... Node is cooperatively multitasking. Cooperative multitasking has serious, extremely-well-known problems with tasks causing other tasks to have resource starvation. It turns out these people hit those problems. These problems are really, really hard to solve in a cooperatively-multitasking environment... you can mitigate them but you can not solve them. We know this because trying to mitigate the issues with cooperative multitasking is not some sort of new computer science problem that just emerged in this brave new Node world for the first time ever, but something that entire major programming communities grappled with for decades without ever solving, including but not limited to the entire Apple programming community prior to OS X, which I'll remind you is properly pronounced "OS Ten", as in, 9 entire major versions preceding that with people trying to deal with this problem.
The shocking thing is not that there are very solid, time-tested reasons to think carefully about Node... the shocking thing is that these reasons are considered "controversial".</p>
<p>Node is a technology stack based on a language originally designed to animate things when a button was clicked (and I'll remind you, that's also not slander, that really is the origin of Javascript) that developed into a very well-understand dynamic scripting language with well-understood issues, using very old software techniques that have problems that are very, very well understood. The fact that these problems are in fact very well understood means that you may still find use cases where you can use this tech... "well-understood problems" is actually a good thing!... provided you do in fact understand them, which can not be done by trying to go up to the code and argue it out of having these problems, much less trying to argue them out of existence by debating with people.(It is so weird to me watching people trying to defend Node on this point. It's not like when Rust comes out with a new feature and people dismiss it with "Oh, someone wrote a paper on that in the late 1960s and implemented it in some obscure Lisp variant that died, so p'shaw on your claims of newness"... the Node scheduling paradigm was one of the dominant mainstream schedulers for decades at a time. It's not news! It's not something we have to wonder about what could possibly happen... we just open the history book, and there it is.)</p>
</blockquote>
<p>The OP post on this thread also have some of the gotchas and why the OP change from Node to Go</p></pre>icholy: <pre><p>If I was at a hackathon or writing a prototype, I'd probably use node.js because it's easy to bang something out quickly and there are tonnes of packages.</p></pre>ThisAsYou: <pre><p>Fair enough. What would you choose for production?</p></pre>icholy: <pre><p>I'm using Go in production right now and it's great.</p></pre>ThisAsYou: <pre><p>At what scale?</p>
<p>Would you want to use it in large-scale productions?</p></pre>iends: <pre><p>I rewrote a production node 0.10.x service in Go and got a 10-30% performance increase. </p>
<p>I rewrote a production db migration tool in Go and had approximately the same performance as the node 0.10.x version (probably because core node db stuff was c++) but I had much better type safety guarantees with Go. </p>
<p>YMMV. </p>
<p>Sadly my company is afraid of Go and used neither. </p></pre>jordic: <pre><p>Keep calm and leave javascript for the browser.</p></pre>metamatic: <pre><p>My perspective as someone who isn't wild about Go, and writes server-side JavaScript most days:</p>
<p>No. Hell no. If you can use Go, you'd be mad to choose JavaScript instead.</p></pre>ThisAsYou: <pre><p>This is the vibe I've been getting. Could you expand on your reasoning? </p></pre>metamatic: <pre><p>While I'm generally fine with dynamic languages (I like Ruby, for example), JavaScript has enough pitfalls that I fall into them on a regular basis. The server environment I'm working with is slow enough to deploy to, and ugly enough to debug in, that it's a real win to catch as many bugs as possible at compile time. While there are tools like jshint, they aren't as robust as a compiled and statically checked language. So I end up writing as much as I can in a compiled language (in my case, Java, since I'm in a JSF-based world), and then using the bare minimum of server-side JavaScript to glue things together. The thought of having to face debugging race conditions in the middle of a callback in a node.js application makes me realize how good I've got it.</p>
<p>Client side it's a different story, as tools like the Chrome developer environment make JavaScript debugging pretty easy, so long as you stick to VanillaJS. I'm not anti-JavaScript, I just find it horrible on the server.</p></pre>ThisAsYou: <pre><p>What are your most common pitfalls with JS? </p></pre>metamatic: <pre><p>Mostly the lack of type checking means that trivial errors, such as forgetting when a singular property is returned as a vector rather than a scalar, result in crashes. Also, nulls have a tendency to propagate beyond their immediate cause and result in unexpectedly empty values elsewhere.</p>
<p>Also painful is the narrow choice of data types — no true integers, no trees, and so on.</p>
<p>So generally I write as much as possible in Java, get it to run and pass all the unit tests, and only then bring the jar file into the server environment and write the JavaScript glue code. The interface methods dumb down values to strings or doubles, but internally more appropriate types are used.</p></pre>Raiyni: <pre><p>You can scale go much better and it is simple. </p></pre>ThisAsYou: <pre><p>In addition, it seems like Go wouldn't require as many servers due to the better speed of not being interpreted. Which translates to less servers and lower costs.</p>
<p>So for a new project, especially if you want to scale, Go seems like it'd always be better...</p></pre>quiI: <pre><p>I wouldn't pick a language based on whether it's interpreted or not, 9/10 your performance concerns are going to have little to do with your language choice. </p></pre>ThisAsYou: <pre><p>Interpreted languages are usually slower in general. So an optimized Go app will be faster than an optimized Node app.</p>
<p>When you have a choice in what language you're going to learn and use, why not go with the one that can go faster when optimized without too much extra dev time?</p>
<p>In addition, deployment is easier because you can build a single binary with Go. With iojs you need to also maintain the iojs version. Granted, Docker mitigates this issue. But being able to deploy a single binary is a lot easier and better IMO. </p>
<p>I'm not saying "everyone ever should use Go." I just think if you have a choice and no reservations for either language, Go is better. </p></pre>010a: <pre><p>One thing you need to keep in mind is that, while Go might be more performant (please stop using the word "faster") under most workloads, if your system ever communicates with an off-machine database then that communication is guaranteed to be the slowest aspect of both a Go and Node system. </p>
<p>There are plenty of benchmarks which say "look at this, I wrote a simple HTTP server and Go can serve 10,000 req/s where Node only serves 200", but the moment you have either of those machines talking to Postgres or Mongo I guarantee both of those numbers will drop to 100-300. </p>
<p>And this just reinforces the point that most people in these discussions seem to forget: Good programmers use Node for io-heavy workloads. It isn't good for compute workloads and thus really isn't comparable to Go in a lot of domains. That doesn't make it bad or worthless, it just makes it specialized. </p></pre>quiI: <pre><p>I dont know much about Iojs, but I've used <em>other</em> interpreted languages. </p>
<p>My point was, almost no one picks languages based on what executes fastest; at least, usually it should be low down on your priorities. Otherwise we'd all write assembly. People pick languages on a variety of factors such as the ones you've mentioned but also others. </p>
<p>You aren't considering how interpreted languages <em>can</em> be more expressive and easier to write than Go. </p>
<p>Don't get me wrong, I love Go. But I wouldn't use Go in favour of say Scala for a lot of problems. Is that because I think higher kinded types are <em>vital</em>?. No, it's all about tradeoffs. And If i am hacking together a proof of concept i am tempted to use a lightweight interpreted language to get it done. </p></pre>ThisAsYou: <pre><p>That's why I am advocating for Go rather than C++ :p</p>
<p>For prototypes though I agree, use whatever you can hammer out fastest. </p>
<p>Edit: really though, I don't know enough to make any decent arguments / assertions for Go. </p></pre>010a: <pre><p>This is a really uninformed and simplistic comment.</p>
<p>Scaling projects in either language is equally easy. The general way of scaling is to horizontally spin up new instances which sit behind a load balancer. You can do this with anything that supports HTTP and its 100% transparent to the language itself. </p>
<p>Scaling is <em>cheaper</em> with Go because generally speaking Go is more performant, sometimes by an order of magnitude. So what might take 3 node machines could be done with a single Go machine. </p>
<p>A correct statement is that you scale Go much more cheaply, not easily or "better". </p></pre>Raiyni: <pre><p>You are right, the correct term definitely would have been cheaper. Cheaper doesn't always equal better but when plenty of companies are switch from node/ruby/python to go for performance reasons does that indicate something? But you really only start noticing those problems when you reach crazy throughputs. An example would be twitter going from RoR to Scala (sure RoR has better scaling now). </p></pre>010a: <pre><p>Companies which run into performance problems or huge costs with things like Python, RoR, or Node are kind of what I refer to as the "1%" workloads. There are <em>many</em> top 50 websites which run on these languages. For example, Yelp is totally Python and Ebay and Paypal are almost totally Node. These languages work fine for them. </p>
<p>So while Go is undeniably faster, I don't really respect that argument for the language because the only people who are going to care are core engineers at Google or Facebook, and those people are probably using C++ anyway (or, in Facebook's case, PHP). The cost advantage that additional performance offers is also not half as expensive as the billable hours wasted finding or training Go engineers for most other companies.</p></pre>Raiyni: <pre><blockquote>
<p>(or, in Facebook's case, PHP)</p>
</blockquote>
<p>It's Hack now, which is basically php still.</p></pre>ninja_uzumaki: <pre><p>I think if you want to prerender a javascript application on the server side, you should go with Node/io js. For anything else, I prefer Go.</p></pre>ThisAsYou: <pre><p>Why not just use something like <a href="https://github.com/olebedev/go-react-example" rel="nofollow">React with Go?</a></p></pre>EstebanVelour: <pre><p>The node ecosystem is really, really worth learning no matter what server-side language you use. Tools like gulp/grunt have become the makefiles of js & css and will simplify your life immensely.</p></pre>Bromlife: <pre><p>I use Gulp & Bower with Go. As long as they're controlled from within Go, it's not a big deal. But man oh man do I hate having to write in NodeJS. Even for the Gulpfile.js - so many callbacks. So many, many callbacks.</p>
<p>So badly designed.</p></pre>nerdwaller: <pre><p>Promises definitely decrease that feeling, but those can still lead to really hard to read stuff that just have promises for no real reason. It is nice to <em>at least</em> have it read better without needing to jump around so much (when done well).</p></pre>ThisAsYou: <pre><p>That's one thing that really made me look at Go. I hate <a href="https://d262ilb51hltx0.cloudfront.net/max/800/0*w-CuLtR8aUeLTMvq.png" rel="nofollow">callback hell</a> and I'm really bad at staying out of it.</p></pre>010a: <pre><ul>
<li><p>Writing Node is much faster. You don't have to deal with weird compiler requirements like unusued imports, variables, etc, all of which eat up the most valuable and expensive resource a company has: A programmer's time.</p></li>
<li><p>Vastly superior package manager. NPM supports versioning, which alone makes it better than <code>go get</code>. </p></li>
<li><p>Much more configurable build process in NPM, Grunt, etc than the fairly limited and black-box <code>go build</code> tool. If you try to do anything in Go outside of the <code>go</code> tool, you'll hit a brick wall and end up needing a makefile, whereas its possible to deploy everything you need in Node with Node, from the project to the build process to even the <a href="https://github.com/foreverjs/forever" rel="nofollow">auto restart system</a>.</p></li>
<li><p>There are <a href="http://www.modulecounts.com/" rel="nofollow">many more packages</a> and third-party projects written in Node than in Go. </p></li>
<li><p>The act of deploying a node application is at least as easy as a Go application, and can be vastly easier with tools like Heroku, of which none exist for Go. </p></li>
<li><p>Go hits some performance bottlenecks when dealing with json marshaling due to its type system. </p></li>
<li><p><code>$GOPATH</code>. Enough said. </p></li>
</ul>
<p>If your main concern with Node is that it doesn't offer good type safety, then you can always look at TypeScript, a product which is actually used by Google for Angular 2. And before you say "but its really just JS in the end": Yeah, and Go is really just Assembly in the end, like everything else. TypeScript is essentially a zero-cost abstraction over JS. </p>
<p>Pitchfork disclaimer: I like both languages. If you want me to list five things great about Go to prove it, I will. </p></pre>ThisAsYou: <pre><p>Unused imports could be fixed using goimports. Unused vars is still annoying though. </p>
<p>You're other points are valid as far as I'm aware. What do you like about Go? :) </p></pre>010a: <pre><ul>
<li><p>Packages</p></li>
<li><p>Its the performance and garbage collection of Java with the syntax of something like Python. </p></li>
<li><p>Its statically compiled which makes deployment easier than something like Java or C++. </p></li>
<li><p>The standard tools are the best in class among any language. It has a full build tool, dependency management, and testing suite all rolled up into one. It even comes with specialized tools like <code>yacc</code> builtin. </p></li>
<li><p>The standard library is also best in class among any language. There is no other language that comes with full and sufficient implementations of http, json, zip, tar, compression, database drivers, image libraries... </p></li>
</ul></pre>zero_coding: <pre><p>I want to prerender javascript application on the server side too and I think Golang is not the best choice for that. How your guys think about that?</p></pre>ThisAsYou: <pre><p>From what I can see, you're right. But you could always mix <a href="https://github.com/olebedev/go-react-example" rel="nofollow">React with Go</a></p></pre>
