Many of us become cynical about technologies that promise big breakthroughs in productivity, so we become overly careful in our choices, but this is a good ques

Many of us become cynical about technologies that promise big breakthroughs in productivity, so we become overly careful in our choices, but this is a good question for managers to always be asking: "Why would a large organisation with a mix of technologies and legacy systems want to muddy the waters with a completely new language?" If you want to make the conservative choice, and stick with what you already have, you should be able to articulate the reasons as clearly as you would if you were choosing a new technology. This certainly hints at the productivity power that I have discovered via Clojure: "Could Clojure be used to build the bespoke CMS? Is it too bleeding edge? Would his team get it?" When Colin Steele wrote about his experience as CTO at RoomKey, he also emphasized the incredible productivity benefits of using Clojure: "As of this writing, we’re on track to having 9 million uniques a month, from zero at the start of 2012. We did so with absolutely no fuss, no late nights, no hand wringing, and a laughably small amount of additional opex spend. " http://www.colinsteele.org/post/23103789647/against-the-grain-aws-clojure-startup http://www.colinsteele.org/post/23103789647/against-the-grai... And in this article Dave Elliman is describing an architecture very similar to what Colin Steele describes, and with similar gains in productivity: "After brainstorming some ideas we decided to put forward the idea of a Javascript based Single Page App (SPA) with a Clojure back end and a set of small Clojure based micro services sitting on top of MongoDB hosted in Rackspace." I haven't done the Javascript thing yet, but the Clojure/MongoDb/micro-services approach has worked out very well for me. (I'm using "micro-services" informally, as in "lots of small apps that work together").