If you want sync code that badly, why don't you use EventMachine instead
with fibers? You write sync language in Ruby, so it's natural to write
"sync-style" code in EventMachine also.
JavaScript is asynchronous, Node.js is asynchronous, everything feels
natural (and fibers don't).
> Please stop with "the performance hit" bs, thanks.
Just because you make a wrong benchmark doesn't mean anything.
On Thursday, April 12, 2012 3:32:34 PM UTC+3, Jorge wrote:
>
> On Apr 12, 2012, at 1:24 AM, Marco Rogers wrote:
>
> > I would've hoped you had more fortitude against the attacks on
> streamline then to start throwing around hastily designed benchmarks to
> prove your point. It sucks that the "sync-looking" advocates have to deal
> with the level of aggression they do here. I've expressed that to some
> people myself, even though I don't advocate these solutions either. But
> this is almost certainly not the way to win hearts and minds.
> >
> > When you create an abstraction layer, it's almost always slower. That's
> just something you're not going to get away from.
>
>
> That's wrong, StreamLined code does not have to be any slower because it
> simply writes the JS for you:
>
>
> > On Apr 10, 2012, at 10:35 PM, Bruno Jouhier wrote:
> >
> >> Streamline translates its special syntax to vanilla JS with callbacks.
> So, if you implement a function like
> >>
> >> function foo(x, y, _) { ... }
> >>
> >> Normal JS modules (not written with streamline) will be able to call it
> as:
> >>
> >> foo(x, y, function(err, result) { ... });
> >>
> >> Streamline is just a tool that helps you write your code. This tool
> produces vanilla JS that follows the standard node callback conventions. So
> you can publish it to NPM, you won't be forcing anyone else to use
> streamline. (...)
>
> > On Apr 10, 2012, at 11:01 PM, Axel Kittenberger wrote:
> >>
> >> Its not like Bruno is doing an evil plot here. Since as long your
> >> benchmark does not compare apple with oranges, it will always be just
> >> as fast as vanilla written code, since in the end, it translates to
> >> vanilla code.
>
>
> > Even if the benchmark wasn't flawed, simply because you can contrive a
> scenario where it wins doesn't make up for the fact that it stills loses
> most of the time.
>
> Again, wrong. It simply writes for you the ~ exact vanilla JS code you
> would have had to write yourself.
>
> > Then on top of that, it becomes clear that streamline does some trickery
> in transforming to js that injects more cleverness. Hence the fact that
> your example doesn't require an explicit nextTick. So then you leave people
> with the feeling that if it is ever faster, it's because streamline has
> done some tricky optimizations in the background.
>
> Totally safe optimizations, as any other good compiler would do. Is that a
> bad thing too, in your opinion?
>
> > In my opinion, people who are interested in streamline and fibers will
> already be prepared to take the performance hit in exchange for ease of use.
>
> Please stop with "the performance hit" bs, thanks.
>
> > A better argument would be that you're committed to making that hit as
> small as possible. And assuring people that a 2x difference won't often
> make a huge difference in practice.
>
> You're making up numbers.
>
> > I agree with that, and I think it's easily defensible.
>
> Only if it were true, which it isn't.
>
> > This benchmark is not.
>
> FYI the benchmark is a reply to this:
>
> > On Apr 10, 2012, at 4:55 PM, Joe Ferner wrote:
> >> On Apr 10, 10:12 am, Bruno Jouhier <[email protected]> wrote:
> >>> @joeferner
> >>>
> >>> (...) From my experience there are code patterns where fibers beats
> callbacks 10 to 1.
> >>
> >> beats 10 to 1 how? in code readability?
>
> --
> Jorge.
>
--
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
