# Cultural differences between Clojure and NodeJS

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

Right now I have to work with NodeJS, because I have a client who uses NodeJS. I am getting used to the asynchronous style of NodeJS. I notice a subtle cultural difference between Clojure and NodeJS. Most of the tutorials for NodeJS assume the person reading is a beginner, someone who may not understand big complex words like “asynchronous”. In the world of Clojure, there is the assumption that the person reading the article has some experience. With Clojure, there is more focus on theory, and more focus on the difficult concurrency cases that one can face while programming, problems that Clojure was designed to solve. With NodeJS, there is more the sense that the asynchronous style was a historical accident, arising from the precedent established years ago by Ajax. NodeJS tutorials have the tone “This is the way things are, this is the way you need to adapt to circumstances.” Clojure is more “This is the way things used to be, thankfully we invented Clojure so those problems are solved now.”

To be clear: some of the tutorials about NodeJS are great. Check out We Have A Problem With Promises. It looks at 4 different cases:

doSomething().then(function () {
return doSomethingElse();
});

doSomething().then(function () {
doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);


But consider the point he makes at the opening:

Fellow JavaScripters, it’s time to admit it: we have a problem with promises.

No, not with promises themselves. Promises, as defined by the A+ spec, are awesome.

The big problem, which has revealed itself to me over the course of the past year, as I’ve watched numerous programmers struggle with the PouchDB API and other promise-heavy APIs, is this:

Many of us are using promises without really understanding them.

That last sentence sums up the world of NodeJS. Developers are expected to copy-and-paste code without really understanding it. One doesn’t run into this attitude in the world of Clojure.

Consider how Tomasz Nurkiewicz wrote about Promises and Futures in Clojure:

Clojure, being designed for concurrency is a natural fit for our Back to the Future series. Moreover futures are supported out-of-the-box in Clojure. Last but not least, Clojure is the first language/library that draws a clear distinction between futures and promises. They are so similar that most platforms either support only futures or combine them. Clojure is very explicit here, which is good.

…Promise is a thread-safe object that encapsulates immutable value. This value might not be available yet and can be delivered exactly once, from any thread, later. If other thread tries to dereference a promise before it’s delivered, it’ll block calling thread. If promise is already resolved (delivered), no blocking occurs at all. Promise can only be delivered once and can never change its value once set:

(def answer (promise))