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

131–140 of 168 posts

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

#131

Post by Peaker »

cgag wrote: post #115
payload wrote: post #107

Earlier quoted context omitted.

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 impor…

Am I right in thinking that Haskell servers will likely be winning on these benchmarks after Mio is released in 7.8.1? https://news.ycombinator.com/item?id=6198068

Since Warp seems to use many light-weight(green) threads behind the scenes, and Mio is mainly about improving multithreaded performance on actual multi-core set ups, the answer seems to be yes.

However, it would probably only help if you use -threaded (which you should, anyways).

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

#132

Post by Peaker »

payload wrote: post #107
lmm wrote: post #11

Earlier quoted context omitted.

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 impor…

Don't use "runhaskell", it's more of a "script mode".

Use: ghc -threaded -O2 main.hs && ./main

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

#133

Post by payload »

strager wrote: post #117
payload wrote: post #107

Earlier quoted context omitted.

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 impor…

Have you tried precompiling with -O2? IIRC runhaskell runs code like GHCi: interpreted bytecode by default (for source .hs files).

Yes I have and I invite you to do it also by yourself to check it. There is no significant difference in this benchmark between "ghc -O2" and "runhaskell". I didn't investigated why... but I would be very interested in the details :)

Also "-threaded" gives the usual penalty of bookkeeping and bad caching and stuff. You don't need threads in such a benchmark. Though I am mildly surprised that "node" runs faster with multiple processes :)

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

#134

Post by payload »

Peaker wrote: post #132
payload wrote: post #107

Earlier quoted context omitted.

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 impor…

Don't use "runhaskell", it's more of a "script mode". Use: ghc -threaded -O2 main.hs && ./main

There is no significant difference in this benchmark. Do you measure something different?

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

#135

Post by bsaul »

enraged_camel wrote: post #108
ciclista wrote: post #95

Earlier quoted context omitted.

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 troubleshootin…

Agree on that, yet, if you want the big picture, you should multiply that by the probability of having something to troubleshoot, or a critical issue, in the first place.

That would give you a better estimate of the risk you're taking by using that language. And that's where the 30 years of PL design from GO's author gets some importance.

You could consider my argument a bit far fetched, but GO's design has been explicitly focused on keeping things simple and no-surprise, and so far all the reviews seem to agree on that point. That could compensate for the lack of results in Google (especially compared to what node.js forces you to do)

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

#136

Post by ebiester »

romaniv wrote: post #118
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 solved the cognitive overhead problem by developing everything via progressive enhancement. This way JavaScript has a clearly defined role and place in the process and I don't have to think in multiple languages. Of course, a lot of developers these days don't want to do progressive enhancement and dismiss it as "impossible".

So, with progressive enhancement...

I have a main screen with a query whose processing takes over a minute to perform it on all of the data, but seconds for incremental changes after that. Each row returned has a detail screen associated with it, and the users have a requirement to be able to move to a detail screen, update a record, and return to the main screen without continually incurring the heavy query penalty each time they return to the main screen. Business also has a requirement that the database of record is normalized. (Denormalizing and precomputing is good, but you run into problems when the feed updates.) Do you...

A. keep a Nosql (say... redis) cache, precompute, and perform two commits? This adds a non-trivial amount of complexity keeping them in sync, not including watching for jobs from outside feeds that can update at any time. This isn't bad for a simple system, or a system with a lot of engineers, but it's non-trivial to get right and easy to find out a bug after the fact.

B. Keep it all in the session? This has its own problems: if using an ORM, you're going to be increasing your memory load per user substantially. Otherwise, you're having to keep a separate data structure around and marshal/unmarshal, creating an additional complexity layer, and I haven't seen a great way to do this.

C. Keep a single page application and implement a polling mechanism behind the scenes to keep the information fresh? With a system like Ember or Angular, this may not be trivial but it's not terrible either, and I'd argue it's superior to a redis cache.

I know that I can provide a better user experience by prefetching. I don't know how to do this with progressive enhancement.

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

#137

Post by pbsd »

invisible wrote: post #80

I've worked with both node and Go. There is a lot of hyperbole and fluff points about Go's strengths in the original article (sorry to the author!). Things that are touted as huge wins for Go have equally better things in node. Both platforms are great and they both have appeal for different people. My eloquent post was eaten by an expired link on the original article but here are some counter-points: The commutative…

> 32-bit integers in JS don't have float problems because the precision doesn't break

Unless you try multiplying them.

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

#138

Post by thezilch »

romaniv wrote: post #118
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 solved the cognitive overhead problem by developing everything via progressive enhancement. This way JavaScript has a clearly defined role and place in the process and I don't have to think in multiple languages. Of course, a lot of developers these days don't want to do progressive enhancement and dismiss it as "impossible".

Not impossible as much as not worth the effort on the dollar. Reddit is fairly simple -- just a threaded-comment engine, if you will. You want the up/down rave to be progressive? So now every up/down is a form; already, drastically increasing the page's weight but I digress. You hook the body for form submits and reduce out your up/down forms; we are done, despite having a bunch of forms marking up the page.

Don't forget your form needs to be comprised of up and down submit-buttons; wouldn't want the progressive-CSS lords coming down on us.

Those fearful of JS come along... Collapse comments? Refresh the page, but don't forget to pass previous state of comments previously collapsed! Submit an up arrow? Don't forget that blob of state! Loaded deep-nested replies? Push it into state! Careful; none of this matters to 99.9% of your users, because they are understanding they'll lose the statefulness on refresh, while everything stateful happens inline and without refreshing the page and bringing in sections of the page as dictated by our stateful blob.

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

#139

Post by frio »

redneckbeard wrote: post #57
rartichoke wrote: post #51

Earlier quoted context omitted.

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…

My understanding is that many people try Go and decide they don't like it, as you did; at the same time, many have experiences that are similar to mine and they embrace it. To each his own. The word "rigged" in your original comment implied dishonesty on my part. I just wanted to clarify that the JS code used in the microbench was Ryan Dahl's, and mine was just a port to Go. I was merely giving Go the same task that…

I like Go the language; I dislike Go the platform (currently). What's there is great, but there's not enough of it. It's a great 1.0 release: stable, fast, but sparse.

Luckily, Go has a decent head of steam behind it, so when I revisit it in a few years that should be a solved problem ;).

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

#140

Post by Peaker »

payload wrote: post #134
Peaker wrote: post #132

Earlier quoted context omitted.

Don't use "runhaskell", it's more of a "script mode". Use: ghc -threaded -O2 main.hs && ./main

There is no significant difference in this benchmark. Do you measure something different?

I didn't measure, no.

I suppose maybe it uses the optimized compiled packages code, and the main code doesn't really do anything, so -O2 doesn't matter.

However, I would still expect "-threaded" to have an effect.

Post reply on HN