Trying to understand the benefits of GO

<p>I am relatively new to web development but i have used Python with Django and i have read a few chapters on Node. I am trying to analyze the differences and benefits between Python, JavaScript/Node, and GO. If any of what i said is wrong please let me know, i am interested in learning.</p> <p> </p> <p>From my understanding the old ways such as with Python and Django were that the WSGI server(for example) handled one request at a time per process. You either start another instance to accommodate requests or you dont. This can be bad because with many requests(millions to billions) you have to wait on each I/O request, which in most cases will take longer than the task at hand. Alternatively if you have a task that is long running/CPU heavy then you can start a new thread that handles the task, return a message to the request to free up the WSGI, and when the thread finishes send another message. There are alternative ways of doing things, similar to Node with Tornado/Twisted.</p> <p> </p> <p>Node takes a different approach by doing things asynchronous. This can be better in some ways because the server handling requests doesn&#39;t need to wait on I/O. Long I/O? No problem, handle other requests while you wait and when it&#39;s ready get back to it to finish the task. Everything is still done on the same loop though. The downside is that this is bad for long running/CPU heavy tasks since it will hold up the main loop from processing other requests. You could start a new process for each request(cluster) but that is relatively heavier than a thread and so it may not be ideal. Because multithreading isn&#39;t supported, parallelism is only between cores(1 thread per core max). You can program in the Node environment using JavaScript but it is a dynamically typed language, meaning type checking will for the most part be deferred until runtime which will slow performance down. I say for the most part because the V8 engine does type inferencing during compile time but the performance improvements is nothing compared to a statically typed language.</p> <p> </p> <p>From what i know about GO is that it has something called goroutines which is similar to threads but about 500x less expensive in terms of memory. They also cost less to start/stop. This is because they are just really a bunch of blocks running on a thread. When goroutine A starts it does its thing until it either finishes or runs into I/O which it then lets the next goroutine run, and so forth. The good thing about this is that a goroutine waiting on I/O doesn&#39;t block the entire thread. To my understanding goroutines accomplishes the same thing as Node callbacks except it does concurrency more efficiently? Another upside to GO versus Node is that GO lets you easily do parallel work by distributing the goroutines to other threads through GOMAXPROCS. This let&#39;s you maximize your core processors unlike Node. Finally GO is statically typed, meaning type checking will be done at compile time rather than at runtime where it can slow down your program. Type checking at compile time will also offer extra reassurance that your program doesn&#39;t break down the line.</p> <p> </p> <p>Sorry i know this was long but in conclusion it seems like GO does the best of both worlds, that is the more traditional way of doing things(Python, C, Java, etc) and the async Node way of doing things but better. Are there any advantages to using JavaScript/Node or something like Python/Django? Have i missed any of the major benefits to GO?</p> <hr/>**评论：**<br/><br/>ansible: <pre><p>A lot of the appeal of Go vs. node.js is that the code is more straightforward. Callbacks based code breaks up an algorithm into pieces, which can be harder to write and reason about. Managing concurrency is more explicit. With Go, you write the simple case (handle one client at a time), and then just put that in a goroutine. You still need to be careful about any shared state, of course.</p></pre>qudat: <pre><p>Coroutines exist in node now with ES6/7, it&#39;s no longer a reason to choose python or go over node</p></pre>IntellectualReserve: <pre><p>Coroutines are far more difficult for me to reason about than goroutines and channels. Maybe that&#39;s just because I haven&#39;t fully grokked them yet. </p></pre>thraxil: <pre><p>There are a few difficulties with the event-based approach taken by Node, Tornado, gevent, libuv, etc. First, especially with Node.js, the callback approach to structuring code gets very complicated very fast. There are various approaches to mitigating this, futures, promises, deferreds, etc. But they all introduce additional conceptual overhead. Second, they require constant attention and care. If your code blocks on I/O or CPU at some point, your entire process and all clients it was serving are blocked. This requires constant vigilance when writing code and evaluating libraries that you might pull in. This is where Node.js has an advantage over, eg, Tornado. Javascript has never had any kind of proper concurrency at the language level so any Node.js modules you use, you can be fairly confident were written with this taken into consideration. On the other hand, if you&#39;re using Tornado, it&#39;s very easy to import a python module that wasn&#39;t written with an event loop in mind and just makes a blocking network call somewhere deep down.</p> <p>The &#34;traditional&#34; threading model in many languages has its problems as well. First, the relatively heavy weight of most thread implementations limits the number of threads you can practically run at a single time. Second, while it&#39;s usually easy to start using threads, it&#39;s also usually easy to share data between threads, often without realizing that you&#39;re doing it, which quickly leads to race conditions and data corruption, unless you add a bunch of locks, which can quickly lead to bottlenecks and deadlocks, killing much of the concurrency that you were trying to achieve in the first place.</p> <p>IMO, neither of those are really ideal. Both quickly lead to &#34;traps&#34; for inattentive programmers and difficult to reason about code (either callback hell or mutex hell).</p> <p>Go (and Erlang, and other languages that have lightweight processes and message/channel semantics for communicating between them rather than shared variables) offers a better middle ground where you can write relatively straightforward code and have a good shot at getting it correct without nasty race conditions or deadlocks. That&#39;s not to say that you can&#39;t end up with those in these languages if you really try, but the common patterns should at least steer you away from them.</p> <p>OTOH, a mature framework like Django or Rails is going to come with a lot of out of the box functionality and a large ecosystem of libraries and resources. I do mostly Django development for my day to day work and as much as I love Go, it will be a long time before Go can match something like Django for rapid development of relatively typical CRUD/REST web applications.</p></pre>qudat: <pre><p>Conceptually coroutines are difficult to grasp at first as well. Node, python, c#, golang and others are all seemingly converging on preferring coroutines for async tasks.</p></pre>Frenchiie: <pre><p>Are goroutines and message passing slower than threads trying to access that shared data through a lock/mutex?</p></pre>synn89: <pre><blockquote> <p>Are there any advantages to using JavaScript/Node or something like Python/Django?</p> </blockquote> <p>Rails, Python, PHP, Java, etc have been around for a long time so they have very mature libraries available. </p> <p>Most projects also really don&#39;t need blazing fast speed. So traits like being easier to code in and having a large selection of libraries to pick from can weight more than performance.</p> <blockquote> <p>Have i missed any of the major benefits to GO?</p> </blockquote> <p>Yes. Go is designed to be structurally simple as a language so large teams can work on a project and their code won&#39;t look like a mess. Java had a similiar design philosophy and it worked well for the language.</p></pre>dhdfdh: <pre><p>This is the way I look at Go. It&#39;s C with benefits. And you can do anything with C. The benefits include additions to the language for handling OO-like modules, templates for the web, and built in threading with goroutines and channels, servers, and all those things I do now with C and structs (and can now consider myself a genius for doing them for years :) ).</p></pre>Frenchiie: <pre><p>Is it really C with benefits though? I do see a lot of things from C but GO doesn&#39;t let you self manage the memory. I think the structs is a nice feature too btw.</p></pre>dhdfdh: <pre><p>Some would call that a benefit, too. </p></pre>Frenchiie: <pre><p>If it&#39;s low latency sure. Still, i wish GO would give the option to do self memory management. From my understanding it&#39;s trying to be an all around language but a systems language at the core. I don&#39;t think that&#39;s possible without giving programmers at the very least the choice to manage their own memory. Also it seems they have a competitor, Rust, that DOES let the user manage their own memory.</p></pre>the-tomster: <pre><p>Something like C or Rust gives you the option of manually managing memory, but that doesn&#39;t automatically make your programs faster. Whether your memory is managed by GC or manually you need to pay attention to avoid frequently allocating memory.</p> <p>If GC time becomes a problem you could set up a pool of the frequently used objects and manually manage them. You&#39;d get 90% of the benefits of manual memory management while avoiding memory management bugs in the rest of your code.</p> <p>edit: I just noticed that the <a href="http://blog.golang.org/qihoo" rel="nofollow">Qihoo 360 and Go</a> post from today shows the impact of these kinds of optimizations.</p></pre>Frenchiie: <pre><p>Didn&#39;t know about the Pool aspect of Go, interesting feature. Still not the same thing as being able to manually free up memory here and there but this does help.</p></pre>RSoreil: <pre><p>You are trying to figure too much of it out from reading advertising, just use the languages for a bit and see how they shake out. The is no clear winner for the most part.</p></pre>Frenchiie: <pre><p>I wouldnt call it advertising, this is mostly my understanding of how everything works. I&#39;m just trying to understand what makes GO great. Is it because it&#39;s fast? How fast? Is it some cool feature? Does it scale well? Node works great for serving non-CPU heavy tasks to many connections in a short time. Can GO with it&#39;s goroutines do a better job? Why shouldn&#39;t i keep using Python? Why should people move to Go? From what i know, and i may be wrong, it seems like Go is the clear winner. I&#39;m just trying to get peoples feedback that have previously used these other languages and technologies on huge services to see how everything compares.</p></pre>LimEJET: <pre><p>Go isn&#39;t &#34;super-fast&#34;, but it is compared to Python and Node. Go usually benches slightly ahead of Java, which is a respectable place to be.</p> <p>Scalability depends on a lot of factors, most important of which is code quality. If your code is built with it in mind, absolutely Go is scalable. The main reason for which is that goroutines are very easy to manage. Compare the workflow for goroutines with doing threads in python or child processes in Node. In Go, you just hand your function a channel and send it off. In Python, you need to make sure that any variables are instances of threading.local so that you don&#39;t get collisions, and then after everything is finished you have to explicitly join all threads.</p> <p>Basically, what it comes down to is that Go has less compulsory boilerplate for basically any given project.</p> <p>There&#39;s also the &#34;compiled&#34; aspect. No external libraries make Go programs very easy to deploy. Want to throw your application on a new server? Just move the executable. No need for the target system to install anything.</p> <p>Also, as far as I know the Node runtime is A LOT heavier than the Go runtime (which comes bundled in the compiled executable), so you can cut down on hardware cost by running weaker hardware and getting basically the same results.</p></pre>Frenchiie: <pre><p>Hmm you say Go isn&#39;t super fast but then what is? There aren&#39;t a whole lot of languages that are. C/C++ sure but what else? You even said Go benches slightly faster than Java and from what i know between Java and C/C++ there isn&#39;t anything else. Sure quality code is a big part of it but if the foundation is weak to begin with it wont matter all that much</p></pre>LimEJET: <pre><p>Is &#34;what else&#34; really a relevant question here? And what do you mean by &#34;foundation&#34;?</p></pre>Frenchiie: <pre><p>Well i would think so since you are saying Go isn&#39;t very fast. As opposed to what then? By foundation i mean the internals of a language(including vm, standard interpreter, etc)</p></pre>LimEJET: <pre><p>I said Go is pretty fast compared to Java. That does not mean that &#34;Go isn&#39;t very fast&#34;! What it means is that you can take a look at benchmarks of java and know that Go places above it (which is useful since Java benchmarks are everywhere). As for your definition of &#34;foundation&#34;, Go doesn&#39;t have a VM or an interpreter. It&#39;s a compiled language with a minimal runtime that handles GC and thread allocation. All else is native code.</p></pre>cryptos6: <pre><p>You said that java would be the &#34;more traditional way of doing things&#34;, but I think that this assessment is a bit smattering. Java has very good support for multithreading and async programming and it gets even better with Scala. Please don&#39;t exclude java from your list of possible technologies because some hipsters are saying something else is cool now. Take a look at the Akka framework for example. And with Scala you get a more concise and powerful language compared to Go. So, have a look before you go the Go way. </p></pre>