4 ms·

> “The last thing we want to have happen to the Node ecosystem is to create a Python 2, Python 3 situation”. As a long time Python user unhappy with the 2 vs 3

by bsg75 12y ago

> “The last thing we want to have happen to the Node ecosystem is to create a Python 2, Python 3 situation”. As a long time Python user unhappy with the 2 vs 3 thing, is not the Node vs IO thing very different? A fork (Node) vs two versions being managed by the same group (Python)?

iancarroll 12y ago
At least for now, iojs works with node and node works with iojs. They're also managed by different people.
- deleted 12y ago
  [deleted]
lbotos 12y ago
It's different but if IO/Node diverge too far, it could break packages.
- debacle 12y ago
  They're both MIT and likely to stay MIT. They don't have to diverge at all unless Joylent goes open/closed. Edit: Downvoters, have I said something that is untrue?
  - emergentcypher 12y ago
    But isn't the point of the split that they have differing opinions on how to do things? Hence, they -will- diverge according to those differences in opinion. Not to mention, keeping them consistent means someone has to take code added to one, and port it into the other. That must take some work, and I can see the laziness of people coming through.
  - bsimpson 12y ago
    The whole debate is over uptake speed. If async functions and lambda arrows land in IO and I use them in my package, people on node v10 aren't going to be able to use it. If Joyent accepts new features as quickly as IO, there's no point in the fork. Essentially, there's bound to be some level of fragmentation.
    - debacle 12y ago
      I don't really see one implementation being a superset of another as fragmentation - IO will just be better, and Node will slowly die.
    - jessaustin 12y ago
      What this scenario means is that there should be a way for a module to depend on polyfill modules, only for particular engines. So on IO the dependency would not be in effect, while on e.g. node v0.10 it would. I don't think this is possible now, but you could just publish two modules.
    - tracker1 12y ago
      That's already happening... co was released over a year ago, and still requires the dev version of node and the --harmony flag... this is something that should be in 0.12 which should have been released by now. Any modules relying on generators already require gnode or > 0.10 ... so uptake speed is very relevant and already an issue. It's about how slow things have moved since 0.10 as much as anything else.
diminoten 12y ago
It'd be a very similar experience for users, where IO code/packages would be incompatible with node.js code/packages despite being, on their face, very similar. But you're right, that situation might not last as long, due to the fact that one is theoretically trying to eat the other's users, rather than in the case of Python, where things are much friendlier.
deleted 12y ago
[deleted]

by bsg75 12y ago

iancarroll 12y ago

At least for now, iojs works with node and node works with iojs. They're also managed by different people.

deleted 12y ago
[deleted]

lbotos 12y ago

It's different but if IO/Node diverge too far, it could break packages.

debacle 12y ago
They're both MIT and likely to stay MIT. They don't have to diverge at all unless Joylent goes open/closed. Edit: Downvoters, have I said something that is untrue?
- emergentcypher 12y ago
  But isn't the point of the split that they have differing opinions on how to do things? Hence, they -will- diverge according to those differences in opinion. Not to mention, keeping them consistent means someone has to take code added to one, and port it into the other. That must take some work, and I can see the laziness of people coming through.
- bsimpson 12y ago
  The whole debate is over uptake speed. If async functions and lambda arrows land in IO and I use them in my package, people on node v10 aren't going to be able to use it. If Joyent accepts new features as quickly as IO, there's no point in the fork. Essentially, there's bound to be some level of fragmentation.
  - debacle 12y ago
    I don't really see one implementation being a superset of another as fragmentation - IO will just be better, and Node will slowly die.
  - jessaustin 12y ago
    What this scenario means is that there should be a way for a module to depend on polyfill modules, only for particular engines. So on IO the dependency would not be in effect, while on e.g. node v0.10 it would. I don't think this is possible now, but you could just publish two modules.
  - tracker1 12y ago
    That's already happening... co was released over a year ago, and still requires the dev version of node and the --harmony flag... this is something that should be in 0.12 which should have been released by now. Any modules relying on generators already require gnode or > 0.10 ... so uptake speed is very relevant and already an issue. It's about how slow things have moved since 0.10 as much as anything else.

diminoten 12y ago

It'd be a very similar experience for users, where IO code/packages would be incompatible with node.js code/packages despite being, on their face, very similar. But you're right, that situation might not last as long, due to the fact that one is theoretically trying to eat the other's users, rather than in the case of Python, where things are much friendlier.

deleted 12y ago

[deleted]