You can have both. An 'officially recommended approach' does not preclude 1000 unofficial but working approaches. However, it does it make it a lot easier for someone dipping their toes in.

With Node for core and basic problems, I find myself thinking "Should I follow this blog post written by a highly respected developer but which is a year old and therefore forever in Node-land, or this blog post written last week by a nobody?". I don't like thinking that way about production code I'm writing for clients, so I use languages where I don't have to think that way.

When you say languages, do you really mean frameworks? It seems like languages are fairly general purpose and don't go out of their way to tell you how to build your application. Node is more in the "language" camp than the "framework" camp, and there are bunch of frameworks on top of it that give you the structure you're looking for.

Anything. I'm a pragmatic developer who just wants solutions that help me pay the bills. It's precisely for that reason that Node has been a problem for me - it's caused much more than its fair share of headaches, when compared to Ruby, Python, PHP, Bash, Go.

Perhaps using a framework would make things easier, but I'm reticent to rely on it in the main part of the project when it causes so many problems just in the small parts.

Can you give an actual example of the 'so many problems' you describe?

Your previous comments address the paradox-of-choice idea, but the uncontroversial path in Node is to 'just use Express' right? How it that a worse situation than in other languages where there are also trendy frameworks competing against the default option. You name PHP as a better situation but from what I gather PHP is even worse at casting off legacy frameworks. Laravel is the new trendy, whereas it was CodeIgniter/Symphony before that and EE/Wordpress before that. And in Ruby, there's similar competition over an alternative to Rails [0].

[0] https://blog.engineyard.com/2015/life-beyond-rails-brief-loo...

Sure. There was the decision a couple of years back to stop using self signed certificates. I spent a couple of hours wondering why a server I was running that compiled SASS on deployment suddenly stopped working, and it turned out to have been this.

A more recent example comes from Zombie, which I use for functional testing. When they moved to v3, they required io.js instead of Node. So eventually I decided to go with Zombie 3 and moved to io.js, but then another library broke which required Node instead of io.js.

They're the two big ones that stand out, but there have been lots of other small annoyances.

I don't have a dog in this fight but the certificate thing sounds a lot like they corrected a significant security issue rather than API instability.

True enough, but they didn't tell anyone they'd done it for hours after they pushed out the changes. A notice on the terminal after the update should have been possible, or at least a big message on the homepage. But nothing - only an angry GitHub issues queue with random suggested causes and fixes.

In our shop we actually use all of Ruby, Node, Go, Python and Bash (in about that order of code volume). Honestly, for instability of 3rd party libraries Node is pretty bad, but Ruby is not really far behind. I am sure that I have spent more time debugging other people's code in Ruby than in Javascript.

Having said that the IO split has been a royal PITA. We got pegged to Node 10.x because JSDom only supports IO and Jest (which is what we wanted JSDom for) only supports Node :-P. I've been waiting a year for it to get cleared up.

It sounds like we made the right choice, though, because in this thread the people who are complaining about Node seem to be the ones who tried switching back and forth between IO and Node. There is actually only one bug in Node that has impacted me (related to the way connections are shut down) and it isn't fixed yet in master so not upgrading hasn't really impacted us. We just have to live without some of the ES6 features.

Personally, I'm a big fan of Go (old C++ programmer). We started using it a little over 2 years ago. The language definition has changed in that time, so I wouldn't call it stable ;-) The core libraries are rock solid, though. We barely use any 3rd party libraries (I think we use 2) so it's not really fair to compare that with other languages.

Although we have a fair amount of python in our shop, I don't seem to work on those projects very much (a month here and there). I can't say too much about it other than our Python code breaks due to 3rd party libraries more often than any of our other code. However, I think this is probably due to injudicious choices for our 3rd party libraries ;-)

Overall, I would say that my experiences don't match yours, but I wonder if it's because we never tried moving to IO.

Software development is not about chasing the latest shiny fad or trend on the market, it's about solving real-world problems by researching available solutions. So, if you think that Node doesn't fit or not equipped enough to solve your problems, you're welcome to check other solutions till you find the one most suitable to the problem at hand.

So, if you think that Ruby or Python could get things done for you and you're very familiar with them, go for either and get it done but to pick on Node just because you don't quite grasp its inner workings is really odd of you and the whole reasoning behind your critique is rather absurd.

It's not absurd to say "I'd like to use Node because of its performance and because it's easier to hire for, but only if it were more stable and had better documentation". As somebody who has to consider trade-offs between short-term and long-term costs for clients, these are very real problems for me.

Node's documentation really is terrible. The fact that it doesn't show what arguments functions take, what types are expected, etc. is pretty sad in 2015. The documentation is barely better than your typical side-project readme.md file, at best you get 1 example of an api's usage (always the most basic use-case only, of course).

