I'm sure Isaacs has said as much several times: - Core won't be changing dramatically (i assume this includes moving the entire stdlib to an alternate IO pattern) - node.js takes v8 "as is" (i assume this means we won't be disabling features in the language just because a few people complain about them, even if they are slow which I'm not convinced they will be)
This discussion is really about what the healthy patterns and usage will be in the ecosystem, which is ultimately far more important. -Mikeal On Aug 6, 2013, at 8:30AM, Rick Waldron <[email protected]> wrote: > > > > On Tue, Aug 6, 2013 at 11:12 AM, greelgorke <[email protected]> wrote: > Uh, i don't say, fork and prevent. we're talking about adapting language > feature into core code, right? never said, node should do that. i said, don't > addapt anything, if it doesnt make node better than before. > > Then I apologize for misunderstanding the point of this: > > "i think its hard to reason about if node should keep with v8 and adapt es6 > features until we have real field experience with them." > > I still don't see where exactly the discussion had become node-code-centric, > but I'll give you the benefit of the doubt and concede my wrongness. > > Rick > > > > Am Dienstag, 6. August 2013 16:58:21 UTC+2 schrieb Rick Waldron: > > > > On Tue, Aug 6, 2013 at 5:35 AM, greelgorke <[email protected]> wrote: > Few points in my opinon: > > 1. Callbacks are not un-intuitive. We do it all the way in our life. i mean > besides the programming. > 2. Callbacks are not hard to compose. they are functions, do them right, > nothing stops you to compose, currie or memoing anything. > > One just have to make a little switch in his/her mind. I find it surprising, > that many of us are willing to make a bigger switch to more abstract > concepts, just to be back in old sync-imperative world... And it doesn't even > save you from this so annoying task to think about your architecture... > > Besides of the callbacks, i think its hard to reason about if node should > keep with v8 and adapt es6 features until we have real field experience with > them. > > Node.js (the core) isn't obligated to immediately use ES6 features, but > forking v8 to prevent the use of new language features will only result in > Node.js stagnation and ultimately, abandonment. I think it's safe to say that > won't happen. > > Rick > > > > Node is supposed to be done and be crazy fast. so i'm with Trevor here. > > Am Dienstag, 6. August 2013 10:38:22 UTC+2 schrieb Trevor Norris: > I'd like a clarifying point. By callback system I'll assume that means the > EventEmitter modal. > > But the concept of abstracting the callbacks away using a more composable > > and more natural way is definitely a good thing, at least in my opinion. > > The callbacks are a implementation detail of asynchronous io but low-level > > stuff is not what a normal developer should rely on. > > Getting to the point of calling the callback has gone through so many layers > of abstraction I'd hardly call it low-level. > > > Nodes key feature is that it strongly encourages thinking about concurrency > > but the best concurrency abstraction is the abstraction which abstracts > > concurrency totally away. All I'm saying is that the node library could > > evolve when the language does. > > As far as I'm concerned most the new "features" coming to JS are sugar. The > event based callback system is straight forward and cheap. Well, it _can_ be > cheap. Also easily extendable. I don't buy the argument it's unnatural or > difficult to reason. It's simple to define. The end of an asynchronous task > is an event. Then, if there's a listening callback it gets fired. > > There are many ways to handle this, and unfortunately it seems there's > inconsistency. Do we just have one callback that we always call and pass the > status, or do we listen for several events and only fire for those that have > listeners? It's all implementation details, but adding an extra layer of > keywords and control flow isn't going to remove the fundamental problem. > That's easy enough to see in this thread. Even to the point of discussion > variable naming conventions to remove confusion. Seriously? > > I used to be on the band wagon of "let's chain all the things!" Then I began > to see how all the map() and forEach() in the world just makes things run > slow. It's all just syntactic sugar that for some reason makes developers > feel fuzzy. And it encourages bad patterns like writing functions in > functions. Can it be done? Yes, but if you ever take the time to trace > execution you'll see it has to reoptimize that code every time. > > And at the very least, until those "features" work without introducing > performance penalties I can't see them being integrated into core. > > > > > > > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > [email protected] > > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
