[spasquali]

Your experiences moving a Node app to Go would make for a great study. You're extremely influential, and it may be better to give concrete examples of how Node can be improved.

I wonder about this "enjoyable" criteria. I'm assuming you're not claiming to be the only person who has written large Node systems, or that nobody has ever written larger, more highly trafficked, more complex Node applications than you have. So the point seems to be: for you, Go is more fun than Node at scale. As a well known contributor, that's a valuable perspective. I'd like to know more about how your personal experience could be translated into general truths all developers could understand.

It seems to me that Node is used rather extensively by the core contributors. I don't get the impression that they have never actually used the product, based on their repos etc.

Thanks for all your work. I'm sure the Go community will similarly benefit from your efforts.

[tjholowaychuk]

I think the issue is we've been slowly accepting that the node is the right way to do things. Five years of working with someone will do that to you. If you follow me on twitter you probably see me complain about it in various ways all the time, it's not that I'm bored with it, node's problems are real and some people just seem to ignore them, or maybe just deal with them because they know backwards compat can't be broken immediately. It has always bothered me that people would advocate such broken systems (streams etc) when real-world alternatives were better even before now, even C has a much better example of what a stream should be.

I'm definitely not the only one writing large systems, but I think the tolerance level varies per developer. Also plenty of people make a living/name from Node, of course they're more likely to praise it than to be honest about its faults, I'm definitely a minority in that respect. Having broken concepts is one thing, but resisting change when they're obviously broken is not a good thing. Many of these same people make money from consultation, where it's advantageous to have a broken system. I'm not trying to screw them over but someone has to be honest.

It took years to get .addHeader() in because no one in core believed in a progressive API, they didn't use node in real-world applications to see the need. This still happens all the time, take npm-www for example, Isaac is a rad guy but him aswell as most other "core" community members advocated building tiny little things and stitching them all together, and just recently realized that in practice this doesn't scale, thus ended up going with Hapi. This lack of insight is all over Node as a community.

It's hard to describe well, but I hope people will try Go (or similar alternative), you'll really see how much more robust it is. If node fixed its conceptually flawed event system, rewrote http so it wasn't awful to work with, and fixed streams then we'd have a pretty good system to work with. It's very easy to pass off problems with node as problems you'd have with any platform, but that's unfortunately just not reality.

[spasquali]

I have to push back against some of your statements.

“I think the issue is we've been slowly accepting that the node is the right way to do things. Five years of working with someone will do that to you.”

Who is “we” and what is the evidence for the conclusion? How is it true that 1) In 5 years all coworkers think exactly the same way; and 2) Some purported truth about human behavior relates to the general usage of a programming language within an opinionated and free community? This seems like some random statement without any (provable) basis in reality.

“It has always bothered me that people would advocate such broken systems (streams etc) when real-world alternatives were better even before now”

You’ve started companies, joined companies, and encouraged Node technology at companies. You’ve advocated for others to use the systems that you’ve built. These companies have investors and other who trust your judgement. Why did you advocate a broken system, for so many years? Or did you come to this conclusion just a few weeks ago? What led you to that conclusion?

“I'm definitely not the only one writing large systems, but I think the tolerance level varies per developer.”

I’m not sure that anyone I know who builds massive enterprise systems ignores the “bad parts” of a system. None of them are tolerant of bad ideas. You really can’t be if you’re a professional with responsibilities to your team, your company, and shareholders. To suggest that Node is popular because Node developers are more tolerant of bad systems is, well, a weak theory that I think doesn’t stand up to reason.

“Also plenty of people make a living/name from Node, of course they're more likely to praise it than to be honest about its faults, I'm definitely a minority in that respect…Many of these same people make money from consultation, where it's advantageous to have a broken system. I'm not trying to screw them over but someone has to be honest.”

It’s not controversial to point out that you have advocated for (praised) a system that you believed was full of faults, for years, for great profit, in many senses. So you’re indeed a minority, but not in the way that you think you are. All of this sounds, to me, a little screwy.

“This lack of insight is all over Node as a community.”

I’ve re-read the paragraph preceding the above conclusion, but have failed to find a cogent argument. Something about #addHeader, and Isaacs is rad, and something else about “building tiny little things and stitching them all together” is a fools errand — this seems to be an “insight”. From Eric Raymond’s Unix rules: “Rule of Composition: Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs.”. Unix has scaled pretty nicely.

Now, you may be right. Also, Raymond might be right. Also, the entirety of the thousands of developers who build serious, professional software by following this credo might be right. Or some may be wrong. Or all may be wrong. But the point is… I still don’t see you producing an irrefutable argument, especially since you want to conclude that Node is fundamentally broken, isn’t “ready for prime time”, and so forth. I mean, you’re the most prolific contributor to the Node project, and you have advocated on several occasions for exactly this sort of methodology. It’s confusing.

“It's very easy to pass off problems with node as problems you'd have with any platform, but that's unfortunately just not reality.”

Not sure what you’re saying here. I could link a few hundred articles covering every language, including Go, that say the same thing you’re saying about Node — but I don’t know what they’re getting at either. No programming language solves all problems, and is easier than all others, and has no mistakes in it, and etc. Do you dispute that? If not…why exactly is the fact that Node has some problems, and some imperfections, and some mistakes, a reason to dismiss it outright? From your earlier post: “my claims of node not being production ready are 100% legit, and based on real-world applications.”. 100% legit? That’s pretty legit! But howzit legit?

I’ve been a little hard here, but I feel I had to be. Again, you’ve been a great contributor to the project, and I hope you do some more great things.