5 ms·

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 13y ago
  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/ http://www.techempower.com/benchmarks/ In addition to various JVM technologies, there are faster technologies in C++, PHP, and Lua.
  • pekk 13y ago
    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 13y ago
      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 13y ago
  What's easier about deploying Go vs with the JVM? Deploying stuff I've written in Clojure has been pretty easy.
  • threeseed 13y ago
    It's more your 'typical' Java app. Which is often the huge array of JARs and folder structure you typically need to bootstrap.
    • cgag 13y ago
      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 13y ago
    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 13y ago
      Doesn't this require your development machine to use the same architecture and OS as your server?
      • wtf_is_up 13y ago
        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.