Reaction to article: Node is Cancer
Tauren Mills
http://teddziuba.com/2011/10/node-js-is-cancer.html
Wish I could respond to his blog entry, but he doesn't have any
commenting enabled.
Isaac Schlueter
> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
Matt Patenaude
Matt Patenaude
Sent from my iPhone
Joshua Kehn
Isaac Schlueter
Seriously, who here *hasn't* heard that you shouldn't do cpu-intensive
operations in JavaScript? That's not even an area where node "needs
improvement", or some such. Seriously, who calculates the fibonacci
sequence in a web server, or does so using the naive recursive
formulation? It'd completely contrived and idiotic.
Ted Dziuba presents easily-digestible rants for people who want a
reason to not learn about new things. He's the tech equivalent of
Rush Limbaugh. He's a childish amateur troll.
I'm happy that we won't have his antics on this list, since he's not
going to be using node.
chjj
node's selling point was that it "never ever ever ever blocks"? What a
stupid person. Would anyone ever claim that?
IO doesn't block in node, which is good. And sure, it can be
considered a certain weakness of node - sometimes we want to write CPU
intensive code in node, and there is no way to avoid blocking for a
considerable amount of time. You could start up a worker, but for a
lot of things its more work than its worth. But honestly, this problem
has never bitten me that much. (One such example would be a slow,
blocking, markdown parser, ...which is what lead me to write my own
optimized markdown parser: https://github.com/chjj/marked ;). As
mentioned above, I don't think node is here to solve *every*
conceivable problem. It does things a certain way, and I like it.
Liam
eio/uv thread pool. However...
That's not Javascript.
Until there's a JS worker process pool which is trivial to invoke (and
doesn't require stringify/stream/parse IPC), that kind of critique
will persist.
On Oct 2, 3:25 pm, Isaac Schlueter <i...@izs.me> wrote:
> Node is optimized for IO-bound operations. Most network tasks are IO-bound.
>
> Seriously, who here *hasn't* heard that you shouldn't do cpu-intensive
> operations in JavaScript? That's not even an area where node "needs
> improvement", or some such. Seriously, who calculates the fibonacci
> sequence in a web server, or does so using the naive recursive
> formulation? It'd completely contrived and idiotic.
>
> Ted Dziuba presents easily-digestible rants for people who want a
> reason to not learn about new things. He's the tech equivalent of
> Rush Limbaugh. He's a childish amateur troll.
>
> I'm happy that we won't have his antics on this list, since he's not
> going to be using node.
>
> > I should also add that these are *current weaknesses*, not "reasons Node is
> > doomed to fail". Implementing something like WebWorkers would considerably
> > ease the compute issue.
> > The real point here that I think is well-made is that conventional wisdom,
> > in experienced hands, usually has sole validity. While event loops are
> > better equipped to deal with a majority of the things that amateur
> > programmers would use threads for, they're not the panacea for blocking
> > software.
> > -Matt
>
> > Sent from my iPhone
Matt Patenaude
As
mentioned above, I don't think node is here to solve *every*
conceivable problem. It does things a certain way, and I like it.
Jorge
Unfortunately, the truth is that exactly that same program in rails in an 12 cores machine would serve fibonaccis 12x times faster than node.js
Node has issues with cpu bound tasks, still awaiting a solution... and that, @izs, face it, is *not* bs
--
Jorge.
Nuno Job
Krishna Guda
Node Punishes Developers Because it Disobeys the Unix Way
the above was the title of the last paragraph which is completely unfounded. Does Linus watch this thread? isaacs npm alone is an answer for a bunch of the the "loosely coupled" concerns. and i don't think that ryan did this to eliminate system admin jobs either.Isaac Schlueter
fibonacci numbers, and have only rails at your disposal, then you've
got bigger problems. Better start praying that the Dark Lords of the
Matrix don't make it rain frogs or something.
Here's a knowledgeable person saying reasonable things about Node and
Rails and PHP:
http://www.mikealrogers.com/posts/a-new-direction-for-web-applications-.html
Ted Dziuba is just lazy. With just a bit more effort, he could have
maybe come up with something really exciting to criticize. He's a
disgrace to the venerable art of trolling. The only upsetting thing
about this article is that people pay so much attention to such a wart
of a person.
Stewart Mckinney
http://teddziuba.com/2011/03/osx-unsuitable-web-development.html
http://teddziuba.com/2010/08/too-smart-for-git.html
http://teddziuba.com/2009/09/twisted-vs-tornado-youre-both.html
He's intelligent, but he probably gets a bigger high off of spewing rage then solving a problem eloquently.
Isaac Schlueter
two together.
Many many people have one of those traits, but lack the other.
chjj
success. Node is popular enough now that we actually have people
criticizing blocking code for blocking. I think we owe it to passing
jquery on github, and probably within the next month, rails.
Sotonin
Sotonin
chjj
based on its merits. He immediately jumps into criticizing the users
of node who like its capacity for buzz-wordery. There will be those
people in every new platform, and I'm sure everyone is sick of them.
It's very easy to overlook that platform's qualities when you can't
stop thinking about how annoyed you are by those people, and it really
shows here. The *very first* thing he tackled in this article, wasn't
node itself, but the buzz-word people who like saying "event loop".
I think he's revealing too much of his hand there. But of course, he
redeemed himself in that area by running a single benchmark, right?
I'm sure in the earlier days of node, before socket.io and express
were on every street corner, it would have been easier for guys like
him to get interested in node. I think people like him might just see
node as a kind of trendy little toy for shiny new web apps now.
(Although I should clarify, socket.io & express are very nice).
I'll be surprised if he's done any real research on node, and I don't
know where he was going with that snippet of code at the end.
There's also the ever-present approach of "I fucking curse a lot on
the internet, which should lead you to believe that I'm more genuine
and honest, and I tell it like it is. See? I'm just a regular guy, and
you should trust my opinion because of it." If I'm off-base here,
someone let me know.
/semi-rant
Karl Tiedt
behind a closed comment system...
Until then... give him the attention he deserves... and that would
be... about 18 less emails than its already been given ;)
-Karl Tiedt
Pavan Kumar Sunkara
about not being more intelligent.
If he is, he would surely know node is not used for calculating
fibonacci numbers.
--
- Pavan Kumar Sunkara
Joshua Kehn
Joshua Kehn
Joshs-MacBook-Pro:~ josh$ time curl http://localhost:1337/
165580141
real 0m3.942s
user 0m0.004s
sys 0m0.004s
Joshs-MacBook-Pro:~ josh$ time curl http://localhost:8888/fibserver.php
Number is: 165580141
real 1m22.709s
user 0m0.004s
sys 0m0.005s
The PHP code is an exact port of his JS code, available at https://gist.github.com/1258315
Anyone want to write a Rails implementation?
Regards,
–Josh
____________________________________
Joshua Kehn | @joshkehn
http://joshuakehn.com
Isaac Schlueter
email address.
http://blog.izs.me/post/10213512387/javascript-is-not-web-assembly#respond
Joshua Kehn
Chris Sanz
Sent from my iPhone
Joshua Kehn
Aikar
caching the results of database queries to memcache and redis...
http://teddziuba.com/2011/06/most-important-concept-systems-design.html
On Oct 2, 11:26 pm, Joshua Kehn <josh.k...@gmail.com> wrote:
> Unfortunately curiosity killed me and I ended up writing a Python variant as well.http://joshuakehn.com/2011/10/3/Diagnosis-No-Cancer.html
> Now I need to get back to working on some canvas popovers.
>
> Regards,
>
> –Josh
> ____________________________________
> On Oct 2, 2011, at 11:19 PM, Chris Sanz wrote:
>
>
>
>
>
>
>
> > This guy Ted doesn't deserve all this attention. His angry blog post is just that... An angry blog post. He clearly cares very little about us devs (or the Node.js community). he is screaming for attention... Calling names on people he hasn't even met (coward/bully) and belittling tech he doesn't even understand (troll - silly programming example). I decided to respond when I saw that he is actually 'silently' reading this thread... (coward) and not really responding w/ the same enthusiasm. Sad to see fellow devs being so negative and nasty. Anyway... back to coding!
>
> > Sent from my iPhone
>
>
> >> Ted's (tjdzi...@gmail.com) and mine are shared on our respective blogs as well.
> >> Now getting Ted to respond to comments is an entirely different matter. My experience is he won't.
>
> >> Regards,
>
> >> –Josh
> >> ____________________________________
> >> Joshua Kehn | @joshkehn
> >>http://joshuakehn.com
>
> >> On Oct 2, 2011, at 10:42 PM, Isaac Schlueter wrote:
>
> >>> I don't have commenting enabled on my blog, either. But I do share my
> >>> email address.
> >>> On Sun, Oct 2, 2011 at 19:34, Joshua Kehn <josh.k...@gmail.com> wrote:
> >>>> Looks like you wouldn't use PHP either:
>
> >>>> real 0m3.942s
> >>>> user 0m0.004s
> >>>> sys 0m0.004s
> >>>> real 1m22.709s
> >>>> user 0m0.004s
> >>>> sys 0m0.005s
>
Stewart Mckinney
Anyone want to write a Rails implementation?
Regards,
–Josh
I'll do a Ruby+Sinatra one tomorrow morning. No need for Rails in this.
Joshua Kehn
Pavan Kumar Sunkara
We should give publicity to joshua's blog post.
Joshua Kehn
–Josh
Joshua Kehn
–Josh
Bradley Meck
Bruno Jouhier
If people don't want to try new things, that's their problem and
that's fine. But what's the point of insulting those who do and who
are making things move forwards (even if not always in a straight
line).
Bruno
Ask Bjørn Hansen
On Oct 2, 2011, at 14:42, Tauren Mills wrote:
For someone who's only worked professionally for a few years (according to linkedin) it seems a bit early to be yelling "Get off my lawn" like that, but there you have it. :-)
- ask
--
Ask Bjørn Hansen, http://askask.com/
Nicolas Chambrier
Have you *really* made the test for ruby ? I tried with PHP, python and scala, and node was actually the fastest (I mean, really, like 8 seconds versus 2 minutes). I wasn't even expecting that, but I must thank Ted for this: I would have never made such a test without his motivation, and now I can really tell Node is damn fast, thanks v8, and thanks Ted.
On 02/10/2011, at 23:42, Tauren Mills wrote:
> I'd like to hear the reactions of other node developers to this article:
> http://teddziuba.com/2011/10/node-js-is-cancer.html
>
> Wish I could respond to his blog entry, but he doesn't have any
> commenting enabled.
Unfortunately, the truth is that exactly that same program in rails in an 12 cores machine would serve fibonaccis 12x times faster than node.js
Node has issues with cpu bound tasks, still awaiting a solution... and that, @izs, face it, is *not* bs
--
Jorge.
dvbportal
Joshua Kehn
Tauren Mills
bringing it up and wasting everyone's time with this troll, but I'm
sure it would have came up regardless. Everyone get back to work!
>> On Oct 2, 2011, at 14:42, Tauren Mills wrote:
>
> For someone who's only worked professionally for a few years (according to linkedin) it seems a bit early to be yelling "Get off my lawn" like that, but there you have it. :-)
> --
> Ask Bjørn Hansen, http://askask.com/
Bjørn, I'm assuming your comment is a misplaced response to Isaac in
the 'metaprogramming' thread, where he says "Maybe this is the part
where I shake my cane at the ruby kids on my
lawn". I have far more than a "few professional years" behind me, but
I have yet to start yelling "get off my lawn". At least give me
another decade... ;)
Tauren
Ask Bjørn Hansen
On Oct 3, 2011, at 0:40, Tauren Mills wrote:
Hi Tauren,
>> For someone who's only worked professionally for a few years (according to linkedin) it seems a bit early to be yelling "Get off my lawn" like that, but there you have it. :-)
>
> Bjørn,
It's Ask, really. :-) See http://askask.com/
> I'm assuming your comment is a misplaced response to Isaac in
> the 'metaprogramming' thread,
I'm really sorry. My comment was, I thought obviously, directed at Ted's "article" -- not at you or Isaac! I wouldn't have replied publicly further in this thread, but I just wanted to make that clear.
> where he says "Maybe this is the part where I shake my cane at the ruby kids on my
> lawn". I have far more than a "few professional years" behind me, but
> I have yet to start yelling "get off my lawn". At least give me
> another decade... ;)
We're probably all there now and then without realizing it. ;-)
- ask
Egor Egorov
On Monday, October 3, 2011 1:25:34 AM UTC+3, Isaac Schlueter wrote:
Seriously, who here *hasn't* heard that you shouldn't do cpu-intensive
operations in JavaScript?
Nicolas Chambrier
But still, many small-brained people (which includes many ITs "leaders" and managers) could believe his bullshit :(
Liam
to pool Node processes and queue jobs when the pool is busy?
In the rush to defend Node and bash the troll, most overlook the valid
point that cpu-intensive tasks should be performed asynchronously, and
child_process.fork() is not a complete solution.
Christian Sanz
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
Chris Sanz
Cofounder & CTO
@csanz
Skype: chrissanz
Jorge
Have you *really* made the test for ruby ?
I tried with PHP, python and scala, and node was actually the fastest (I mean, really, like 8 seconds versus 2 minutes). I wasn't even expecting that, but I must thank Ted for this: I would have never made such a test without his motivation, and now I can really tell Node is damn fast, thanks v8, and thanks Ted.
Jorge
> The tone and vocabulary just put me off.
>
> If people don't want to try new things, that's their problem and
> that's fine. But what's the point of insulting those who do and who
> are making things move forwards (even if not always in a straight
> line).
+1
--
Jorge.
Jorge
All programming languages are cancers. But node is one of the good cancer
--
Jorge.
Jorge
> Threads do not scale on cores as people might think they do.
They certainly do on darwin/OSX and in the current generation of intel cpus.
--
Jorge.
Jorge
> In the rush to defend Node and bash the troll, most overlook the valid
> point that cpu-intensive tasks should be performed asynchronously, and
> child_process.fork() is not a complete solution.
Exactly. +1
--
Jorge.
Branko Vukelić
> I'd like to hear the reactions of other node developers to this article:
> http://teddziuba.com/2011/10/node-js-is-cancer.html
You know what artists say: People will find many flaws in good art, but
bad art has only one flaw -- itself. Nobody is dismissing Node as a
whole as bad. Not even the original article claims that. You can find
small flaws here and there on any platform, and those get fixed, and new
flaws surface. That's how things are.
--
Branko Vukelic
bra...@brankovukelic.com
bra...@herdhound.com
IDEA MACHINE
www.brankovukelic.com
Lead Developer
Herd Hound (tm) - Travel that doesn't bite
www.herdhound.com
Love coffee? You might love Loveffee, too.
loveffee.appspot.com
Bradley Meck
Dave Clements
intensive tasks, php is limited on cpu intensive tasks...
if node answered the main parts of a problem, but there was a cpu
intensive part..say for instance..
a high demand monthly subscription service that provides fibonnaci
calculations (in real time!) to an obviously overwhelming amount of
users, say node took care of the delivery of the result, and the
website etc, what is the best option for outsourcing the cpu intensive
stuff?
From reading so far I've seen, (possibly) rails, or C.
If you really were to do this, what would be the definitive answer?
How would python or perl fair?
Are there any real use cases where CPU intensive tasks would be
required to an extent that they would cripple nodes performance beyond
acceptability?
dave
David Herron
> I'd like to hear the reactions of other node developers to this article:http://teddziuba.com/2011/10/node-js-is-cancer.html
>
> commenting enabled.
http://nodejs.davidherron.com/2011/10/is-nodejs-cancer-no-it-quite-nice.html
I found it interesting that his main example - Fibonacci - is an
example I used in the book Node Web Development. But in the book,
rather than using Node's behavior with that algorithm as a weapon, I
used it as an example of strategies to avoid/fix this class of
problem. The observation is that occasionally you'll write a slow
algorithm, that authentically has to do some serious processing, so
what do you do in that case? Optimize the algorithm? Refactor it to
be asynchronous and dispatch work through the event queue? Refactor
it to a back-end service?
+ David Herron
http://davidherron.com
Bradley Meck
Marak Squires
I'd like to hear the reactions of other node developers to this article:
http://teddziuba.com/2011/10/node-js-is-cancer.html
Wish I could respond to his blog entry, but he doesn't have any
commenting enabled.
Evgeny Bogdanov
Well, for me that's one of the best parts.
I have already reused a lot of code between server/client.
I also plan to move some processing functionality from server to the client,
with JS it's easy. With Ruby/PhP I'd have to rewrite these algorithms from scratch.
I am quite happy with my node installation and starting to use it in production
starting from tomorrow :)
Thomas Love
can assume these are the biggest criticisms he can muster, I feel
better about using Node in future.
I also think the criticisms here of his Fibonacci example are missing
the point, which I took to be straightforward: Node's claims that the
"process never blocks" are false, at least in that unqualified form,
and this might mislead the undiscerning (and beginners, myself
included) into a false sense of scalability-security.
Thomas
Stewart Mckinney
Liam
Since you specified Node as the front end, it would be straightforward
to create a Node plugin in C++ which runs in the I/O thread pool. Yes,
I/O ops are multi-threaded.
You ought to be able to prototype it in Javascript, but Node doesn't
provide a pool of worker processes nor a queue of pending tasks. Also,
you can only do stringify/stream/parse IPC with a worker process
(which is fine for small amounts of data, but slow if you need to move
a lot of data back and forth; for that you'd want mmap/signal or the
like).
Matt
Isaac Schlueter
>
> Says who? I do trading algo in node.js and some computational tasks last for
> hours on a cluster. And it's perfectly fine with me! :) Web-server? Who said
> web-server? :)
Fair. To be more precise:
You should not do CPU-intensive operations in the main JavaScript
thread if it is also responsible for handling requests in a
low-latency manner.
Ricardo Tomasi
from recursiveness. A non-recursive function can get similar (or
better) performance.
On Oct 3, 4:16 am, Joshua Kehn <josh.k...@gmail.com> wrote:
> It's fast because of V8's optimizations. I ran a quick comparison (without the HTTP overhead) with C and Java and got:
>
> Java: 0m0.612s
> C: 0m1.231s
> JS: 0m3.914s
> Python: 0m48.240s
> PHP: Not tested
>
> Now we're just looking at the optimizations done by each compiler / interpreter. V8 and the JVM are doing work to optimize the recursive calls which places them ahead of languages generally regarded as “faster“.
>
> Regards,
>
> –Josh
> ____________________________________
Egor Egorov
Louis Santillan
http://www.infoworld.com/print/174559
-L
Joshua Kehn
Joshua Kehn
Ruprict
Branko Vukelić
> A non-recursive function would be the obvious choice if this was a real
> problem.
Obvious is not the same as optimal. It's usually the other way around.
Joshua Kehn
Charlie McConnell
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
Joshua Kehn
gotrich
own intelligence, and understanding of all things software, yet he
doesn't allow comments (non-anonymous)
as isaac pointed out very well, most of his arguments are baseless and
of a rush limbaugh mindset.
ted hasn't done the analysis of how node works when solving the right
problem, and isn't willing to let go of his childish bias against
javascript.
i *absolutely hated* javascript 2 years ago. now I can't think of
coding in anything but nodejs/javascript.
rich
On Oct 2, 7:48 pm, Joshua Kehn <josh.k...@gmail.com> wrote:
> Ted's (tjdzi...@gmail.com) and mine are shared on our respective blogs as well.
>
> Now getting Ted to respond to comments is an entirely different matter. My experience is he won't.
> Regards,
>
> –Josh
> ____________________________________
> Joshua Kehn | @joshkehnhttp://joshuakehn.com
>
>
>
>
>
>
>
>
> > I don't have commenting enabled on my blog, either. But I do share my
> > email address.
> >http://blog.izs.me/post/10213512387/javascript-is-not-web-assembly#re...
>
> > On Sun, Oct 2, 2011 at 19:34, Joshua Kehn <josh.k...@gmail.com> wrote:
> >> Looks like you wouldn't use PHP either:
>
> >> Joshs-MacBook-Pro:~ josh$ time curlhttp://localhost:1337/
> >> 165580141
> >> real 0m3.942s
> >> user 0m0.004s
> >> sys 0m0.004s
> >> Joshs-MacBook-Pro:~ josh$ time curlhttp://localhost:8888/fibserver.php
> >> Number is: 165580141
> >> real 1m22.709s
> >> user 0m0.004s
> >> sys 0m0.005s
>
> >> The PHP code is an exact port of his JS code, available athttps://gist.github.com/1258315
>
> >> Anyone want to write a Rails implementation?
> >> Regards,
>
> >> –Josh
> >> ____________________________________
> >> Joshua Kehn | @joshkehn
> >>http://joshuakehn.com
>
>
> >>> His article is hilarious. You can see from his words that he is bitter
> >>> about not being more intelligent.
>
> >>> If he is, he would surely know node is not used for calculating
> >>> fibonacci numbers.
>
> >>> --
> >>> - Pavan Kumar Sunkara
Ryan Dahl
> I'd like to hear the reactions of other node developers to this article:
> http://teddziuba.com/2011/10/node-js-is-cancer.html
>
> Wish I could respond to his blog entry, but he doesn't have any
> commenting enabled.
We need to make it more obvious to people that Node is not limited to
accepting connections on a single thread. That would avoid confusing
inexperienced programmers. Over the next couple months Ben Noordhuis
and I will be working on integrating some of the basic features found
in modules like Cluster into Node core. The ultimate goal is that the
hello world example on the webpage will run across multiple processes
with a simple command line flag.
Matt
Nicolas Chambrier
Forget forever complaining douches, that would be great for node to provide such a solution in core. Go go go :)
--
Branko Vukelić
> Forget forever complaining douches, that would be great for node to
> provide such a solution in core. Go go go :)
Big +1 to that
Liam
Diogo Resende
anyone
thinks otherwise, you should dedicate yourself to fishing and forget
about
programming. This is stupid and Ted is a troll.
Try this simple Fibonacci algo in Java and "Node":
function fibonacci(n) {
var a = 0, b = 1;
for (var i = 0; i < n; i++) {
a += b;
b = a - b;
}
return a;
}
Test it from fibonacci(1) to fibonacci(50). What do you think about
Java
performance now? Every language has pitfalls but this particular case
is
not a Node one..
---
Diogo R.
On Mon, 3 Oct 2011 14:35:20 -0400, Joshua Kehn wrote:
> Caching the resulting numbers is another obvious optimization.
>
> Of course this all centers around the idea that serving Fibonacci
> numbers is a real problem someone is trying to solve. Which it's not,
> just an example of blocking a process by spinning the CPU. A dumb
> example.
>
> Regards,
>
> –Josh
> ____________________________________
> Joshua Kehn | @joshkehn
> http://joshuakehn.com [18]
>
> On Oct 3, 2011, at 2:32 PM, Charlie McConnell wrote:
>
>> We're all skipping a step here.
>>
>> If this were actually a real-world problem, we would have stopped
>> and said to ourselves something like this:
>>
>> THE FIBONACCI SEQUENCE IS STATIC. IT WILL NEVER, EVER CHANGE.
>>
>> Furthermore, JavaScript's internal issues with integer precision
>> mean that whichever Fibonacci number comes last before the 52-bit
>> mark is the highest one you'll ever need to know. This is in the low
>> eighties somewhere. Spend three tenths of a second computing it on
>> start, every request just grabs the relevant array element after.
>>
>> Nobody should ever be re-computing a static sequence of numbers in a
>> busy process, in any environment. It's a waste of time and CPU.
>>
>> 2011/10/3 Branko Vukelić
>>
>>> On 2011-10-03 13:58 -0400, Joshua Kehn wrote:
>>> > A non-recursive function would be the obvious choice if this
>>> was a real
>>> > problem.
>>>
>>> Obvious is not the same as optimal. It's usually the other way
>>> around.
>>>
>>> --
>>> Branko Vukelic
>>> bra...@brankovukelic.com [1]
>>> bra...@herdhound.com [2]
>>>
>>> IDEA MACHINE
>>> www.brankovukelic.com [3]
>>>
>>> Lead Developer
>>> Herd Hound (tm) - Travel that doesn't bite
>>> www.herdhound.com [4]
>>>
>>> Love coffee? You might love Loveffee, too.
>>> loveffee.appspot.com [5]
>>>
>>> --
>>> Job Board: http://jobs.nodejs.org/ [6]
>>> Posting guidelines:
>>>
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>> [7]
>>> You received this message because you are subscribed to the
>>> Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to nod...@googlegroups.com [8]
>>> To unsubscribe from this group, send email to
>>> nodejs+un...@googlegroups.com [9]
>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en [10]
>>
>> --
>> Charlie McConnell
>> Support Engineer
>> Nodejitsu, Inc.
>> avia...@nodejitsu.com [12]
>>
>> --
>> Job Board: http://jobs.nodejs.org/ [13]
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> [14]
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nod...@googlegroups.com [15]
>> To unsubscribe from this group, send email to
>> nodejs+un...@googlegroups.com [16]
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en [17]
>
> --
> Job Board: http://jobs.nodejs.org/ [19]
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> [20]
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en [21]
>
>
> Links:
> ------
> [1] mailto:bra...@brankovukelic.com
> [2] mailto:bra...@herdhound.com
> [3] http://www.brankovukelic.com/
> [4] http://www.herdhound.com/
> [5] http://loveffee.appspot.com/
> [6] http://jobs.nodejs.org/
> [7]
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> [8] mailto:nod...@googlegroups.com
> [9] mailto:nodejs%2Bunsu...@googlegroups.com
> [10] http://groups.google.com/group/nodejs?hl=en?hl=en
> [11] mailto:bra...@brankovukelic.com
> [12] mailto:avia...@nodejitsu.com
> [13] http://jobs.nodejs.org/
> [14]
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> [15] mailto:nod...@googlegroups.com
> [16] mailto:nodejs+un...@googlegroups.com
> [17] http://groups.google.com/group/nodejs?hl=en?hl=en
> [18] http://joshuakehn.com
> [19] http://jobs.nodejs.org/
> [20]
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> [21] http://groups.google.com/group/nodejs?hl=en?hl=en
Arnout Kazemier
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
Ryan Dahl
> @Ry can you give a summary of the expected mechanism and API?
It will be a supervisor process with worker processes. Ideally it will
be transparent:
node -n 5 hello-world.js
hello-world.js:
require('http').Server(function(req, res) {
res.writeHead(200);
res.end("hello world\n");
}).listen(8000);
Diogo Resende
time node Fibonacci.js 500
1: 1
...
...
498: 5.325493296145951e+103
499: 8.616829160023857e+103
500: 1.3942322456169808e+104
real 0m0.083s
user 0m0.060s
sys 0m0.010s
---
Diogo R.
>> -Josh
Charlie McConnell
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en [10]
--
Charlie McConnell
Support Engineer
Nodejitsu, Inc.
avia...@nodejitsu.com [12]
--
Job Board: http://jobs.nodejs.org/ [13]
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
[14]
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com [15]
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en [17]
--
Job Board: http://jobs.nodejs.org/ [19]
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
[20]
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en [21]
Links:
------
[1] mailto:branko@brankovukelic.com
[9] mailto:nodejs%2Bunsubscribe@googlegroups.com
[10] http://groups.google.com/group/nodejs?hl=en?hl=en
[11] mailto:branko@brankovukelic.com
[12] mailto:avia...@nodejitsu.com
[13] http://jobs.nodejs.org/
[14] https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
[15] mailto:nod...@googlegroups.com
[16] mailto:nodejs+unsubscribe@googlegroups.com
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
Benjamin Gudehus
Matt
The obvious Fibonacci implementation would never be recursive. If anyone
thinks otherwise, you should dedicate yourself to fishing and forget about
programming. This is stupid and Ted is a troll.
Arnout Kazemier
answered completely random forcing us to build stateless apps (same counts for round robin
Diogo Resende
> 2011/10/3 Diogo Resende
>
>> The obvious Fibonacci implementation would never be recursive. If
>> anyone
>> thinks otherwise, you should dedicate yourself to fishing and
>> forget about
>> programming. This is stupid and Ted is a troll.
>
> No, you missed the entire point.
I understand what you mean, I know the weakness. Every language has
them.
But what's the point of talking about that using an algo that blows in
almost all languages? Java is no different.
Java has threads. What does it have to do with the blog post about
Fibonacci?
Only a troll would use threads on this example.
If someone wants to point out a language as being better for a specific
task,
be my guest, I might agree. But this post.. it's just stupid.
---
Diogo R.
Liam
var wk = require('workers');
wk.init(5);
...
http.Server(function(req, res) {
var task = wk.queue('task.js'. req);
task.on('start', function(data) {
res.writeHead(200);
});
task.on('data', function(data) {
res.write(data);
});
task.on('end', function() {
res.end();
});
});
Doesn't this give more flexibility, e.g. the server process can
maintain a cache and hit it before task queuing
modify the task data stream before relaying it
queue arbitrary modules to workers
On Oct 3, 2:12 pm, Ryan Dahl <r...@tinyclouds.org> wrote:
Charlie Robbins
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
Ryan Dahl
> Why transparent vs explicit, e.g.
>
> var wk = require('workers');
> wk.init(5);
> ...
> http.Server(function(req, res) {
> var task = wk.queue('task.js'. req);
> task.on('start', function(data) {
> res.writeHead(200);
> });
> task.on('data', function(data) {
> res.write(data);
> });
> task.on('end', function() {
> res.end();
> });
> });
>
> Doesn't this give more flexibility, e.g. the server process can
> maintain a cache and hit it before task queuing
> modify the task data stream before relaying it
> queue arbitrary modules to workers
We will also have a low-level API for managing the workers of course
but not as you imagine it. The 99% use-case is symmetric load
balancing. People will still complain about not being able to preempt
work being done for single connections but this is not easily
addressed with Node - nor is it that important - cooperative
multitasking is perfectly valid within a single process.
Dean Landolt
You should note that the slowness in Python (probably ruby too) comes
from recursiveness. A non-recursive function can get similar (or
better) performance.
Liam
combining the latter with the dispatcher? Seems like you'd get more
efficiency if the dispatcher knows when it doesn't need to dispatch,
but I suppose you mustn't overload a dispatcher with pending cache-
served requests.
Can you surface details the low-level API?
On Oct 3, 3:02 pm, Ryan Dahl <r...@tinyclouds.org> wrote:
Branko Vukelić
> It doesn't matter *what* the calculation is. If you block the event loop
> then nothing else gets a look-in while you're blocking it. It's that
> simple - that was the entire argument. And it's entirely valid and true.
This argument is starting to look like:
A: Hey I shot myself in the foot with your gun and it hurts like hell.
B: Yeah, well, the manual says you're not supposed to point it at...
A: I don't care what the manual says, I want a gun that I can shoot my
foot with without the blood and pain and all that crap!
B: Yeah, but you see, we don't sell guns like tha...
A: Fuck you man! You suck!
B: (shoots A in the head) See kido? This is how you use THIS gun.
--
Branko Vukelic
bra...@brankovukelic.com
bra...@herdhound.com
IDEA MACHINE
www.brankovukelic.com
Lead Developer
Herd Hound (tm) - Travel that doesn't bite
www.herdhound.com
Love coffee? You might love Loveffee, too.
loveffee.appspot.com
Jorge
The API I'd love to have to run cpu-bound tasks (a task = a javascript function + a javascript data object) in the background:
execInBackground(fibonacci, 50, cb);
function cb (err, result) { /* called when done */ }
Is simply identical to that of node's background IO tasks.
--
Jorge.
Dean Landolt
Liam
Moving data between V8 instances is said to be possible; not sure
about closure data from a function parameter -- taking a script file
path might be more reasonable. Copying a result object to the main
instance should be straightforward?
Isaac Schlueter
out for functional side-effects.
var x = 100
function foo () { x = 10000 }
evalInBackground(foo, cb)
while (x === 100) {
console.log("ok")
}
throw new Error("SPOOKY!!")
Let's please not ruin node with parallel access to javascript objects.
> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
Isaac Schlueter
If you do this with a v8 isolate, it could be made safe. *However*,
afaik the last time this was investigated, the cost of creating a new
context was much too high to do on each request. In fact, that's the
bulk of creating a new node process.
Liam
future use after constructing it, and if they're memory-intensive you
set a timer to destruct them.
kowsik
to chrome extensions):
http://code.google.com/chrome/extensions/background_pages.html
This allows you to have an isolate process running some code and
there's a socket.io kinda of connect/notify/read/write interface
from/to the parent process.
K.
---
http://blitz.io
@pcapr