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…
Go as an alternative to Node.js for very fast servers
81–90 of 168 posts
Re: Go as an alternative to Node.js for very fast servers
#82So 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…
Re: Go as an alternative to Node.js for very fast servers
#83Earlier 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…
Re: Go as an alternative to Node.js for very fast servers
#84Re: Go as an alternative to Node.js for very fast servers
#85I 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
Re: Go as an alternative to Node.js for very fast servers
#86Earlier 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"?
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
#87I'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…
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
#88Earlier 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"?
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
#89Earlier 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"?
Re: Go as an alternative to Node.js for very fast servers
#90Earlier 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…