Re:Asynchronous Error Handling
by swannodette on Saturday August 31, 2013 @05:35PM
(#6308207)
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".
Re:Asynchronous Error Handling
by abecedarius on Saturday August 31, 2013 @07:08PM
(#6308463)
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.
Re:Asynchronous Error Handling
by swannodette_ on Saturday August 31, 2013 @07:43PM
(#6308539)
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.
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
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.