Comment by swannodette | Hacker News Reader

Comment by swannodette | Hacker News Reader

Parent Full thread

Thanks for the cleanup though I think it's easy to see it's not much of an improvement. It's also not really equivalent to the core.async / ES6 Generator version as the error must propagate through the promise pipeline instead of short circuiting as it would thrown as a real exception.

UPDATE: also see the comment below about stack traces. Since we don't have to wrap promises at every step of the pipeline you can recover much cleaner stack traces devoid of useless promise machinery.

Which leads us to the points from my other post about the problem with promises :) While this is fine for coarse grained asynchrony like this example - the allocation overheads for each step of the pipeline is unacceptable for say mouse events - forcing you to leverage another abstraction like Rx. So does JS need sugar for both promises & async streams? I should hope not, and core.async / ES6 Generators demonstrate that you don't need two different abstractions and you can get a lot more efficiency and less error indirection than promises can possibly offer. This is more or less what Erik Meijer's been saying about C# async/await for a long time now.

not much of an improvement

I just wanted our thumbs off the scale.

the error must propagate through the promise pipeline instead of short circuiting

Along a queue vs. up a stack, I'm not sure there's a fundamental efficiency difference, if that's what you're saying. Maybe. When it comes to distributed apps, OTOH, just one round trip saved by automatic promise pipelining http://erights.org/elib/distrib/pipeline.html can outweigh a lot of that sort of thing.

stack traces

That post says Q's stack traces are fine if you set a flag, and the same for generator-based libraries (optional because it costs extra). I expect ClojureScript does better because it can compile its own code, and the same would go for a promise-based language (or JS preprocessor).

So this is what you were getting at with "needs to propagate and handle errors" vs. ClojureScript -- you're saying the latter's more efficient?

does JS need sugar for both promises & async streams?

I'm not sure what you mean about async streams, but I wasn't seriously after more changes to JS syntax, just wishing (1) E had taken off and (2) new languages learn from it.

That post says Q's stack traces are fine if you set a flag, and that generator-based libraries also pay extra for full stack traces. I expect ClojureScript does better because it can compile its own code, and the same would go for a promise-based language (or JS preprocessor).

Q explicitly says that you don't want to enable stack traces for production, which seems like a fairly high cost to pay. Neither core.async nor ES6 generators need to do anything special to have clean traces - it's fundamental to how the system works.

I'm not sure what you mean about async streams, but I wasn't seriously after more changes to JS syntax, just wishing (1) E had taken off and (2) new languages learn from it.

Sorry for not being clear, my posts are all part of continuum. My point is hardly anyone uses promises for fine grained asynchrony because of the costs and debugging indirection. My point is that you can do both coarse/fine grained asynchrony at little cost and without obfuscating your errors during development or in production if you move beyond promises.

"the debugging story for generators is somewhat bad, especially because of the missing stack traces for thrown errors. Fortunately, there are solutions and workarounds, like those implemented by genny (obtrusive, reduces performance) and galaxy (unobtrusive, but requires native modules)."

From the post you brought up, http://spion.github.io/posts/analysis-generators-and-other-a... -- by the author of Genny. As I said, that's at least qualitatively the same as Q; quantitatively I haven't looked. At https://github.com/spion/genny there's the example line

    require('genny').longStackSupport = true

and "This results with CPU overhead of approximately 500% and memory overhead of approximately 40%. In the future, the overhead will probably be eliminated in node but not in browsers." The benchmark post says Catcher is worse.

The README for Q shows the same switch and says "This feature does come with somewhat-serious performance and memory overhead, however. If you're working with lots of promises, or trying to scale a server to many users, you should probably keep it off. But in development, go for it!"

I'm not a current user of any of these systems, but this is why I said the first-order cause of any performance difference appears to be that ClojureScript is not a library.

I can't really speak to other generators libraries nor their how good their debugging stories are based on how good or bad their designs are. core.async is just a library and not directly part of ClojureScript. I do know that we need nothing to support good traces and we do not take any performance hit of any kind for this "feature".

Not a Javascript library. The post advocates generators for Javascript programmers. For core.async to tell us the efficiency of JS code of this style, it'd need to expose a generator-based interface and compile to generator-based code like a human writes. If I understand right, it doesn't, and the JS libraries that do work this way are much less efficient when full stack traces are turned on. (If there are others, I hope someone will chime in.)

If you think those two libraries are just bad, I'll update somewhat in that direction.

No the post advocates generators plus a competent channel abstraction. It's going to be hard to compare generator libraries to core.async, far as I can tell none employ the comprehensive set of optimizations that we do for time and memory. Perhaps when someone ports our ideas to JavaScript a real comparison can be made.

Reply on news.ycombinator.com