As a co-author of the reactive manifesto I'd like to point out that "reactive" can be considered a superset of "async". Good reactive applications are event driven and non-blocking. They are also responsive, resilient, and scalable which async can help with but does not prescribe.
What are the "bad connotations"? I'm curious to understand other perspectives on this. On Monday, 17 March 2014 20:22:31 UTC, Andy C wrote: > > From what I understand, a single core can easily saturate a memory bus. At > the same time L2 and L3 caches are so small as compared to GB of memory > systems yet growing them does not necessarily help either due to larger > latencies. It all limits the number of practical applications which could > really take a full advantage of multi core architectures. > > Having said that I just wonder if a typical async Clojure application can > even be efficiently performed on a multi-core architecture. In any case, > immutability helps writing reliable multi "execution context" software > there is no need for explicit synchronization in most of cases. > > BTW, I absolutely love the "async" name itself chosen by Clojure authors > as opposed to "reactive" as in http://www.reactivemanifesto.org. Reactive > comes with bad connotations and really does not reflect the intentions > well. > > Best, > Andy > > -- 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/d/optout.
