Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go as an alternative to Node.js for very fast servers

bbs.studygolang.com

Post reply on HN
Print view View original

121–130 of 168 posts

Re: Go as an alternative to Node.js for very fast servers

#121

Post by ef4 »

gtaylor wrote: post #68
Morphling wrote: post #60

I know this post is about speed, but you should always remember that with node.js you only need JS developers while with Go you are probably going to need both Go and JS (for front-end stuff) developers. Just my two cents.

At the same token, having frontend JS devs that don't have much experience in writing backends can leave you with a mess to clean up or completely re-write in the future. I think this "benefit" of using the same language for front and backend is pretty over-hyped, as well. In theory, I can agree that it sounds good. In practice, use the best tool for the job on both ends to fit your team's abilities and strengths. Th…

I have a rich, client-side, fully-offline-capable javascript application. I started out with a different language for the backend, but over time the benefit of switching to Node and sharing one codebase became overwhelming.

Just to give one example: any data query can get answered locally or from the server, depending on what's already cached and whether you're online. Before, I had to implement every call twice and make sure they stayed in sync. Now I can implement once and run the same code in both places.

And other interesting possibilities open up. The server can just run the client's data synchronization code to pull changes from another server, giving realtime server-to-server replication nearly "for free".

Re: Go as an alternative to Node.js for very fast servers

#122

Post by threeseed »

bsaul wrote: post #34
melling wrote: post #24

Earlier quoted context omitted.

How much of an advantage, if any, does Node provide because it's more "mature", or at least has been used for far longer. For example, when I go to StackOverFlow I see that Node has far more questions asked: http://stackoverflow.com/questions/tagged/go http://stackoverflow.com/questions/tagged/node.js

I'm really uncertain about node being judged more "mature". Being developed by Thompson and Pike makes you gain something like 30 years of "maturity". Plus, running in production in the Google infrastructure is far more of a proof of maturity than running the chat service of every hackathon project for 2 years.

Two smart guys writing a programming language instantly gets you 30 years of maturity. Did I just wake up in some bizarro universe or something ?

And nobody cares if Go is being used for some tiny, insignificant part of the Google infrastructure. Get back to me when it is used for a stock exchange, betting site or complex web app.

Re: Go as an alternative to Node.js for very fast servers

#123

Post by rartichoke »

drsintoma wrote: post #90
rartichoke wrote: post #66

Earlier quoted context omitted.

I did like it, what I didn't like was solving common web app related issues that were solved on other platforms years ago. That's what completely killed my urge to consider Go. I don't want to spend most of my time solving boring issues. I want to spend most of my time writing features for apps I make. Being productive makes me happy but everyone has different happiness triggers I suppose. I see performance as a some…

may I ask, what exactly did you have to re-invent? It's true that Go is very young and so are the libreries, and that only recently has started to be seen as web language. But my experience is that the most common problems for web are solved with things like Revel. Is true that is a bit feature basic and there are not that many other options, but I wouldn't consider it insufficient.

To be fair I didn't use revel. Instead I just used pat (the route mapper) and started to try and recreate most of what express does using go's stdlib because nothing else really existed yet.

The gorilla toolkit's APIs are inadequate and it seemed like quite a few people agreed too because most of them said they rolled their own solutions to do things that certain gorilla libs did but with a more intuitive and friendly API.

Go really isn't that young either. It's been what at least 4 years now? There's no excuse. It's not like the language is 6 months old.

As for re-inventing stuff, it's more so go's ecosystem rather than revel's shortcomings although revel does have its own shortcomings if you were to compare it to something like rails and not express.

Revel seems to be somewhere in between rails and express in terms of opinions which is fine but if it's going to make me less productive then I'm simply not going to use it.

Re: Go as an alternative to Node.js for very fast servers

#124

Post by threeseed »

cgag wrote: post #113
swah wrote: post #54

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.

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

It's more your 'typical' Java app.

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

Re: Go as an alternative to Node.js for very fast servers

#125

Post by pallinder »

