Repository navigation
Does io.js address the problems that TJ Holochuck expressed? #399
Description
Activity
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.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 :)
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.
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.
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?
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.
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 insteadIdea is to give users some upgrade path so they can stay up-to-date with latest APIs without too much efforts.
@YuriSolovyov that is the plan for deprecation of the
sysanddomainsmodules :)@mikeal is that a general strategy for any breaking changes, not only deprecations?
@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.
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.
- Promises are now adopted into the language, which add some better guarantees about if/when/how many times callbacks are called.
- 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).
Great thread, interesting read. Thank you for this.
Feel free to continue the discussion, but I'm going to close this issue as it's not really actionable.
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