7 ms·

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 tr

by dcwca 11y ago

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.

blowski 11y ago
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.
- sanderjd 11y ago
  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/ http://www.phoenixframework.org/
- Gigablah 11y ago
  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.
coldtea 11y ago
>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.
- nocman 11y ago
  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.
  - spankalee 11y ago
    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 https://github.com/dart-lang/fletch
    - spion 11y ago
      Now that we have ES6 generators, this is much less of an issue.
      - spankalee 11y ago
        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.

by dcwca 11y ago

blowski 11y ago

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.

sanderjd 11y ago
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/ http://www.phoenixframework.org/
Gigablah 11y ago
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.

coldtea 11y ago

>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.

nocman 11y ago
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.
- spankalee 11y ago
  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 https://github.com/dart-lang/fletch
  - spion 11y ago
    Now that we have ES6 generators, this is much less of an issue.
    - spankalee 11y ago
      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.