I’ve been quite vocal about my opinions on development environments and automating the creation of them on this blog and elsewhere. Boiling it down to the two points I feel most strongly about:

1. Always develop in a production-like environment
2. Automate the creation of these environments

It’s been a couple of months since I’ve stopped using Cider for Clojure development in Emacs. I find a simple ‘inferior lisp’ setup faster and more reliable. For a good summary of why one would consider not using Cider, see Luke VanderHart’s excellent summary.

Recently, I gave a talk at the Clojure eXchange 2014 titled ‘Developing Clojure in the Cloud’. I described a way of creating and using (Clojure) development environments inside VMs. I’ve been developing like this for the last year (spanning 2 projects).

Tradition demands that I write down some subjective thoughts on how my old friend F# is doing. So here we go again (for the 4th year running).

All I can really say is this: wow, what a year.

I’ve been hacking Clojure for many years now, and I’ve been happy to rekindle my love for Emacs. The Clojure/Emacs toolchain has come a long way during this time: swank-clojure, nREPL, nrepl.el, and now Cider. The feature list is ever-growing, and every time you look, there are some new awesome shortcuts that will ‘make your day’.

The Clojure Cookbook is part of the O’Reilly cookbook series. I’d describe this format as a ‘curated wiki in print’. The wiki analogy is especially true for this volume since its contents were contributed by some 60 different developers. It’s packed with small, bite-sized recipes for solving common problems in Clojure. This is useful for developers across the entire spectrum from beginner to expert.

The content is organized into 11 chapters, each containing a number of recipes. The chapter layout is clear and serves its purpose when looking for content. The book covers a lot of ground, from working with primitives and basic data structures to dealing with databases, writing web apps, and running Hadoop jobs. Each recipe comes with code and/or REPL examples, so it’s very easy and enlightening to ‘play along’. In contrast to other books with code snippets, the authors have made all recipes self-contained (no other projects/files need to be created and run for the examples to work), which makes it very easy to dive in at any point in the book.

All Clojure developers swear by their REPL; it’s one of the most powerful tools in our arsenal. Coming from traditional edit/compile/launch languages, it is also a great productivity boost. The Clojure community takes non-AOT (ahead of time compilation) to the extreme. By default, we ship Clojure source code in our development and production jars and thus leave compilation to the very last minute (when the program launches). This gives us lots of power and flexibility; if you’ve ever navigated into a library in Emacs and fixed a bug, re-evaled the form and carried on working, you know what I’m talking about.

You can’t do anything even remotely blocking inside go-blocks. This is because all the core.async go blocks share a single thread pool, with a very limited number of threads (go blocks are supposed to be CPU bound). So if you have hundreds/thousands of go blocks running concurrently, just having a few (a handful really) block – all go blocks will stop! For a more in-depth explanation see this previous post.

One particularly annoying difference between core.async and Go is that you can’t wrap function calls with the go macro. This is due to implementation details of core.async, which can only see the body ‘inside’ the macro and not the functions it may call. This is obviously not a problem if the called function doesn’t interact with any channels, but if it does, then you might be in trouble. I’ve touched on this subject in a previous post.