Byzantine Reality

Searching for Byzantine failures in the world around us

My Argument for Clojure

Clojure has a lot of buzz around it as of late, and I think it’s important to understand why. Thus, my argument for Clojure is as follows:

We need a programming language with three notable features:

  • Intelligent: Clojure provides a sophisticated software transactional memory (STM) system, and it’s runtime provides ahead-of-time compilation, two bleeding edge technologies.
  • Simple: Clojure’s syntax is based on Lisp and is completely interoperable with Java (e.g., Clojure can call Java and Java can call Clojure)
  • Secure: Rather than rolling out their own runtime system, they use the proven Java Virtual Machine. The JVM certainly isn’t perfect from a security standpoint, but it’s certainly safer than rolling out your own solution.

Protocols that the web rely on such as DNS and HTTP are only implemented with such efficiency because they are essentially stateless. By default, Clojure forces statelessness upon the user’s program, although mechanisms are provided to perform side-effects (e.g., agents). Furthermore, transactions must be side-effect free (although I don’t see any obvious way that Clojure enforces this like Haskell does).

A possible downside of Clojure is the complexity of STM, and we must assess whether this complexity is sufficiently greater than using locking to negate the benefits involved. I also seek to evaluate the writability of the language, as it does not immediately appear to be as writable as Ruby. How much they differ is a pressing concern since we aim to pick a language that is relatively siple to grasp as far as readability, writability, and maintainability are concerned. A slight loss in any of these is certainly warranted if the claim that Clojure “solves” the concurrency problem is valid.

That being said, I’m pretty excited about Clojure. Check out the official rationale for Clojure and more interestingly, their argument about Clojure and state.