<p>Does golang provide better performance for backend api end point than nodejs? Here I'm talking about when a user access the end point. Is there any performance/speed difference?</p>
<p>Edit: restful api.. sorry for confusion</p>
<hr/>**评论：**<br/><br/>juicemia: <pre><p>There's no blanket answer. Generally these things depend on what you're doing. </p>
<p>Build some prototypes that are as close as possible to what you actually want to do, and test them out. That's really the only way to know for sure. </p></pre>tmornini: <pre><p>You're right, of course, but unless you're a NodeJS master and a Go novice, Go is very likely to blow the doors off NodeJS in every respect.</p>
<p>1) memory usage</p>
<p>2) request latency, average and standard deviation</p>
<p>3) throughput, particularly on a multi-core system</p>
<p>4) high open connection situations</p>
<p>5) deployability</p>
<p>It's hard for me to wrap my head around how well suited and brutally efficient Go is for API handling.</p></pre>juicemia: <pre><blockquote>
<p>unless you're a NodeJS master and a Go novice</p>
</blockquote>
<p>Out of all the things you listed, I would say that's the one that matters the most.</p>
<p>At the scale that 90% of use cases operate at, what matters more is how fast someone can execute.</p></pre>titpetric: <pre><p>I don't know about you, but I picked up Go very much faster than Node. It took a few months before I completely discarded Node because of every bullet point, and some others which just deal with language libraries and syntax.</p>
<p>Most of the time spent in node was choosing between the mess that are npm packages and I'm going to say poor documentation of stdlib. Trying <code>yarn</code> which is touted as a good replacement to npm (<em>edit), but constantly gives issues forcing you to rebuild npm packages, like <a href="https://github.com/sass/node-sass/issues/1918" rel="nofollow">node-sass</a>. Don't let the issue being closed fool you, that means nothing in Node world. *Nothing.</em></p>
<p>Go shines with it's excellent standard library and the choices third party packages aren't trivial like some often mentioned examples in Node (isarray, is-array, left-pad, etc.). Even with non-trivial node apps, it just becomes ridiculous to understand even how many times you can declare a closure in Node and what's the difference between those declarations. Syntax wise it's a mess. Callbacks, promises, async/await, closures and arrow functions, no concept of concurrency (pcntl fork? Is it the 90's?) and you have to bolt on process managers to scale <em>beyond a single cpu core</em>, like PM2? REALLY?</p>
<p>Go can scale to whatever number of cores without adding a process manager on top. I think that's a fucking great benefit to anybody who's even thinking of Node today. Or even PHP, which is kind of the same, <a href="https://serversforhackers.com/c/php-fpm-process-management" rel="nofollow"><em>but worse, much worse</em></a>.</p>
<p>Here's like <a href="http://leanpub.com/api-foundations/c/FREEDOM" rel="nofollow">10 free copies of API Foundations in Go</a> for fucking <em>anybody</em> who's a Node guy/girl and is looking at Go. Just take the plunge and notice that your mood improves, you're sleeping better and there's no ambiguity to <a href="https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions" rel="nofollow">which type</a> of <a href="https://developer.mozilla.org/en/docs/Web/JavaScript/Closures" rel="nofollow">closure syntax</a> you should use. Binding functions into an object context? I think the reason why I survived so long as a programmer is the ability to put these random facts and nuisances very deep in my psyche so they only come out to play during my worst nightmares. Who doesn't like night terrors?</p>
<p>Edit: p.s. I feel like I should add the fact that Go has a fucking <em>standard library testing and benchmarking toolchain</em>. It wasn't mentioned in the bullet points specifically, but given that node has so many different ass libraries that deal with this shit (sencha, ava, mocha, ...), and people actively advocate moving from one to the other for I don't know which reasons, and I even find it ridiculous that there should be a <em>third party</em> package that implements <em>code coverage</em> (hello <a href="https://www.npmjs.com/package/istanbul" rel="nofollow">istanbul</a>). F... just... I have 99 questions and all of them are ELI5 "Why do planes fly?" but "Why does Node even work?".</p>
<p>Edit2: copies are gone. That was 20 copies like poof. If anybody genuinely wants to learn Go (as opposed to people who just collect free ebooks and never read them) and have somebody who you can ask questions about how to do X or Y, send me a DM and I'll probably send you some extra copies. Also Discord Gophers is a nice location to rant/be serious, you can join me there: <a href="https://discord.gg/PxwHvBS" rel="nofollow">https://discord.gg/PxwHvBS</a> ;)</p></pre>juicemia: <pre><p>Those are all valid points as to why Go is better. And to be clear, I used to be a JavaScript developer. Now I'm a Go developer. I like Go much better, for all the reasons you stated and more. But I think it's silly for us to assume OP's situation will absolutely call for Go just because we like it better for all the reasons you stated above. It really depends on what OP is trying to do. There's never a straight up answer to "Is X better than Y?" Pointing out the flaws in JavaScript and Node doesn't really answer OP's question, which is about performance. </p></pre>titpetric: <pre><p>Well if you want to be abstract about it, literally any premise can be answered with "it depends". Go is set up for scaling and performance that doesn't require the use of external process management, thus being less complex (and relevant to OPs question). If you'll ever need that complexity is another thing, so whatever people tend to implement in Node or PHP still somehow seem to work, even if you're, you know, not as critical to all these things. Or somehow you managed to pick a better tool for some specific job - which I guess you also can't, without knowing all these bullet points :)</p></pre>juicemia: <pre><p>There's nothing abstract about "it depends." It really does depend on what he's trying to do. The question is open-ended.</p></pre>tmornini: <pre><blockquote>
<p>I think it's silly for us to assume OP's situation will absolutely call for Go</p>
</blockquote>
<p>I'm not sure what you mean by "absolutely call for Go" means. It's not exactly the nuclear option...</p></pre>juicemia: <pre><p>I mean that we can't assume his use case will be worth him using Go over Node.</p></pre>tmornini: <pre><p>We don't need to, he didn't ask for that.</p>
<blockquote>
<p>his use case will be worth him using Go</p>
</blockquote>
<p>Why the word "worth?"</p>
<p>Does Go have some hidden costs -vs- NodeJS that I'm unaware of?</p></pre>juicemia: <pre><blockquote>
<p>Does golang provide better performance for backend api end point than nodejs?</p>
</blockquote>
<p>If you stick either in front of a database that crawls that needs to be accessed over a spotty VPN and communicate with three other services to help aggregate its data, they are both going to be slow. Go might not be better in that case. That's why it depends.</p></pre>__crackers__: <pre><p>Musta missed the freebies :( I'll be quicker next time!</p>
<p>One minor thing. From the description of the book:</p>
<blockquote>
<p>This book is the destillation of more than a decade of web development experience</p>
</blockquote>
<p>*distillation</p></pre>titpetric: <pre><p>Maaan, I have to run a spellcheck through this. I'm gonna give you a special link in the DM as a thank you :)</p>
<ul>
<li>Also: maybe I can just pay somebody some reasonable amount of money for editing services? If somebody does that, DM me. Keep in mind that the book is in markdown, and <em>just</em> running a spellcheck through it is not exactly what I have in mind when I say editing :)</li>
</ul></pre>kjin0815: <pre><p>Nooo I want the copy. Thanks for your points. I am really open to moving to a completely different language, and based on your comment, I might transition to Go!</p></pre>titpetric: <pre><p>Added 5 more copies, grab one quick.</p>
<p>Edit: boy they Go quick. For the people left out, consider buying <a href="https://leanpub.com/b/golang-app-bundle" rel="nofollow">it bundled</a> for $12. My wife buys books from this income, so go buy her a book.</p></pre>kjin0815: <pre><p>:)</p></pre>tmornini: <pre><p>I agree 100%</p></pre>tmornini: <pre><p>I answered OP's question:</p>
<blockquote>
<p>Does golang provide better performance for backend api end point than nodejs?</p>
</blockquote>
<p>OP didn't ask "should I use NodeJS or Go?"</p></pre>juicemia: <pre><p>You said it was brutally efficient and well suited for it. There's no doubt that it is. That's why I love it.</p>
<p>What you didn't say was that it's faster, which is what his question was, because you can't possibly know the answer to that. OP didn't even say what he was trying to do.</p></pre>tmornini: <pre><p>I'm not sure what you mean by this.</p>
<p>He said he was developing an API -- which I assumed (my bad, but I was right!) meant HTTP API.</p>
<blockquote>
<p>What you didn't say was that it's faster</p>
<blockquote>
<p>2) request latency, average and standard deviation</p>
<p>3) throughput, particularly on a multi-core system</p>
</blockquote>
</blockquote></pre>juicemia: <pre><blockquote>
<p>unless you're a NodeJS master and a Go novice</p>
</blockquote>
<p>Out of all the things you listed, I would say that's the one that matters the most.</p>
<p>At the scale that 90% of use cases operate at, what matters more is how fast someone can execute.</p></pre>tmornini: <pre><p>While that's true for scale, it's NOT true for latency.</p>
<p>Tons of evidence says latency is a critical ingredient for end users...</p></pre>juicemia: <pre><p>That's very true. I don't disagree. What I'm saying is that what's even more important than latency is actually having the application and that works correctly.</p>
<p>It's better to get something implemented first, and then solve the performance issues when you actually know you have them, than to try fixing latency issues that don't exist yet by using tooling that you aren't familiar with.</p></pre>tmornini: <pre><blockquote>
<p>What I'm saying is that what's even more important than latency is actually having the application and that works correctly</p>
</blockquote>
<p>Not in all cases.</p>
<p>If we're offering our wisdom about what's most important for OP, rather than simply answering his question, I'll counter your assumption that working-and-correct is more important than working-and-correct-and-fast/quick by suggesting perhaps he has needs you don't fully understand.</p></pre>juicemia: <pre><blockquote>
<p>I'll counter your assumption that working-and-correct is more important than working-and-correct-and-fast/quick by suggesting perhaps he has needs you don't fully understand.</p>
</blockquote>
<p>Read the thread man.</p></pre>chewxy: <pre><p>An exported function of a package is technically an API you know</p></pre>titpetric: <pre><p>Since he's coming from Node, he might have issues understanding what you mean by "exported" or "function" or "package"</p></pre>kjin0815: <pre><p>I should have said Restful API...</p></pre>