cgag wrote: post #113
swah wrote: post #54

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.

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

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).

Re: Go as an alternative to Node.js for very fast servers

#126

Post by arh68 »

razorsese wrote: post #110
AndyKelley wrote: post #10

I did the benchmarks outlined at the end of the article. Summary of results: 1. Node.js v0.10.15, single worker: 46.2 seconds 2. Node.js v0.10.15, cluster 8 workers using naught: 17.2 seconds 3. Go 1.0.2, GOMAXPROCS left default: 3.5 seconds 4. Go 1.0.2, GOMAXPROCS=8: 3.7 seconds Detailed results below: 1. Node.js v0.10.15, single worker Concurrency Level: 100 Time taken for tests: 46.217 seconds Complete requests: 1…

Why is this faster? https://gist.github.com/jdpaton/9f20ff0b13e0cc20017a

I did find this bit:

  // When calling .end(buffer) right away, this triggers a "hot path"
  // optimization in http.js, to avoid an extra write call.
  //
  // However, the overhead of copying a large buffer is higher than
  // the overhead of an extra write() call, so the hot path was not
  // always as hot as it could be.
  //
  // Verify that our assumptions are valid.
https://github.com/joyent/node/blob/master/benchmark/http/en...

Re: Go as an alternative to Node.js for very fast servers

#127

Post by drsintoma »

chimeracoder wrote: post #120
drsintoma wrote: post #87

Earlier quoted context omitted.

> Typing in Go can still be annoying for some situations. If you're dealing with external content (creating an API with mutable content that you still need to read) it can be annoying at best (e.g. reminds me of writing C). Types in Go are a nice implementation though. Indeed, that's probably the biggest flaw I've found working with GO's type system. Trying to work with unknown n-level JSON is real pain.

I'm not entirely sure what problem you're referring to here, but I wrote a tool to enable with mapping JSON to native Go types: https://github.com/ChimeraCoder/gojson . Basically, you specify the narrowest possible type that covers all expected (valid) inputs. If your JSON is effectively "strongly typed" (most APIs are), this is going to be a huge win for you. If your JSON is not, then you'll have a problem in any st…

Very interesting! It might be exactly what I was missing. I ended up using simplejson[0] but it still felt like a workaround. I'll give yours a try next time. Thanks!

[0]https://github.com/bitly/go-simplejson

Re: Go as an alternative to Node.js for very fast servers

#129

Post by drsintoma »

rartichoke wrote: post #123
drsintoma wrote: post #90

Earlier quoted context omitted.

may I ask, what exactly did you have to re-invent? It's true that Go is very young and so are the libreries, and that only recently has started to be seen as web language. But my experience is that the most common problems for web are solved with things like Revel. Is true that is a bit feature basic and there are not that many other options, but I wouldn't consider it insufficient.

To be fair I didn't use revel. Instead I just used pat (the route mapper) and started to try and recreate most of what express does using go's stdlib because nothing else really existed yet. The gorilla toolkit's APIs are inadequate and it seemed like quite a few people agreed too because most of them said they rolled their own solutions to do things that certain gorilla libs did but with a more intuitive and friendl…

> Go really isn't that young either. It's been what at least 4 years now? There's no excuse. It's not like the language is 6 months old.

1.5 if you count from the first stable release. Which IMHO is what matters, before was just a experiment with a lot of uncertainties. It took ruby 9 years to arrive from 1.0 to Rails. They were other times, sure, but still.

I still consider it very young, or at least I don't know of any other younger language with a better ecosystem.

> Revel seems to be somewhere in between rails and express in terms of opinions which is fine but if it's going to make me less productive then I'm simply not going to use it.

Well, everyone has their preferences, certainly in Go there are not many choices so is not for everyone. But I'd keep an eye on it. Things can change very quickly.

Re: Go as an alternative to Node.js for very fast servers

#130

Post by tensor »

pekk wrote: post #114
tensor wrote: post #98

Earlier quoted context omitted.

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.

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.

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.

Post reply on HN