<p>So I've decided to dip my toes in the Go pool and I find it extremely fun and refreshing (coming from a dynamic background, who knew static typing could be so useful).</p>
<p>I will primarily use Go for api servers and there are a few questions I have:</p>
<p>1) Go obviously doesn't have an event loop, so how does a Go server handle multiple requests at the same time? I've read about goroutines but all the different "web framework" hello world examples I've seen don't seem to make use of them.</p>
<p>2) How can I setup automatic recompilation on file changes? Something like "go watch" doesn't seem to exist.</p>
<p>3) Any articles with examples comparing Go code and node code doing the same thing? I've read most of the "Resources for new Go programmers" from the sidebar.</p>
<p>Thank you for reading. :)</p>
<hr/>**评论：**<br/><br/>peterhellberg: <pre><p>2: You can use gin to do code reloading on change: <a href="https://github.com/codegangsta/gin">https://github.com/codegangsta/gin</a></p></pre>torwori: <pre><p>This looks like what I thought I needed, thanks!</p></pre>peterhellberg: <pre><p>You are welcome.</p>
<p>Also, my favorite tool to run tests when a file in the project change: <a href="https://github.com/jpillora/spy/" rel="nofollow">https://github.com/jpillora/spy/</a></p></pre>j1436go: <pre><p>In answer to 2)
Godo is a pretty good task runner:
<a href="https://github.com/go-godo/godo">https://github.com/go-godo/godo</a>
A makefile with <code>watch make ...</code> works also pretty well.</p></pre>EclecticMind: <pre><p>Comparisons between Node.js and Go are plenty but you need to specify what you're looking for. An article about someone's success story, or the event handling technical differences. </p>
<p>Like others mentioned, every http request runs independent of one another. Think of them as asynchronous, except they look like regular functions and you don't even need to pass a callback! Isn't it nice?</p>
<p>Recompiling files on the fly isn't hard, but which files are you talking about? Go, or templates and such? I would check out reflex. Gin became a pain in the ass to deal as I created more projects. Gin is basically a proxy to your app, whereas reflex just reruns the command you give it when you change a file that's being watched. Think of gulp or grunt file watching then running a task. </p>
<p>Simplify your life by not worrying about asynchrony and speed for now. Goroutines are simple, I would add them in after you figured out the other stuff. </p></pre>torwori: <pre><p>I'd like to see both successes and differences.</p>
<p>When you put it that way, yeah, it looks awesome!</p>
<p>Reflex/gin both seem to me like the thing I was looking for.</p>
<p>Thanks for the advice! :)</p></pre>tagesticket: <pre><p>1) I would rephrase this as Go doesn't expose the event loop directly. The event loop exists in Go, but is managed by the runtime. A simplified view of how it works is the following:</p>
<p>You write all your code as blocking synchronous code which runs in execution contexts called goroutines. These are similar to threads with the primary difference being that they are managed by the go runtime and not the OS. The runtime can detect when your code is at a blocking call boundary such as a read or write. If it knows you'll be waiting for the result of some operation it runs code from another goroutine until that piece of code blocks.</p></pre>torwori: <pre><p>So essentially, I can think of (in my case) every request spawning a goroutine which does it's own thing, all the while being completely non-blocking (one goroutine waiting on a db call or read/write will mean nothing for the others). Is this right?</p></pre>tagesticket: <pre><p>Exactly. If you're using the net/http library then the server does exactly this. You provide it with a handler that is called for every request. Each request is then processed in its own goroutine by the handler. There are some catches to be aware of though. All the magic the runtime does won't work if you call into a C library. In that case the call will be fully blocking. An example would be if you had accesses to a sqlite database.</p></pre>torwori: <pre><p>Good to know, thanks!</p></pre>pierrrre: <pre><p>1) a simple HTTP server: <a href="http://golang.org/pkg/net/http/#ListenAndServe" rel="nofollow">http://golang.org/pkg/net/http/#ListenAndServe</a>
It creates a new goroutine (lightweight thread) for each HTTP request.</p>
<p>2) Press "ctrl+C" and run your program again</p>
<p>3)
<a href="https://gobyexample.com/" rel="nofollow">https://gobyexample.com/</a>
<a href="https://golang.org/doc/effective_go.html" rel="nofollow">https://golang.org/doc/effective_go.html</a></p></pre>idiomatic: <pre><blockquote>
<p>2) Press ctrl-C...</p>
</blockquote>
<p><a href="https://github.com/idiomatic/seppuku">or have code that watches for file change and automatically exits</a>.</p></pre>ecmdome: <pre><p>Your username ></p></pre>jerf: <pre><blockquote>
<p>Go obviously doesn't have an event loop, so how does a Go server handle multiple requests at the same time?</p>
</blockquote>
<p>Go doesn't "have" an event loop, Go <em>is</em> an event loop. In the way you know the word, all Go code is always asynchronous, all the time.</p>
<blockquote>
<p>I've read about goroutines but all the different "web framework" hello world examples I've seen don't seem to make use of them.</p>
</blockquote>
<p>net/http is automatically spawning one goroutine per request, so you don't see it. They're still there and you can still use them freely.</p>
<p>The other two I can't really cover. I'm not a huge fan of automatic recompilation on change, but I freely acknowledge that's just a taste thing and there's nothing wrong with it. I'm more into compilation errors showing up in my editor. Perhaps if you mention and/or Google, you can find out how to turn that on in your editor, as it's useful either way.</p></pre>jerf: <pre><p>I have to admit I'm at a loss as to what's so horrible about this post. It really is the best way to explain Go to a Node user.</p></pre>torwori: <pre><blockquote>
<p>net/http is automatically spawning one goroutine per request, so you don't see it. They're still there and you can still use them freely.</p>
</blockquote>
<p>This is the explanation I was looking for, thanks!</p></pre>
