Comment by pcwalton | Hacker News Reader

Comment by pcwalton | Hacker News Reader

Unless you know you can't use what you know, stick with what you know. Business concerns trump technical concerns for early-stage startups, and the differences between the three are minute as far as business is concerned. However, having to struggle with learning a new stack can impact your business.

Even if the differences between node.js and Go mattered, you won't get anything valuable from asking HN "should I use node.js or Go", since the two stacks are broadly in a similar niche and have similarly-sized communities. It'll mostly be fans of one technology bashing the other, as you can already see in this thread. It would be better to focus on specific concerns: Do you need support for shared memory on multicore? Is the ability to reuse JavaScript code on the browser and the server a concern? Is there a specific library that's essential to your business that's only available on one or the other? These questions would engender a much more interesting discussion.

This is the best answer. You can scale any language to 100k pageviews/day. Some scale easier than others, but almost anything reasonable will hit those numbers with the proper infrastructure.

New languages and frameworks have their pitfalls. Pick what you know so that you don't get tangled up in the weeds while trying to build out a product quickly.

I still don't understand why people ask this question. It's exactly like you say. The technology stack does not really matter. All that matters is how productive you are in the initial phase.

You should always be choosing something you are familiar with, because it will allow you to get where you want much quicker. And yes, later, then you do actually build a business, you can start playing around with newer technologies. But only if they are valuable for the business.

Double so because OP has been out of the loop for 6 years, which tells me that they are probably a bit rusty and not prepared to absorb a new language on short notice.

node's error handling is by far its weakest point IMO, Go is a lot better in that respect, but a full javascript stack has its advantages

I remember you criticized on twitter this point of Node some time ago and the response of some leaders of Node community was like "Sorry, this isn't Erlang" and "Erlang is better but it's harder"

Yeah, pretty naive responses, but understandably most people who have been in the community for a long time don't want to admit the reality, seeing as node is what powers most of our jobs haha. Bottom line is node has a massive flaw, and it should be fixed, at least core members should have interest in fixing it.

Especially with tools like Go there's a lot of pressure to NOT use node in production when great alternatives are available. Node still has the "JavaScript edge", but if fault tolerance remains as poor as it is now that won't matter for long.

Your are right.

Once ES6 is here(when? i dont know), things are going to get better i think,

but Go way of dealing with concurrency in general is a lot better than javascript's for now.

Generators will help a tiny bit but certainly not nearly as much as something like coroutines with separate stacks. I know the node-fiber guy(s) had some issues with v8's internal stack usage so it doesn't seem like a near-future possibility to really have light-weight coros in node :(

FWIW (to give a little context to this comment):

TJ is the author of Jade, Stylus, Express, Connect, Component, Kue, Mongoose, Knox, Cluster (before the bundled cluster module), Canvas, N, Commander, etc, etc.

If anyone has a perch upon which to criticize Node, he's certainly amongst the most qualified.

Reply on news.ycombinator.com