> Both of those languages have great tools (rails, for example)
I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management.
Perhaps one might admire it for making a bold claim about configuration vs. convention, but a valid criticism of Rails is that they went so far along the convention line in rebellion of bad tools like Spring that now they get accused of excessive magic.
> But I can't see Clojure pushing either Ruby or Python out of the water any time soon.
Like I said, success is fashion. But then, people said this to me about Git Vs. SVN after I gave a tech talk to a bunch of ruby folks about how git would take over the world. Two people left that talk and went on to found Github, so... "High Fashion."
Clojure has all the power of Ruby's dynamism, but with a better solution to the expression problem (protocols are namespace contained, allowing for monkey-patching that doesn't taint the world). It has access to a lot of fantastic high-performance libraries. It can safely deal with high degrees of parallelism with a degree of ease few environments can claim. It has a minimalist syntax which can compete with even the most terse and convention-driven ruby syntax (i.e., Compojure vs. Sinatra).
Similar complaints can be leveled at Python with less of a performance angle and more of a power angle; Clojure gives you access to many of those features that the python community feels are "too awkward" to use in the OO world, but are entirely natural in the Lisp world.
So yeah, every time someone writes a server in Node.js I think to myself, "You could have done it in Clojure and had just as much dynamism during development, just as easy a deployment story, and also perform easily an order magnitude faster under load, and you don't have to run like a scared child from parallelism."
> I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management.
When evaluating what tool to use for a project, there are many things to take into account other than the technical superiority of the tools. Relevance Inc, one of the strongest backer of Clojure, still make use of Rails for client projects. Rails' huge web dev ecosystem really made many common tasks as simple as importing a gem here and there and making a few method calls. It all comes down to the right tool for the right job. I'm interested in your take on how Rails' "share-nothing approach", awkward architectures etc.
> Clojure has all the power of Ruby's dynamism
Yes, and then some. Without repeating what you have already said, I would add efficient persistent data structure to the Clojure's list of awesome tricks. Doing functional programming in ruby and python, for example, will force you to trade value immutability with efficiency -- a penalty that one does not have to pay in Clojure.
Clojure is definitely gathering a lot of following. Like many others, I have picked it up, played with it, and never looked back.
But going back to what was said before. Yes, Clojure is awesome. No, Clojure is not obsoleting Ruby or Python any more than those obsoleted PHP, at least not now.
I enjoyed programming in Clojure, but chose Python once more for a new project because w/ Clojure I don't know which projects are doing well. (Templating? Web app library? Postgresql?).
Wrt Python I know I'll do fine w/ Django, Flask, Jinja2, Psycopg2, Tornado...
You have successfully gotten me to commit myself to looking into Clojure. Any good resources on learning/setting up, or should I go by the seat of my pants?
I find Clojure Programming (http://www.clojurebook.com/) to be an easy and practical introduction of the language. It often compare and contrast the Clojure way of doing things vs scripting languages like Ruby. After that, Joy of Clojure (http://joyofclojure.com/) dives deep into the whys of the language. Even though it was written against Clojure 1.2, it covers advanced topics like continuation passing style that were left out of Clojure Programming.
I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management.
Perhaps one might admire it for making a bold claim about configuration vs. convention, but a valid criticism of Rails is that they went so far along the convention line in rebellion of bad tools like Spring that now they get accused of excessive magic.
> But I can't see Clojure pushing either Ruby or Python out of the water any time soon.
Like I said, success is fashion. But then, people said this to me about Git Vs. SVN after I gave a tech talk to a bunch of ruby folks about how git would take over the world. Two people left that talk and went on to found Github, so... "High Fashion."
Clojure has all the power of Ruby's dynamism, but with a better solution to the expression problem (protocols are namespace contained, allowing for monkey-patching that doesn't taint the world). It has access to a lot of fantastic high-performance libraries. It can safely deal with high degrees of parallelism with a degree of ease few environments can claim. It has a minimalist syntax which can compete with even the most terse and convention-driven ruby syntax (i.e., Compojure vs. Sinatra).
Similar complaints can be leveled at Python with less of a performance angle and more of a power angle; Clojure gives you access to many of those features that the python community feels are "too awkward" to use in the OO world, but are entirely natural in the Lisp world.
So yeah, every time someone writes a server in Node.js I think to myself, "You could have done it in Clojure and had just as much dynamism during development, just as easy a deployment story, and also perform easily an order magnitude faster under load, and you don't have to run like a scared child from parallelism."