Communicating Sequential Processes

you can do everything in an FRP style if you like with core.async, it's flexible enough for that. But I think for less toy examples this is undesirable as you allude.

But core.async does some amazing stuff to actually analyze the code inside a "go" block and recompile it as a state machine so that a single thread can be "parked" and resumed. This allows core.async to work without multiple threads. It does this all at macro expansion time. This is the sort of thing that really demonstrates the power of Lisp. There's no way to do this without modifying the compiler in a language without a macro system.

So the output of a core.async program is going to be startlingly different than a normal ClojureScript program, because of the way it takes your "go" blocks apart and rewrites them when the macro is expanded.

Here's an example.

https://gist.github.com/jcromartie/5991947

I wonder if most of that is the runtime and libraries or the resulting JavaScript code is just that big.

* Intro: http://clojure-doc.org/

* Libs: http://www.clojure-toolbox.com/

* Examples: http://clojuredocs.org/quickref/Clojure%20Core

* Pedestal: https://github.com/pedestal/app-tutorial

Also a few books at different levels:

* http://www.clojurebook.com/

* https://leanpub.com/fp-oo

* (2nd ed early access available) http://joyofclojure.com/

* http://pragprog.com/book/shcloj2/programming-clojure

* http://www.manning.com/rathore2/

* http://www.packtpub.com/clojure-data-analysis-cookbook/book

But if you mean Clojure(Script) in general, I kind of agree. There are some beginner friendly tutorials; lately Andrew Brehaut's intro to the Clojure web stack[2] has been smooth going for me, despite being a bit dated. But you have to look around. In particular, I've found the small-scale mechanics of the language easy to pick up via Clojure Koans[3], 4clojure[4], and ClojureDocs[5]. What's missing the most IMHO is approachable introductions to the big-picture concepts. Especially the less generically lispy, more Clojure-specific parts, concerned with concurrency and state. (I hear the book Clojure Programming by Emerick et al. is good for that... have yet to read.)

I kind of understand Clojure not being easy or quick to learn, because powerful tools take time to master. But even with that said, it could be better. When I get confident with Clojure I hope to be part of a new wave of Clojurists who write really beginner-friendly tutorials :) I think it won't be the "gurus" who write them, but regular joes/janes like you and me for whom the initial difficulty of this stuff is still a fresh memory.

[1] https://github.com/clojure/core.async

[2] http://brehaut.net/blog/2011/ring_introduction

[3] https://github.com/functional-koans/clojure-koans

[4] http://4clojure.com/

[5] http://clojuredocs.org/

They may have fixed that recently, and this CSP implementation is really cool, so I may take a look back at the language.

That said, I agree with Rich's analysis in the "Wither actors?" section of the core.async announcement:

"They still couple the producer with the consumer. Yes, one can emulate or implement certain kinds of queues with actors (and, notably, people often do), but since any actor mechanism already incorporates a queue, it seems evident that queues are more primitive."

See: http://clojure.com/blog/2013/06/28/clojure-core-async-channe...

It should be noted that actors better fit in a distributed system, which is a step above and beyond concurrent systems.

Libraries like dart:html and dart:io express their asynchronous APIs in terms provided by dart:async so the model is unified across the stack (e.g. HTML events are delivered through streams out of the box).

Here is the first example and third examples from David's post rewritten to Dart

https://gist.github.com/mraleph/5991990

you can see that it is not that much different from ClojureScript versions.

   var loc = document.getElementById("location");

   window.addEventListener("mousemove", function(e) {
     loc.innerHTML = e.pageX + ", " + e.pageY;
   });

I suspect all the cost is from repainting large areas at the speed of mouse movement. But the mouse examples are for illustration - in production code you'll probably want to throttle (which would avoid piling up the repaints you observed on slower machines) as well as address the IE 10 edge case.

The security implications of channels are neat too, you can treat them as capabilities to specific parts of a process' API.

In Go you don't actually ask "what channel do I read from?". You are handed a channel (as a function argument or as a value from another channel) which you can then use to communicate. From the encapsulation point of view, pids and channels are very similar -- the code using the channel/pid doesn't have to know anything about the other end.

But the semantics of channels and message passing are very different: always synchronous vs asynchronous by default.

But really, you don't care if the user pushes the keyboard or moves the mouse first, you just want to handle each event as it happens in essentially a sequential manner.

If you had some code that communicated with channels and used only a single real thread without using any non-deterministic operations, then you'd actually have deterministic choice. So if you write a unit test with some mock services, you would always read from a particular service because the execution is truly deterministic. That might also mean that if two services respond at similar times (even non-deterministically) and you prefer one over another in at a choice, you could wind up unfairly ignoring one of the channels.

To combat this issue, Golang & core.async introduce randomness when multiplexing. If two channels are both ready, one is selected at random.