@paddybyers Your explanation of the application state issue is very eloquent and matches my own reasoning.
@isaac, @mikeal, This is turning into a real joke! You tell us that you would like to change process.nextTick and you ask us for feedback. Several people respond that this change is problematic for them and that they would much prefer that you introduce a *new* API and use it internally to solve your problems (and optionally make this new API public so that other people who have similar problems to solve can solve it the same way you do). If you had listened to them, you'd have said: "ok guys, we understand that this is a problem for you; there is another easy path that solves the problem for us and won't put anyone else in trouble; let us do it." Case closed. Everyone can move forwards! Instead you reply that anyway, the issue is already settled, the API will change, and all the people who are asking for process.nextTick to be preserved are just misusing node and need to rethink their applications with child processes. If the issue was settled from the start anyway, you shouldn't have asked: just make the change and tell us afterwards! Don't pretend that you care about our opinion! The problem is that people like me (I don't know about paddybyers but I'm assuming he is in a similar situation) are building real applications for real customers, not I/O libraries for other nodejs developers. And you guys simply don't know what building a real application means! One thing you'll learn the day you build an application for real customers is that your audience is not made of geeks so you cannot tell them to just post a stacktrace on GitHub when something goes wrong. They don't know what a stacktrace is; they don't know what GitHub is either; they don't want to know what these things are; and there is no point trying to teach them! What they need is very robust exception handling and meaningful error messages. You'll also learn that you have to listen to what your customers say (behind every vocal customer, there are several silent ones). Another thing you'll learn is that applications have "requirements". Everyone's not busy building the next Facebook. Some of use are building applications that will serve 1000 simultaneous users in the worst case. Some may even be building applications for very small businesses with less than 10 users. These applications may be less I/O intensive and more CPU intensive than the typical "next gen proxy" you have in mind. The people who are building them may have built similar applications on top of other stacks before. They probably know the CPU and I/O patterns that their applications have. They may be ready to trade a bit of "technical purity" for "pragmatic solutions", like building things that are not entirely stateless. And they may still have very valid reasons to want to build them on top of node.js rather than Ruby or PHP. They are probably not spending their days writing fibonacci or prime number generators, etc, etc. So, when we tell you that we find process.nextTick useful because it allows us to time slice computations, it does not mean that we don't understand node. It just means that we know what we are building, that we have built similar things before with other stacks, that we have done our homework with the figures and that we consider that this approach is completely viable for *our* use cases. So, please stop saying that we are doing things wrong and that our opinion should not matter. We are building real things and we know what we are doing. You just don't know what we are doing! Please, listen to your customers! Bruno On Thursday, May 31, 2012 10:45:58 PM UTC+2, Mikeal Rogers wrote: > > > On May 31, 2012, at May 31, 20121:21 PM, Paddy Byers wrote: > > Hi, > > If a collection is of "indefinite size" then it should not be loaded >> entirely in to memory in order to accomplish computation, it should be >> streamed. In the case of streaming the collection you can iteratively >> perform the computation without locking up the process indefinitely and >> without taking on a large memory footprint of either the original >> collection or even what has already been processed. >> > > Yes, you stream application data in and out of your application. But I'm > talking about application state, such as anything you have on a > per-connection or per-token basis, for example. It's in memory because it's > your application, not your application's data. > > > If that data is of "indefinite size" then it needs to be out of process. > This is why Redis and memcache exist. > > I don't see any argument for computationally intensive tasks on > application data of "indefinite size" that much be entirely in process > memory at one time. > > > Thanks - Paddy > > >
