Go as an alternative to Node.js for Very Fast Servers

In C++ header dependencies are also a DAG, since include guards prevent cycles (and multiple includes). What makes Go faster are a few things: (1) C++ headers contain templates, which are slot to compile; (2) Go only looks at direct imports and uses the compiled form of those imports, rather than recursing over their imports (again); (3) Go is simpler to parse; and (4) there is no overloading, so symbol/method resolving is simpler.

I also think that the advantage is often overstated. C++ is a nightmare in this respect, C programs and libraries often compile very fast (on my current machines, running configure often takes much more time than the actual compilation), the same applies to e.g. Java code.

That's really helpful when refactoring,

And annoying for testing, the printf example has been beaten to death. (Yes, I know that you can add a line such as var use = fmt.Println).

But for those of us who don't trust our human brains as much and want to be absolutely sure that these silly errors don't slip through

It's always surprising how Go fans can sell a feature that any strong statically typed language always had (easy refactoring by letting the type system work) can sell as something unique and new ;).

But what I don't like: the negativity against Node and omitting some facts. In the replies of the orignal post a guy tested two (!) times Node and once it was significantly faster (v0.6) and once it had same speed (v8.0). So, why has mjijackson such different results in this thread at the top?? And maybe we should test it on real servers and not on a MBA. Moreover, we have here some micro benchmark which possibly doesn't reflect reality well. Don't get me wrong, I appreciate any benchmarking between languages but then please do it right and make no propaganda out of it. Further, Go's package manager seems to be nice but it does NOT have version control. How do you want to use this in a serious production environment. Maybe version control will come (but then tell how without loosing its flexibility) or not but this is something serious and definitely not an alternative to any server environment except for some mini services.

EDIT: downvoting is silly, propaganda and won't help the Go community in getting more credibility, better do some further benchmarks; otherwise this post/thread is full of distinct misinformation and should be closed

Go was such a huge relief after that horrible catastrophe language that seems to still continue to wreck new generations. Please, please, don't poison your career on focusing on a single language, especially one as disturbing as Haskell.

This is a small flaw in the go packaging system (and it is a flaw) which I'm sure they'll fix, either with a convention to always use branches for versions (which I guess is doable, but only if it becomes widespread), or by changing import to take an argument for the version. So something like:

    import "github.com/gorilla/mux/1.0.3"

    import "github.com/gorilla/mux", ~> "1.0.3" 

At present the first solution is possible, BUT it needs to become a convention which everyone follows in order to be useful (involving named branches or tags at the repo). The other advantage of this is that it states requirements fully in the package concerned - otherwise all we know is that this code requires github.com/gorilla/mux, not which version or when it was last tested/imported, whether it will work with the latest release or not, etc. But then it would let you run into conflicts by accidentally importing two versions of the same package with different paths.

The current convention of no version certainly puts more onus on the package maintainers to maintain backwards compatibility, or on users to maintain their own library of packages which they periodically update, and I see the arguments for it.

Of course none of this matters if you're just one person using packages to build an app at one moment in time, but if you yourself supply packages/apps to others, or want to setup members of an org over time with the same set of packages in the same state, and rely on other packages to compile yours, it can become more complex.

Other package managers tend to have a central point to adjust package dependencies, and make sure packages are always available forever at the same uri, so it'll be interesting to see how go manages this when go packages become more complex and widely used, start to be removed by maintainers, and start to have complex chains of dependencies on specific versions, or whether the much simpler go system in the end leads to a saner situation and puts the onus for this problem back on end users.