Isaac: I fully confess to being an ignorant childish distracting useless retrogressive drag on the community, and I'm sorry if this discussion in fact hurts us. Also, seek trained medical professional help.
Alas, the hunger to know more about this topic STILL calls at me. It did before Isolates was cancelled, it did when Isolates was cancelled, and I sought to rectify my ignorance by asking others, not investigating the source which I feel less than capable of, and blaming no one I did not get the help I requested highlighting the "subtleties" of the technical landscape surrounding this still interesting feature: https://groups.google.com/d/msg/nodejs/zLzuo292hX0/xb30bmk3ds8J Please let me know if you have constructive advice for better ways to seek knowledge than what I've done here, or back in February when Isolates was canned. I wish to become more informed, and hope this community is civil and mature enough to help explore the topic with me. Respect, -rektide On Monday, September 17, 2012 6:09:32 PM UTC-4, Isaac Schlueter wrote: > > 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 [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
