Do you guys wonder why there is a collective groan when you show up? Especially considering how difficult it is for a group of geographically remote people to convey a collective groan in a written medium ;)
Threads-a-go-go lives exactly where it should; in userland where anyone who wants to can try it. You should stop being so bothered by how things work in the community. There are so many people in the node community that wish their modules got more attention. Those people don't have nearly as many stars and forks on github as threads-a-go-go. Whatever it is you think you're entitled to, you've already got it. :Marco PS: And find some way to get rid of the "eval" thing for chrissakes. If you want javascript people to take you seriously, show them you're serious about javascript. On Monday, September 17, 2012 12:20:13 AM UTC-7, Bruno Jouhier wrote: > > > I've got some idea what Nuno is groaning about. :) Threads-a-go-go is a >> pretty daft silly thing. >> It's certainly not the safe sane shared-nothing threading that keeps Node >> & JS safe. That >> responsible multi-threading work was attempted in the 'isolates' branch >> of Node.js. I would >> definitely not push the threads-a-go-go work upstream. :) >> > > My FUD detector is blinking red!!! > > Threads-a-gogo is perfectly safe and 100% shared nothing. Every worker > thread runs in its own isolate, and worker threads communicate with the > main thread by passing immutable strings. > > If you did not take the time to experiment about it or just read about it, > don't post counter-truths like this. > > If TAGG could be criticized, it would be for lacking certain useful > features. To me, the most crying ones are 1) a module system and 2) the > ability to transfer ownership of objects (so that we don't have to > serialize everything), or at least pass "frozen" objects. > > I don't know if this is behind Crockford's comment but the "thread-a-gogo" > story is, IMO, a perfect illustration of the lack of professionalism that's > going to hurt node. Instead of embracing something that brings a plus to > node (the ability to write CPU intensive operations in JavaScript, with > worker threads) and was carefully designed to be aligned with the basic > node model (CPU intensive operations are handled as async ops with a > standard node callback, eventing API between threads is aligned on node's > emitter API), the solution is being at best ignored, when not covered with > FUD. The end result is that we are going to get tens of half-backed > threading libraries instead of having consolidation around one promising > solution (that needed help). > > The dogma will be preserved (threads are bad, you need to do this with > processes and shared memory, even if this is less performant and more > complex) but this is just a childish attitude. > > My 2 cents, > > Bruno > -- 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
