Blog Post

Expert to Expert: Erik Meijer and Rich Hickey - Clojure and Datomic

Play Expert to Expert: Erik Meijer and Rich Hickey - Clojure and Datomic

The Discussion

  • User profile image

    Two of my favourite computer scientists together, awesome.  Datomic seems the simultaneous answer to so many reccuring problems, I hope I get to play with it someday. 

    It must really take a lot of 'hammock time' to think these things through and come up with such comprehensive solutions.  I wish I could find the time.

  • User profile image

    Very interesting ... along with the InfoQ talk on values etc... which Rich did recently, I'm really going to have to try Clojure ... hard to understand why I haven't yet.  Datomic sounds great as well and I'll have to do some research on that as well.  I am not sure if "continuations are the goto of functional programming", but now I'll have to think about that too.  Great E2E, thanks to all!

  • User profile image

    I think the continuations topic needs more treatment. GOTO Aarhus 2012 is a great place to have this conversation. Wink


  • User profile image

    GOTO = Call/CC

  • User profile image


    Agree. And as with goto's (jmp's), call/cc is useful in compilers (in a compiler generated code), but it is quite confusing for humans.

  • User profile image

    For arguments against continuations see here:

  • User profile image

    An very interesting question towards rich hickey would be:

    Clojure is actually used by quite a few start ups and they had positive experiences. But many of them do not use clojures concurrency primitives like STM.


    Why is that the case? In the early days clojure was labelled a LISP build with a focus on concurrency. But why those abstractions so rarely used? Why did Microsoft cancel STM?

    Are those reasons related?

  • User profile image
    Timothy Baldridge

    Microsoft canceled their STM project because they did it wrong. As Rich mentioned here, you can't get good STM performance by simply slapping STM onto a language that has mutability as the default. Clojure has very limited mutability, therefor STM fits well with its view of the world.

    That being said, the reason why you don't see many people use STM is that most people don't need it. With immutable data structures, and functional programming, many (if not all) of your issues with concurrency will just not be issues. On top of that STM is really only one of the 4 concurrency primitives Clojure offers.

    So the take away here is that Functional Programming + Immutable Data gets rid of most of your concurrency issues, if that doesn't do it, Atoms, Futures, Delays and Vars can help dramatically. If that doesn't do it, then look to Agents, and Refs (STM).

  • User profile image

    Rick Hickey needs to stop interrupting Erik the whole time and let him ask the whole question first...

  • User profile image

    very interesting and useful information I see here...

    thanks for the discussion...

  • User profile image
    Robert Levy

    Yes, refs/stm are needed pretty rarely, atoms a little more frequently. One of the nice things about Clojure code is that the stateful parts are a very small percentage of the code, easily identifiable and separable, and jump out at you, whereas is many languages mutable state permeates everything you do. To the poster who raised this question, I would say that in practice Clojure's concurrency/parallelism story provides major advantages over, say, Common Lisp: 1. immutability is fundamental to the language, so idiomatic code can take advantage of multiple threads without problems. 2. there is high-level parallelism functionality 3. there is high-level concurrency functionality. 4. you also have Java-level thread tools. The result of all this is that in Clojure, reasoning about change and coordination is much cleaner and simpler than in any other language I have used.

    It's worth pointing out that while I might not need STM that often, I have run into at least one situation where I would like to have STM at the multi-node level, and there is not a good story for that. There is a project that someone I know is working on to implement Clojure on the Erlang BEAM, but I don't think it has been released yet. Edward Liebke's Avout project may be a good solution, which I am hoping is moving along. I haven't tried it yet, but I definitely intend to.

Add Your 2 Cents