Alex,
I developed galaxy as a pure generators alternative to streamline, with the
hope of switching to a pure JS solution in the future.
But after some experiments with it I decided to stay with streamline,
simply because the syntax is more concise and plays better. For example,
here is how you chain 3 async calls with streamline:
function asyncFn4(_) { return asyncFn1(_).asyncFn2(_).asyncFn3(_); }
and the same thing with galaxy:
function* asyncFn4() { return (yield (yield (yield
asyncFn1()).asyncFn2()).asyncFn3()); }
More keystrokes, more difficult to parse visually, more risks of mistakes
(closing parenthesis in the wrong spot, forgetting a yield), etc.
And other generators libraries won't do any better because the problem
comes from yield's precedence. They'll likely even require more code, like
a wrapper around every async function definition.
Fibers, with the default futures library, preserves the nice chaining:
function asyncFn4() { return asyncFn1().wait().asyncFn2().wait().asyncFn3();
}
But this is less efficient than the corresponding streamline code (in
fibers mode) because every asyncFnN() call allocates a future (streamline
optimizes this case).
I'm probably a bit extreme in my quest for concise and composable syntax
but these things matter when you deal with a big code base.
Bruno
On Wednesday, January 8, 2014 9:13:42 AM UTC+1, Alex Kocharin wrote:
>
>
> I'm not looking for async stack trace. If I were, I'd probably pick up
> "trycatch" module instead.
>
> What I'm asking is that what is the point of writing javascript if you
> can't use it without compiling?
>
> If you can use a compiler, you can use typescript, iced coffee and a dozen
> languages better than javascript. If you don't want to use a compiler,
> fibers and generators will help without any streamline stuff. So what is
> the point...
>
> -----
>
> I'm using callbacks only. People who don't understand them just can't work
> with node, so I have no regrets about that. The biggest drawback so far was
> that debugger can't step in async calls, don't know what to do about it.
>
> If I wanted to write sync-like code, I'd probably turn to generators and
> "co" module. It looks nice, but I didn't actually manage to try it, since
> generators aren't on by default even in 0.11.x...
>
>
> // alex
>
> 08.01.2014, 11:37, "Bruno Jouhier" <[email protected] <javascript:>>:
>
> The async stack is reconstructed when you *catch* the exception (would be
> very inefficient otherwise). The normal pattern is to have at least one try
> catch in your high level HTTP dispatcher. You actually automatically get
> one if you use the companion streamline-streams or ez-streams companion
> libraries.
>
> Try the following:
>
> function a(_) { return b(_); }
> function b(_) { return c(_); }
> function c(_) { return d(_); }
>
> function d(_) {
> setTimeout(_, 1000);
> throw new Error("xx");
> }
>
> try { a(_); }
> catch (ex) { throw ex.stack; }
>
> Output:
>
> Error: xx
> <<< async stack >>>
> at d (/Users/bruno/dev/syracuse/junk/stack._js:7:18)
> at c (/Users/bruno/dev/syracuse/junk/stack._js:3:23)
> at b (/Users/bruno/dev/syracuse/junk/stack._js:2:23)
> at a (/Users/bruno/dev/syracuse/junk/stack._js:1:23)
> at main (/Users/bruno/dev/syracuse/junk/stack._js:10:6)
> <<< raw stack >>>
> at __$d (/Users/bruno/dev/syracuse/junk/stack._js:7:18)
> at ___ [as _onTimeout]
> (/Users/bruno/dev/syracuse/node_modules/streamline/lib/callbacks/runtime.js:100:13)
> at Timer.listOnTimeout (timers.js:124:15)
>
>
>
>
> On Wednesday, January 8, 2014 3:45:25 AM UTC+1, Alex Kocharin wrote:
>
>
> I run "node_ test._js", then "node debug -p `pidof node`" (node_ doesn't
> have debug option), and that's the code I see:
>
> ```
> debug> c
> break in test._js:4
> 2 debugger ;
> 3 return setTimeout(__cb(_, __frame, 2, 0, function __$main() {
> 4 debugger ;
> 5 console.log("... world"); _(); }, true), 10000);
> });}).call(this, __trap);
> 6 });
> ```
>
> And this is an example stack trace:
>
> ```
> Error: xx
> at __$main (/tmp/node_modules/zz/test._js:5:16)
> at ___ [as _onTimeout]
> (/tmp/node_modules/streamline/lib/callbacks/runtime.js:100:13)
> at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
> ```
>
> Needless to say, I don't remember writing any of these underscore methods.
> And as I said earlier, I avoid compilers for this exact reason. Personally,
> I'd much rather stick to the callbacks and not trade writing time for
> debugging time. But if you're using a compiler anyway, I'd rather look for
> await/defer features of IcedCoffeeScript because it comes with much more
> obvious syntax.
>
> PS: yes I know, it's possible to use fibers or generators or whatever with
> streamline. But I can use them without streamline just as well, and it'd be
> much easier.
>
>
> 08.01.2014, 05:55, "Seth Pollack" <[email protected]>:
>
> Hi Alex, please see my comment below about not trolling for more "my
> control flow is better than your control flow" debates ;-)
>
> All joking aside, there are many innovative approaches out there -- an
> embarrassment of riches. For folks who are into coffee script, streamline
> has full support for that as well.
>
> Also, i may not have been clear enough about the debugging experience
> under streamline. The code in the editor and debugger are the same.
>
> Seth
>
>
> On Tuesday, January 7, 2014 4:49:42 PM UTC-8, Alex Kocharin wrote:
>
>
> I wonder how having different code in the editor and in the debugger helps
> productivity.
>
> Oh come on... If you're using a compiler anyway, why not move to iced
> coffee or something? I'm avoiding it recently, but it's still better than
> streamline.
>
>
> 07.01.2014, 22:53, "Seth Pollack" <[email protected]>:
>
> I've written up a blog post here http://bit.ly/KtMIYS that explains why
> we've chosen Node.js plus Streamline as our platform for our product (
> www.rivaliq.com).
>
> We are all Node fans in this forum, but i'm guessing that fewer folks have
> given Streamline (https://github.com/Sage/streamlinejs) a spin. We have
> found significant developer productivity (and happiness!) benefits by
> making the switch to using it. I'm not saying that here to troll for more
> "my control flow is better than your control flow" debates, but rather to
> share our experiences in order to hopefully help others. Please give it a
> read, and I welcome your comments on the blog.
>
> Seth
>
>
--
--
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
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
