It's my opinion that core.async shouldn't be used a concurrency mechanism, or as a new programming paradigm. Instead, it should be used as a communication method between sequential processes, and as a de-coupling method between modules. Let's go back to Rich's original post on the library:
"There comes a time in all good programs when components or subsystems must stop communicating directly with one another. This is often achieved via the introduction of queues between the producers of data and the consumers/processors of that data." Thus, this library should be uses as a communication system between subsystems, and not as a low level building block for the internals of a subsystem. Now, in some languages (e.g. CLJS) this library may be the only form of concurrency, but that's beyond the point. So your concerns with multi-consumer, and the limitations of <! and <!! I feel don't apply. the very fact that these functions are labeled as ! means they contain side-effects. And as such, I should strive to keep these functions at the boundaries of my code. Also, since I am using these items at the bouderies, they most likely will be transferring fewer, larger objects than many smaller objects. In this case, a few more CAS or lock calls doesn't matter much at all. In the same vein, having slower distributed puts/takes also doesn't concern me as much. The types of systems I envision using core.async with would be concerned more about fault-tolerance than performance. As Joe Armstrong said once about Erlang (and I paraphrase): performance isn't as important as fault-tolerance. What good is a program that runs fast, but doesn't get the job done? Almost all your proposed changes to core.async are driven by performance, performance I don't think we need. Just some thoughts :-) Timothy Baldridge On Mon, Jul 1, 2013 at 2:26 AM, pron <ron.press...@gmail.com> wrote: > Oh, yeah. It's 0.2-SNAPSHOT. > > > On Monday, July 1, 2013 11:24:40 AM UTC+3, puzzler wrote: >> >> I'd love to try this out, but when I follow the getting started >> directions and add [co.paralleluniverse/pulsar "0.1.1"] to my dependencies, >> I seem to get a completely different API and namespace layout than what is >> given in the documentation. Is there a "snapshot" release that contains >> the latest changes? >> > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
