Live data from Hacker News

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

bbs.studygolang.com

81–90 of 168 posts

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

#81
post #68

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…

As a single developer on a project, I use js on the front-end, NodeJS and CouchDB (views written in js). This means that every step of the way is js, json and http, which is extremely liberating for me, as someone who's just starting out with web development.

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

#82
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…

It does not make sense to group peoples reaction to choice like this. As a counter example Apple products are very popular in the USA and other Western Countries, and Apple does not give you many choices.

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

#83

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 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 waving 5% of the time is going to be spent context switching languages. I'd lose most of that time not having a richer language than what JS 1.5 offers, and if backend JS ever gets 1.7+ features, I am certain the browsers are not in the same stride, at which point I lose again.

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

#85
post #24

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…

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

Much more so than internet posts about it, there are countless modules for NodeJS as well. Need to upload and store and return images in Monogo using streaming? Done. Need to keep servers running despite errors? Done. Amazon S3? Done. Need an alternate cloud provider? Done. Need login using OAUTH/OpenID/whatever? Done. On and on. Most times you need some general purpose web functionality, there's already a couple Node modules in that area, if not an entire framework or sample app and tutorial targeted at that area.

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

#86

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

There is a huge difference between the two. Hyperthreaded cores only give you a speed up in specific situations where additional work can be squeezed into the pipeline.

http://en.wikipedia.org/wiki/Hyper-threading

The speedup is very work dependent and in practice for things like web pages and api servers you generally only get another 20-40% of performance from them rather than a full 100%.

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

#87

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.

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

#88

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

Well it shouldn't matter that much anyway, I don't think modern kernels will put the same process threads on the same physical core.

That's the reason intel tells you to shut hyperthreading off if your operating system doesn't support it.

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

#89

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

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 cause more of a performance degradation than the advantages that HTT provides, which would be easily resolved with some benchmarking :D

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

#90

Earlier quoted context omitted.

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 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.
Post reply on HN