3 ms·

I'm really excited about this. While node-js is a great project, it still doesn't have the awesome instrumentation and tooling around it the JVM does. Additiona

• Zak 14y ago
  I'm not sure. Async-by-default doesn't seem like a great model for programming the server-side part of most things that are done over HTTP. Three use cases jump out at me: 1. Javascript doesn't have threads, but you want to write a usable HTTP server in it. 2. Threads are scary. 3. You want to make certain actions asynchronous over HTTP (i.e. client says "start", then server maybe says "done" later). Now consider Clojure: 1. Clojure has threads (on the JVM, at least) and one typically uses an existing Java web server when a web server is called for. Unlike Javascript when node.js came out, Clojure isn't lacking options for running or writing a web server. 2. Clojure makes a lot of threaded operations pretty non-scary. Its native data structures are all immutable and it has constructs for concurrent state. These are not any harder to work with than the async/callback model. I find it more natural, but I'm used to Clojure so that could be bias. 3. Async-when-desired is already easy in Clojure. Futures provide a very easy way to do stuff in a thread pool without blocking. Agents provide the same thing for state changes. It really is as easy as (future do-blocking-thing) and (send-off an-agent do-blocking-thing some-args). I can imagine why I might want this sort of thing in certain languages in addition to Javascript, but why would I want it in Clojure?