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

101–110 of 168 posts

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

#101

Post by thedufer »

redneckbeard wrote: post #39
rartichoke wrote: post #35

That test is rigged to be a best case scenario for Go. How often do you send 1MB responses down to the client? If you send 3KB responses then you would see both setups are much closer in performance. Factor in some actual I/O and the difference will be even less. Then you'll eventually realize using either one makes little difference when it comes to performance. This is why micro benchmarks are pure jokes. A real wo…

Original author of the post in question here. Please note that the microbench was "rigged" by the author of Node when he was first presenting it several years ago (spelled out in the article). If you need a tl;dr, it's this: I don't care for JavaScript as a language. Many make the argument that JavaScript should be adopted widely server-side because of its speed. I assert that languages should be evaluated not only f…

At the very least, calling 50% more lines a "similar line count" is disingenuous. 5 extra lines doesn't look like much, but on a typical multi-thousand line codebase, you're looking at thousands of extra lines.

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

#102

Post by ebiester »

thezilch wrote: post #83
ebiester wrote: post #78

Earlier quoted context omitted.

I am a "full stack" developer. I know the ins and outs of both my front and back end stacks (Groovy in my case), and I have a pretty good sense of the patterns required in this case. However, one of the more frustrating pieces of this is that I never dive deep into one paradigm. I'm continually having to work bilingually. When I was working with node.js, I didn't feel nearly as much bilingual stress (even though I've…

I didn't, by any means, intend to say it is not a good setup or denigrate you. I don't think anyone is wrong for using, even big teams, and I might even use the setup myself for certain projects. Only that it is rare to find really good full-stack developers, and those developers willing to work equally on both ends of the stack. And that a majority of work is thinking about the architecture and product; only hand wa…

With the new transpilers, I don't think that's as much of a problem so long as one stays to modern (IE9+) browsers. (Let's see if this really comes true, but I know a few node.js types are anticipating this.)

In the domain I'm in (internal enterprise cough) I find that most people are expected to be full stack. On the other hand, these tend to be more simple UIs in general, so the front end knowledge isn't as vital (cue 'good' full stack developer comments...)

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

#103

Post by aaronblohowiak »

aaronblohowiak wrote: post #89
thrownaway2424 wrote: post #73

Earlier quoted context omitted.

What do you think the difference is between a "real core" and a "hyperthread core"?

An HTT cpu can still only execute one instruction at a time; there are often instructions that cause the cpu to have idle time (stalled waiting for data) and hyperthreading allows for the cpu to spend that otherwise idle thread making progress on a separate task list. However, this still means that the two scheduled threads are contending for the same execution unit... The parent is suggesting that this contest may c…

note: the above was a simplification / based on my understand of HTT cpus as of about 2008. apparently things got more complicated in the last 5 years :D The bottom line remains that HTT can cause slowdown in some cases and you should benchmark with it turned off as well.

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

#104

Post by kin3tic »

rartichoke wrote: post #51
redneckbeard wrote: post #39

Earlier quoted context omitted.

Original author of the post in question here. Please note that the microbench was "rigged" by the author of Node when he was first presenting it several years ago (spelled out in the article). If you need a tl;dr, it's this: I don't care for JavaScript as a language. Many make the argument that JavaScript should be adopted widely server-side because of its speed. I assert that languages should be evaluated not only f…

The development speed isn't very good with Go because you have to re-invent almost everything yourself because the web libs are seriously years behind other platforms. The default template language is also really archaic and no one has created a solid alternative yet that's actually well tested and used by the masses. It might have good execution speed and the language itself might be nice but the only thing that mat…

>The development speed isn't very good with Go because you have to re-invent almost everything yourself because the web libs are seriously years behind other platforms.

This is complete and utter nonsense. This is true if you're still trying to build a webapp the way you would have gone about it 5 years ago. You're like the petulant child in IRC demanding his Golang Rails clone.

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

#105

Post by oofabz »

AsymetricCom wrote: post #96
thrownaway2424 wrote: post #93

Earlier quoted context omitted.

No, not even close. Each thread on a Haswell CPU, just as an example, has 8 execution ports. Each Haswell core has ten execution units. The CPU can retire way more than one instruction per cycle.

In theory

It's not just theory, you typically get about 3 instructions per cycle in practice.

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

#106

Post by redbad »

fredsanford wrote: post #38
616c wrote: post #3

So beyond the ironic comment mentioned before with the Golang Hello world tutorial using Chinese, what is the real reason behind the Chinese following behind Go? It seems like this site confirm there must be a pretty dedicated Golang following, but I cannot figure out for the life of me why. Does anyone actually know?

Maybe because a lot of choice has been removed from the system? I've worked with a bunch of people from different countries and find that the more strict the gov't, the less they like choice, in general. All anecdotal of course... Giving one guy from the Ukraine the typical choices at a restaurant here in the US would freeze him in place. What would you like to drink? Tea Sweetened or Unsweetened? Sweet. frustration…

    > My brain requires braces to line up in the left column, 
    > anything else slows me down. Maybe I'm just old?
One amazing property of humans is our ability to re-shape ourselves in new environments; to literally learn new tricks. The handicap you identify here is only serving to diminish your potential.

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

#107

Post by payload »

lmm wrote: post #11
MatthewPhillips wrote: post #7

Is it possible to write Go in a functional way? Are there first class functions? Anonymous functions? If so it seems it would be possible to write highly functional code given the flexibility of interface{}

Up to a point, but go's limited datatypes make it difficult to write the kind of code you're used to writing in haskell/f#/etc.

A haskell version with the Warp server performs just a little bit worse than the go version (6 secs vs 7 secs) with a little bigger minimal latency (68 ms vs 71 ms).

  go version go1.0.2
  runghc 7.6.2
  cabal packages of today
Runned with "runhaskell main.hs" on localhost over loopback :)

  import qualified Network.Wai as Wai
  import qualified Network.Wai.Handler.Warp as Warp
  import qualified Network.HTTP.Types as HTTP
  import qualified Data.ByteString as ByteString
  import Blaze.ByteString.Builder.ByteString (fromByteString)
  
  main = do
      let port = 8000
      Warp.run port app
  
  app req = do
      let n = 1024*1024
      let bytes = fromByteString $ ByteString.replicate n 100
      return $ Wai.ResponseBuilder HTTP.status200 [] bytes

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

#108

Post by enraged_camel »

ciclista wrote: post #95
diminoten wrote: post #75

Earlier quoted context omitted.

So do I just email all my questions directly to Thompson and Pike, then? In this case, language maturity means the quantity of reference material available to help troubleshoot problems as the arise.

The golang nuts mailing list is extremely active, you'd have no issues finding answers there.

The difference is sending emails to some mailing list and waiting for someone to answer, vs. entering a few keywords to Google and have the top result be the answer you want because someone already asked the same question before.

This is not a stab at Go or its maturity, but rather a realistic assessment of the importance of answers being (nearly) instantly available when you're working on a project or troubleshooting a critical issue.

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

#109

Post by corresation »

thrownaway2424 wrote: post #73
corresation wrote: post #18

Earlier quoted context omitted.

Try with GOMAXPROCS set to the number of real cores on your test machine (e.g. ignore hyperthread cores).

What do you think the difference is between a "real core" and a "hyperthread core"?

I'd be humored to hear your idea of what the difference is, given the misplaced use of scare-quotes.

A hyperthread core is a virtual core -- it is not actually a core at all but is a re-purposed, possibly stalled physical core. While it can improve some scenarios, in some cases (particularly core-saturating benchmarks) it can actually hurt performance.

This is hardly an out there or controversial statement. Further I didn't say to disable hyperthreading, I said to try setting parallelism to the physical cores. Again, nothing, whatsoever, controversial about that.

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

#110

Post by razorsese »

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

Post reply on HN