Pre-conj Interview: Lucas Cavalcanti and Edward Wible
Lucas Cavalcanti and Edward Wible's talk at the conj is about Datomic, a database that extends the concurrency semantics of Clojure into a distributed database. They have created generic solutions to common problems using Datomic.
Datomic is an append-only database. That means you never delete or modify existing records. It appears that the speakers have used this property to solve some tricky problems, including HTTP caching, audit trails, mobile sync, and authorization. A nice introduction is this talk by Rich Hickey.
Why it matters
Datomic is a relatively new database and people are still working out the best usage patterns for it. Its data model is quite flexible, so you often have to enforce your own structure. While that may be more work, the promise is that lots of other problems with traditional databases become non-issues. This talk promises to show us a glimpse of those practical benefits of Datomic.
About Lucas Cavalcanti
About Edward Wible
LispCast: How did you get into Clojure?
Lucas Cavalcanti: I've got into Clojure at Nubank, the company I currently work for, about a year ago. Nubank was already using Clojure, so I learnt it as we evolved the project. I was already familiar with Lisp syntax and knew functional programming very well, so the move to Clojure was not too hard.
LispCast: Can you explain a little about Nubank? And how do you use Datomic?
LC: Nubank is a tech company for financial services that just went public:
We use datomic as our primary database system, taking advantage of the free datomic transaction logs for auditing, and adding more data to improve auditing. We also use the datomic query language (based on datalog) to analyze data, often joining multiple databases, since we have a SOA with each service having its own database.
We also use some datomic capabilities to do database sync with mobile clients and cache management.
LispCast: Your talk's description mentions some "hidden superpowers of Datomic". You mention that the solutions to these problems are generic. Does that mean they can work for any problem?
LC: The solutions we'll provide will have some small assumptions to work, but these assumptions don't depend on the entities types we're saving, just something about the database structure. Thus we said the solutions are generic, and could work for any problem that matches these assumptions.
Also means that we can write just one function that will serve to implement one of that "superpowers" for all entities/endpoints of your system.
LispCast: So a lot of people are new to Clojure, and certainly to Datomic. Can you explain Datomic briefly for those of us who have never used it?
LC: If you know Git or any version control system, Datomic brings to a database many powers you have with Git: Think of each database transaction as a commit that generates another version of the database. So you can get the database value at any point in time, check the changes made by a specific transaction, all the history of a certain entity or even create "branches" of the database.
It works by collecting facts like "the entity 123 has the attribute :speaker/name with value"Lucas Cavalcanti"" and gives a query language based on datalog that, once you get the basic concepts, makes much more sense than any other query language I've worked with.
LispCast: So, is there anything else you think people should read up on to make the most of your talk?
LC: Read the docs: http://docs.datomic.com/index.html
LispCast: Where can people follow your adventures online? Where do you socialize?
LC: I guess twitter @lucascs
LispCast: Ok. Last question: If Clojure and Ruby got together, what would they name their baby?
"the (dis)functional duck typing" ;)
LispCast: Awesome! Thanks for a great interview. It was informative.