Everybody, These debates give me hives. Seriously, they make my skin crawl.
If you think that providing an API for threads is a great idea, then just go do it, as a userland module. Jorge did. What's the big deal? Some people like it, some people don't. That's how anarchy works. Think his threads_a_go_go thing is the wrong abstraction? Fine. Do a different one. It's just code. Write some. There's plenty of room in the npm registry for all of us. If you think that such a thing absolutely MUST be provided by the core library, then that belongs in a github issue. Be prepared to make a VERY strong case for it. It's a huge change to the architecture, which was tried in the past and turned out to be not a good idea. You'll need to be patient (since it will take a while), be willing to help work on it, and have a plenty of new data showing that it's actually a valuable change to make in the core, and why the problems encountered last time can be overcome. I can tell you that it won't have any chance of landing before 2.0, and you'll have to (at least) convince Ben Noordhuis and Bert Belder that it's worth doing. They're both rather skeptical right now, and stubbornly fixated on "evidence" and "use cases" and "reasonable trade-offs", so that'll be an uphill climb, but I've found them easy to convince if you can provide these things. If you convince them, that's probably the best way to convince me. This is software. All is flexible. But we're not going to make architectural changes just because someone says that we have to, using strong words and providing no data. That's not responsible, for a platform that is used in production by real companies making real money. If you can do it in userland, great. Go do that. There's a good chance we'll never do it in core, then, since we don't have to, it's a lot of work, and there's no compelling reason to. If you can't accept that, and can't convince us to do it in core, then weigh your discontent against the work of forking node and creating a new project. Some of us will probably even help you. It might be an interesting project :) If you are annoyed that people don't *like* the module that you wrote, or the project you forked, well, get over it. Some people hate request and express. I have issues with underscore and never use it in my projects, and Mikeal calls me crazy and superstitious for that. Maybe he's right. And those are the most popular modules out there. I would urge any software developer (or any creative person in any field) to divorce their self-esteem from the things that people say about their work. Yes, of course, we all want to build things that are appreciated by the people we respect; but there's always a crowd of nay-sayers. You should be worried when you write a program and no one talks shit about it, because it means you're probably not doing anything interesting or important. I would very much like to get away from the idea that anyone should make passionate speeches about how the world will end if we don't do some feature in node-core, or if some module is or isn't used by everyone or anyone. Lighten up. We can all do our thing, explore and experiment, and so on. Having a small set of core functionality is an important part of a healthy module ecosystem. We won't be making dramatic architectural changes to node any time soon, and certainly not without data to justify it. In debates like this, both sides tend to miss most of the subtlety of what is actually involved with making major changes to a platform like node. These debates are an annoying distraction from actually getting anything done. It's not about dogma vs features. We aren't married to Ryan's original vision of Node; in fact, he wasn't even married to that vision when he was running the project. We've deviated from that vision numerous times. (Qv. commonjs-style module system, synchronous fs functions, isolates, domains as a JavaScript abstraction rather than a shared-nothing IO isolation, etc.) In each case, we've done our best to make decisions based on the trade-offs and data from real world use cases. Since he's stepped down from day-to-day management of the project, we've even rejected a few of his feature requests! Anyone who accuses the Node project of being dogmatic hasn't been paying attention. Our dogma is just a shorthand for experience, which is the sum of accumulated evidence; if you want to change it, provide new evidence. It's not that hard. I've seen it happen several times. You know who almost never gets involved in these shenanigans? TJ Holowaychuk, James Halliday, Matt Ranney, and the folks at Joyent and LinkedIn and Voxer and Cloud9. Do you know why? Because they're too busy getting things done, writing modules, and keeping production systems running. What's childish and unprofessional is flinging insults because node doesn't have a feature you want. Node is for builders, and builders aren't here kvetching over node's lack of threads. They're complaining that TLS is 10x slower than stud or nginx, that readable streams are too hard to extend properly, and that http is slower than it ought to be. There is no end to the complaints that they send my way, and taking on a monumental architectural change because a vocal minority says we need to, would mean turning our backs on those builders. That'd be amateurish. Go build something. Come back when you can tell me what you couldn't ship because you didn't have threads. -- 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
