Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does io.js address the problems that TJ Holochuck expressed? #399

Closed
moreofmorris opened this issue Jan 14, 2015 · 13 comments
Closed

Does io.js address the problems that TJ Holochuck expressed? #399

moreofmorris opened this issue Jan 14, 2015 · 13 comments

Comments

@moreofmorris
Copy link

Hello.

Just a question really, does this io.js project aim to address some of the problems that TJ Holowaychuk expressed in his Farewell Node.js post? https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b

@YurySolovyov
Copy link

Error handling and callback complains could be partially solved once/if API will be more Promise-oriented.
You can already get promisified node APIs with bluebird for example.

@mikeal
Copy link
Contributor

mikeal commented Jan 14, 2015

Error handling and callback complains could be partially solved once/if API will be more Promise-oriented

Actually, TJ preferred the use of generators for a lot of this stuff. Generators are only available in latest stable Node.js if you re-compile so you can see why he was/is quite frustrated.

io.js 1.0.0 has generators by default without even so much as a flag :)

@idx3d
Copy link

idx3d commented Jan 14, 2015

I think those "problems" cannot be solved anymore in core and stay compliant with npm in the same time. npm + node so big ecosystem and it will be broken if core will be changed to solve problem of callbacks and error handling.

@mikeal
Copy link
Contributor

mikeal commented Jan 14, 2015

I think those "problems" cannot be solved anymore in core and stay compliant with npm

We actually have a much better idea about how to responsible add small breaking changes to core now, and we have a versioning scheme that helps as well, so I think we can address the "meta" concern that core can't be changed.

Some of his concerns about debugging remain but asyncwrap is a step towards solving them.

Honestly though, you have to take what TJ said with a grain of salt. TJ is extremely prolific, which is great for everyone else but it also means that he uses almost no code he didn't write himself. The largest benefit of using this platform over something like Go is the ecosystem. For early adopters like TJ, who showed up when virtually nothing was already available, this matters a lot less than the kinds of users we attract nowadays.

@idx3d
Copy link

idx3d commented Jan 14, 2015

We actually have a much better idea about how to responsible add small breaking changes to core now

Is it any chance to take a look on it? Or it is not published yet?

@mikeal
Copy link
Contributor

mikeal commented Jan 14, 2015

It's sort of buried in the TC calls, which are all public but laborious to go through. Mention is made often to deprecating certain modules and features and thoughts about how to increment the version responsibly in order to do so.

@YurySolovyov
Copy link

It would be great to have some sort of guides when this happens like:
foo is deprecated, use bar
or
using foo in such way (...) is anti-pattern, it's been deprecated, don't use it, do bar instead

Idea is to give users some upgrade path so they can stay up-to-date with latest APIs without too much efforts.

@mikeal
Copy link
Contributor

mikeal commented Jan 14, 2015

@YuriSolovyov that is the plan for deprecation of the sys and domains modules :)

@YurySolovyov
Copy link

@mikeal is that a general strategy for any breaking changes, not only deprecations?

@mikeal
Copy link
Contributor

mikeal commented Jan 14, 2015

@YuriSolovyov no, many breaking changes can't be done that way. for instance, v8 might break the C++ API and there isn't much we can do about it other than bump the major version number, but we will be bumping the version number properly according to semver.

@greim
Copy link

greim commented Jan 15, 2015

Seems like "performance over usability" was something he complained the most about, where "usability" meant not just that callback-structured code is painful to write and maintain, but lack of language-level guarantees about if/when/how many times callbacks are called.

  1. Promises are now adopted into the language, which add some better guarantees about if/when/how many times callbacks are called.
  2. Async/await will eventually mitigate need for callback-structured code, with generators and libs like co partially filling that need today, all of which work in tandem with promises.

So I think with those two things io.js is on a path to become more like what TJ wanted (but was too impatient to wait for).

@moreofmorris
Copy link
Author

Great thread, interesting read. Thank you for this.

@cjihrig
Copy link
Contributor

cjihrig commented Jan 15, 2015

Feel free to continue the discussion, but I'm going to close this issue as it's not really actionable.

@cjihrig cjihrig closed this as completed Jan 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants