Pre-West Interview: Ron Toland

Talk: Staying SAFE: a Foundation for Clojure Applications

Ron Toland's talk at Clojure/West is about large-scale Clojure systems.


I detect a theme in the Clojure/West talks. Clojure has been around almost eight years now. We're starting to see companies that have mature Clojure codebases. And they are wanting to talk about them.

This talk seems to go with that theme. Sonian has been using Clojure for six years and they want to share how they build their services. As background, I have to again suggest Reflections on a real-world Clojure application. Unfortunately, there isn't much out there right now. I am very much looking forward to these talks being published.

About Ron Toland

Homepage - Twitter


Ron Toland was gracious enough to agree to an interview. He is giving a talk at Clojure/West about building large systems in Clojure. The background to his talk is available, if you like.

Interview with Ron Toland How did you get into Clojure?

Ron Toland: I got into Clojure through Scheme.

There was a senior engineer at my first programming gig that kept raving about Scheme and the book Structure and Interpretation of Computer Programs (SICP). After several months of listening to him, I finally bought a copy and read through it. I was blown away by how very simple building blocks could be used to do very complicated things.

In particular, it struck me that the authors covered the map-reduce paradigm in only chapter 2 of their book; given that at the time I was reading (2009-2010) hadoop was all the rage, and the book was written in the 1980s, I started wondering "what else does lisp have that we're only now re-discovering"?

After doing some digging into currently used Lisps, I came across Clojure. Since I was already familiar with Java, it seemed like a perfectly pragmatic Lisp to me: stealing all the thunder of the JVM, but stacking on top of that the beauty and power of Lisp. It's been my favorite programming language ever since. You've been using Clojure at Sonian for 6 years. When you started, Clojure was very new. What made you choose Clojure at such an early point?

RT: I wasn't at Sonian when the decision was made to use Clojure, but I do know the background.

Basically the first version of everything was written in Ruby, which worked fine until they needed to scale things out and up to handle a larger volume of email.

They knew they needed to rebuild it in a different language, so they looked at several contenders: JRuby, Java, Clojure, Scala, even Erlang. They held a big meeting of all the devs to decide which one to go with, and it came down to Clojure or Erlang. Clojure, because several of the devs were familiar with Common Lisp or Scheme and liked it, and Erlang, because the architecture they were designing around is actually pretty close to the way you'd build it in Erlang.

Clojure won because of the JVM. It turns out that email is terrible, with multiple standards used by different programs at different times over the decades, and so processing it into something searchable is a nightmare. Java has a lot of libraries for processing email that have been built up over the years to handle most of email's craziness. Erlang doesn't (or at least didn't at the time).

Since with Clojure they could use those Java libraries directly, while if they used Erlang they'd have to write their own, they went with Clojure. What is the SAFE codebase?

RT: SAFE is the primary application we use at Sonian for email ingestion. archiving, and indexing into Elasticsearch. What is the most important thing to get right early when writing a large Clojure system?

RT: I wasn't part of the team that originally wrote SAFE, so I can't speak much about what to get right at the start of building a large system in Clojure.

I can say that a lot of large systems don't start out that way; they begin as smaller applications that grow over time, as needs arise. The trick is to keep it from becoming a mess by constantly revisiting how it's put together and looking for better --- usually more abstract, but not always --- ways to express what it needs to do. What do you wish could be better in Clojure for large systems?

RT: I'm not sure there's anything in the language itself I wish was better about Clojure for building large systems. Getting logging configured correctly always seems to be a pain; it'd be nice to have a single logging library that could hide the ugliness of the underlying java libs from us. Is there anything else you'd think would be useful for people to know before they watch your talk?

RT: I think that pretty much covers it. I'd encourage people to attend the Trapper Keeper talk today, so they can compare the two approaches. Where can people follow you online?

RT: I blog at, and my twitter handle is @mindbat. If Clojure were a food, what food would it be?

RT: If Clojure were a food, it'd be coffee. Once you use it long enough you can take it for granted, but when you don't have it you can't seem to get anything done.