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

111–120 of 168 posts

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

#111

Post by bhauer »

SkyMarshal wrote: post #74
bhauer wrote: post #44

Earlier quoted context omitted.

I agree with Voidlogic here. Perhaps his tone was a little confrontational, but his intentions were good. :) Go 1.1 > Go 1.0.2 wrk > ab In particular, ab should be avoided whenever possible. Apache Bench (ab) remains a single-threaded tool, meaning that for high-performance servers in particular, your exercise will run into the limits of Apache Bench before the limits of the server(s) being tested. The LigHTTP team h…

Is this the wrk you're referring to: https://github.com/wg/wrk

Yes. Sorry for not providing the link!

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

#112

Post by slashclee »

masklinn wrote: post #50
agentultra wrote: post #30

Earlier quoted context omitted.

My only gripe is its intended use as a systems programming language. The runtime kind of makes it a silo; ie: hard to bind other languages to it through an FFI. Of course if I am mistaken or there's something being done to address such a scenario then I will be much happier seeing more and more infrastructure code shipping in Go.

> My only gripe is its intended use as a systems programming language. It's not. It's a new Java, not a new C++. > ie: hard to bind other languages to it through an FFI. More or less impossible: GC and goroutines are not optional so you'd need to cleanly setup and shutdown the Go runtime. You'd have to embed Go as you do Lua or Python.

> > My only gripe is its intended use as a systems programming language.

> It's not. It's a new Java, not a new C++.

Not according to the Go developers. "Go is a general-purpose language designed with systems programming in mind." http://golang.org/ref/spec#Introduction

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

#114

Post by pekk »

tensor wrote: post #98
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.

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.

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

#115

Post by cgag »

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…

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

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

#117

Post by strager »

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…

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

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

#118

Post by romaniv »

ebiester wrote: post #78
thezilch wrote: post #72

Earlier quoted context omitted.

Nay. You're going to need both backend (routing, security, caching, HTTP, more caching, SQL/ORM/whatever, MVC, search/document stores, etc) developers and frontend (HTML, CSS, HTML5 (Re: "the hard stuff"), AJAX/JSONP/CORS/whatever). Off the cuff, knowing another language is going to be very little of the overhead, especially when you consider one side is dealing with local services and the other is dealing with mostl…

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

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

#119

Post by chad_oliver »

thrownaway2424 wrote: post #93
aaronblohowiak wrote: post #89

Earlier quoted context omitted.

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…

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.

You are absolutely correct, but you could also afford to be a bit more polite. Sentences like "In other words, you have no idea what the difference is" might be true but they're also a bit rude.

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

#120

Post by chimeracoder »

drsintoma wrote: post #87
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…

> 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 statically typed language (not just Go), because you need some way to reason about the type. You'll also have the same problem with dynamically typed languages as well - the main difference is that Go will never do implicit casts (I would view this as a good thing).

I've done a lot of work in Go involving JSON (that's originally why I wrote the above tool - to save myself time), and in practice, it's rare that I have to do anything more than decode, check for an error[0], and then move on.

[0] Which is something everyone should do in all languages, not just Go - once you've confirmed that there is no error, you rid yourself of a lot of possible bugs that could pop up later on in harder-to-discover places.

Post reply on HN