"Should use Go for webapps that scale". What does that really mean?

<p>what is lacking in other languages when it comes to scaling?</p> <hr/>**评论：**<br/><br/>jerf: <pre><p>The answer is always complicated and varies depending on your local needs. But one generic answer is that many of the dynamic scripting languages popular today are miserably, miserably slow, and despite the common meme that it won&#39;t matter because the languages will always &#34;be stuck in IO&#34; it turns out not to be the case. A language that is faster and better at using multiple CPUs can serve potentially an order of magnitude or sometimes even two orders more than such a language, and even in &#34;the cloud&#34; using 10x or 100x fewer servers is nothing to sneeze at.</p></pre>theonlycosmonaut: <pre><blockquote> <p>A language that is faster and better at using multiple CPUs</p> </blockquote> <p>Wanted to add: some of these languages have poor concurrency stories, like Perl and Python, though the situation appears to be on the way to improving in many cases.</p></pre>jerf: <pre><p>At this point I&#39;m ready to call it: The attempt to add threading support 10 years or more after the fact to the dynamic scripting languages has failed. None of them have really successfully pulled it off. And merely dropping in an &#34;event loop&#34; is just sort of the barest minimal support for concurrency that can be imagined... I find it truly bizarre when someone holds it up as a revolutionary step, or somehow the epitome of concurrency support.</p> <p>I don&#39;t believe this to be fundamental to the paradigm. I think if someone set out to write a 1990s-style dynamic scripting language and built in threading from day one, it would work fine. However, the window of opportunity for new 1990s-style dynamic scripting languages has pretty much closed.</p></pre>theonlycosmonaut: <pre><p>Fair enough. I just double checked, and it appears both Python and Ruby are adding cooperative concurrency. Not quite what I thought in Ruby&#39;s case. An improvement, but nothing like real green threads.</p></pre>agonopolskiy: <pre><p>everything scales....its just how it &#39;scales&#39;, linearly or exponentially with the amount of data/requests, so its a fairly useless statement by itself. I would say that there is nothing go that will make &#39;your webapps scale&#39;. Every language is suited for specific tasks and has tools that make certain tasks easier then others, but ultimately you can make everything slow in any language, and given enough time you can figure out to make most languages &#39;scale&#39;</p> <p>Go makes it easier to write decoupled components that can then be easily distributed, but just like any other language you can also dig yourself in a hole if you don&#39;t know what your doing. </p> <p>That being said, anyone who would tell me to &#39;use go for webapps that scale&#39;, I&#39;d personally put in the digging their own hole because they don&#39;t know what they are doing category</p></pre>ecmdome: <pre><p>Built in concurrency is one huge factor that helps you scale.<br/> A low memory footprint is another. Significantly faster than something like python and rails in most cases. Compilable code allows you to easily run it without external dependencies.</p> <p>All of that, and the standard library has everything you need to build a modern scalable web application.</p></pre>RSoreil: <pre><p>Not having to rewrite the entire thing and not having hardware costs scale to a point where it becomes prohibitively expensive.</p> <p>The only time where this phrase is used is when talking to people using obviously slow as shit languages or sometimes when using languages that encourage writing code which simply becomes a nightmare with a lot of nodes / traffic.</p></pre>Fwippy: <pre><p>&#34;app that scales&#34; is just new talk for &#34;the servers are gonna cost you a lot of money, so it&#39;s worth making your code fast&#34;</p></pre>klaaax: <pre><p>first what do you mean by scaling or it&#39;s just yet another empty sentence that sounds ridiculous ... and nobody ever said that but you,so you can remove the quotes.</p></pre>