[swah]

Go doesn't mean just fast for me; in that space there is also the JVM. To me, it fits the fast and lean and easy to deploy space.

[tensor]

The headline of this article bothered me in this regard. Node.js is decidedly middle of the pack in terms of performance:

http://www.techempower.com/benchmarks/

In addition to various JVM technologies, there are faster technologies in C++, PHP, and Lua.

[pekk]

I think you will find that in many actual applications PHP is not faster than Node.

Further, once you apply a framework to paper over some language warts, performance is often terrible and can only be rescued by extremely liberal caching.

If this were not so, it would be hard to see the motivation for HipHop.

[tensor]

Might the motivation simply be to get closer to C++ performance?

I really don't value this type of response where the benchmark is brought into question, yet nothing is substituted as evidence. In the few cases were someone does claim that they rewrote a sufficiently complex system in Node from some other language, it's impossible to discount that the performance changes come from architectural choices rather than language choices.

Playing devils advocate, I've heard the same claim you put forth here about Node.js: it gets much slower in real apps because you have more slow JS code being run vs the very fast C libraries that back the core of Node.js.

To me, benchmarks like the one I posted above are the most compelling form of evidence we have. What I take from it is that a great many "boring" languages and frameworks are really very fast. It's not the answer that most people want to hear of course; it goes against the current popular hype.

[cgag]

What's easier about deploying Go vs with the JVM? Deploying stuff I've written in Clojure has been pretty easy.

[threeseed]

It's more your 'typical' Java app.

Which is often the huge array of JARs and folder structure you typically need to bootstrap.

[cgag]

My understanding is you can just build an uberjar that contains all that, then just drop that jar on your sever and run it (java -jar myuberjar.jar).

[pallinder]

go build

It compiles a binary, just send it to the server and it will run, no need to even have go installed on the server (or any libs really).

[chc]

Doesn't this require your development machine to use the same architecture and OS as your server?

[wtf_is_up]

No. It's simple to build Go toolchains for whatever your deploy os/arch target is. Then you just cross-compile.

* Download Go source

* Extract, cd go/src/

* GOOS=linux GOARCH=386 ./make.bash #this will build the linux_386 toolchain

* GOOS=linux GOARCH=amd64 ./make.bash #linux_amd64

* GOOS=linux GOARCH=arm ./make.bash #you get the picture

GOOS can be windows, darwin, freebsd, netbsd, plan9.

Then when you want to cross-compile your app, you do:

GOOS=linux GOARCH=arm go build myApp.go

That's it. Now you have a statically linked binary that you can drop on whatever your target is. As someone who has had to cross-compile a lot of C and C++ code, I find this simplicity to be a huge win.

[chc]

Thanks for that. It's been a while since I used Go. That is quite nice.