Preach. I inherited a Node project for which Rails was a much better solution for our use case. It's been fun learning a new platform, but for our needs Rails would have been fine. The only conceivable reason I can see they chose Node is because it's cool.

Doesn't preclude them, but doesn't encourage them, which was the philosophy. An officially blessed approach would deprive alternatives of oxygen (though to be fair, it might also enlarge the pie, by attracting extra developers like yourself).

The flexible experimental approach inevitably conflicts with the constraint of back-compatibility (e.g. of x86, java).

Node seems more like the Drosophilia-like JS frameworks.

I can't reply to the grand-child of this post, so here's my reply.

It seems that you don't like Node and are intent not to use it. I respect that and am not trying to push it. I think asynchronous programming in the reactor pattern is a good solution pattern for many types of problems, and Node.js is a solid application of that pattern. But it certainly is more complicated than synchronous programming in the kinds of environments you listed.

I do wonder however what compels you to shit all over a thread celebrating a project milestone with an opinion that comes from an admitted lack of knowledge.

I'm not 'shitting all over Node'. I do use it for certain applications, and would love to use it more because it is a fantastic solution for some problems. As a back-end for websockets it's in a league of its own, and 'Isomorphic JavaScript' is very exciting if you ever need to hire developers.

I am using this discussion as a means of saying "here's what I think Node needs to get more people using it in production". My opinion is that they need to do more work on stability of the API, and improve documentation, to win over us enterprise types who value long-term stability over short-term features.

Just because I think you'll find this useful (and not because I want to denigrate Node, which I think is great tech, especially with the upgrades in this announcement), have you seen Phoenix[0]? Despite immaturity, I think it is already close to being in Node's league as a back-end for websockets, but seems to have a philosophy you may enjoy more. That is, it reminds me a lot more of Rails and Django than anything in Node. (I also think Elixir is awesome to work with, but that's somewhat beside the point.)

[0]: http://www.phoenixframework.org/

This is an announcement about the Node open source community finally overcoming their differences and making strides towards platform stability, yet your first response is to complain about "massive instability" (which turns out to be more about individual libraries than the platform itself) and how you "wouldn't hold Node up as a great example of the open source community". I can't see this as anything more than a slap in the face.

My opinion? You probably should withhold your judgement of the "open source community" if you only have superficial knowledge about their efforts.

>I think asynchronous programming in the reactor pattern is a good solution pattern for many types of problems, and Node.js is a solid application of that pattern.

Asynchronous programming a la Node (with callbacks etc) is an anti-pattern.

We've had better ways to handle that for 4 decades now.

For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are?

It would make your comment much more helpful, IMHO.

> For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are?

While I am not certain what the GP specifically references, I can say that about 40 years ago the Actor model[1] was officially documented. The literature documenting benefits of an Actor model over a callback approach are easily found. For understanding the pain which callback-based systems often produce, a person can familiarize themselves with the Win32 API (disclaimer: this is a masochistic exercise not recommended for anyone).

1 - https://www.cypherpunks.to/erights/history/actors/AIM-410.pd...

Even if you don't go the actor route, if you're going to use continuation passing style as much as Node wants you to, having a language with better CPS support would be much nicer

Blocking threads.

People associate threads with shared-memory concurrency, which can be really hard to deal with, but shared heaps are not the important part - blocking is.

Blocking threads means that all your functions can call each other, all control flow constructs just work, and debugging is sane. With blocking threads functions don't need to belong to a special class of async functions that in general need to be called from other async functions.

It would have been great if node invested in allowing many concurrent blocking JS threads. To see what that could have looked like, see Dart's Fletch project: https://github.com/dart-lang/fletch

Now that we have ES6 generators, this is much less of an issue.

Generators don't help with the sync/async split.

Generators are just iterators, and are synchronous. The consumer asks for a value with next() and the value must be computable (even if that value is a Promise).

If you have an async function (one that returns a Promise or in the future a Stream), and you need to call it from a sync function, and somehow incorporate the future value into the return value of the sync function, you're stuck. You have to async-ify your functions all the way up the call chain.

With blocking this isn't a problem. We just need environments that make blocking cheap.

In my experience in practice there is no big difference, really, its just a matter of a few keywords.

As for "having to change an entire call stack", that just stopped happening after a while. The rule of thumb was that if the function is impure (e.g. relying on mutable state) then it will likely become async, too. That lets me plan ahead.

Anything other: blocking in an Erlang like system, actors, CSP, real continuations, async/await, etc.

What are the differences between what you reference as "actors" and "CSP"?