Comments on: Clojure: A Lisp Worth Talking About

By: Digital Digressions by Stuart Sierra » Blog Archive » More Clojure Love

Tue, 10 Jun 2008 20:45:22 +0000

[...] I didn’t make it clear in my first post about Clojure, I like this language. Here’s some more reasons [...]

By: Mercurial » Blog Archive » Clojure, a new Lisp is born

Mercurial » Blog Archive » Clojure, a new Lisp is born — Tue, 11 Dec 2007 17:09:34 +0000

[...] A new Lisp WTA. A link to the talk presenting Clojure. The website for Clojure. [...]

By: Rich Hickey

Rich Hickey — Thu, 06 Dec 2007 14:59:04 +0000

md, it’s a matter of right tool for the job. STM is great for some problems. Just because you have N cores doesn’t mean you have N processes contending for the exact same data. Many multithreaded apps have occasional interaction with small, but potentially overlapping sets of shared data. STM makes doing the right thing easy and scalable. Doing a real transaction, i.e. read x from here, modify it, put it there without it being in both places, or no place, or changed by anything else, is very cumbersome (impossible?) in a pure asynchronous message passing system (cf Mnesia, which does plenty of locking: http://www.erlang.org/doc/apps/mnesia/Mnesia_chap4.html#4). Of course there are also merits to asynchronous concurrency systems and Clojure has that too, in its Agents (http://clojure.sourceforge.net/reference/agents.html), a slightly different take on actors (Erlang’s model).

Erlang is very cool and Clojure is not designed to compete with it, but saying there is only one way, or presuming that a specific method will not work for an unspecified class of problems, is unproductive. Sorry you don’t like the JVM, but I find it pretty impressive, even if not suitable for all problems.

By: Sp3w

Sp3w — Tue, 04 Dec 2007 16:34:55 +0000

[...] On Clojure I haven’t been this excited about Lisp since Peter Seibel came to talk about Practical Common Lisp. [...]

By: Mike McNally

Mike McNally — Mon, 03 Dec 2007 23:35:13 +0000

Well md, the thing is that there are projects out there that are doomed to be Java projects. In such an environment, the availability of a sophisticated higher-level language like Clojure is a really nice thing. I suspect that the large Java OLTP application I’m most familiar with isn’t much different than others like it, and I can imagine a good deal of the Java code at certain layers being replaced by Clojure.

I don’t mean to suggest that Clojure should not be a potential choice as a primary implementation language. I really don’t feel I can offer a respectable opinion on that. All I can say is that from what I’ve seen, Clojure has a lot going for it compared to Javascript (Rhino), Groovy, or JRuby.

By: md

md — Mon, 03 Dec 2007 22:59:45 +0000

I always welcome new Lisps, and Clojure seems to have some nice properties, however there are couple showstoppers:
- while you may think java vm is a great think, it’s not. when you do some java threaded server software, you will find out that java VM is quite unpredictable, sometimes giving delays for dozens of milliseconds in the executing context of the thread for no reason
- Clojure’s concurrency model ala ‘transactions’ is broken. Might work fine on 2-4 cores CPU. When we will have CPUs having 8 and more cores, centralized approach to concurrency like locks, transactions, ‘lockless’ data structures (where your lock is ‘lock’ instruction) will break. The only right way to model concurrency is the way Erlang does it. And forget about that using crappy java vm

By: unClog » Clojure, Clojure, we want Clojure

unClog » Clojure, Clojure, we want Clojure — Sun, 02 Dec 2007 20:16:58 +0000

[...] Sierra heard the talk in person and has a great overview on his [...]