Jon: Why did you choose Clojure to power the business?

Dimitrios: The core of our business is the simulation of the global box office. It’s all about processing complex and constantly changing data as fast as possible. When we first started our simulations could take five hours. It’s now about a minute. We have found functional programming a great fit for our team, especially those with a scientific background.

Team: Clojure might seem an unusual choice for performance-intensive simulation work; but it’s working out well. It’s a great fit for the problem, performant enough for our needs and it’s extremely expressive and readable, allowing us to iterate quickly on complex simulation algorithms.

Jon: How do you get it so fast?

Dimitrios: Through lots of optimisation and the ability to easily deploy using Amazon AWS.

Team: We’ve had to think outside the box, just throwing more machines at the problem might help, but then we’d have more problems with managing a distributed processing infrastructure e.g. a Hadoop cluster. To say more would be to enter a larger discussion of simulation and stochastic models that we probably don’t have time for here!

Jon: How did you go about adopting Clojure?

Dimitrios: Initially we started with Racket. Racket was nice and functional, but it was lacking support in certain areas. The developers came up with the idea to move to Clojure.

Team: Because the webapp for a previous iteration of our product was built in Racket, we were no strangers to parentheses. We tried Clojure for certain parts of the system at first, and it worked out very well. It has a larger ecosystem than Racket, so we’ve ended up adopting it across our stack. The usual reason of 'it works well with our existing Java systems' wasn’t a factor for us.

Dimitrios: As we’ve grown as a business we’re now using Clojure for almost everything - plain Clojure for back-end services and ClojureScript on the front-end.

Team: While we’ve gotten a lot from Clojure, we’re not obsessive, and recognise that it isn’t the best tool for every job. We’ve been experimenting with Serverless recently and this is one area where a lighter-weight solution may work better.

Jon: What is your team size?

Dimitrios: Our development team is currently five people and will be six shortly. We’re a fully remote team, scattered across the UK.

Team: You might think that remote would be an issue, but we’ve developed a way of collaboratively working together using appear.in video conferencing, Slack and tmux - we pair-program remotely much of the time and although we’re close to XP we’d prefer to refer to our team as agile with a small 'a'.