Managing a transition like this is far from trivial for a company facing a variety of immediate demands and constraints, even if it promises to pay dividends in the long run.

Mobile and desktop are not something I focus on heavily either. It's nice to know that if that were to change, Clojure at least offers some decent options.

On one hand, I like using something that makes me think and also gets the job done (clojure). On the other hand, it feels good to be a member of a huge community (JS, ruby, python developers) and know what many others know.

I had not thought about your points about selling a software in a "less standard" lang. I think you're right.

1) clojure is functional - Someone with math background will have no difficulty to think of computation as combinations of functions. And with map/filter/reduce there is a lot of fun stuff you can do. Also, there is no need to burden a learning programmer with pointers, and clojure doesn't bother you with that, it's all "by-value".

2) clojure has great data types - After all, it's all about data. Clojure shines with elegant notation and powerful processing of data structures, which IMHO is very easy and straightforward to grasp.

3) clojure has a REPL - Learning by doing helps a great deal to get a feeling for programming, because of the direct feedback.

4) http://try-clojure.org/ - No need to install anything - get started instantly, do the further steps later. And there's a tutorial as well (never tried it).

For many, Clojure may be a better choice as you suggest: perhaps especially for web projects. But I think for some groups and applications, CL remains a better choice.

Does my comment came across like that because I point out benefits from using Clojure, or what makes you say that?

The “do-it-yourself” mentality that is at the core of Clojure dev culture results in a less rich library ecosystem. Not only you often end up writing custom code for a generic feature, the rest of your team cannot reuse their past experience but has to learn your custom code and maintain it.

People in the Clojure community have been trying to build such frameworks. But every one of them seems to stay in a weird niche where they’re not comprehensive and _easy_ enough to draw in people who’d use something like Django et al.

I think one of the reasons is that they’re all trying to cater to the crowd that wouldn’t use such a framework anyway.

Secondly it’s already very quick to create a web app in Clojure. If you use a set of libraries you pay with some initial setup/thinking/choosing cost. The benefit is then to have a program that is more malleable and composable, which is kind of the point for many who choose Clojure in tge first place.

There’s really a mismatch of expectations and philosophy I feel.

I like to write dumb, obvious code. Most Clojure code is about taking your data, representing it a sequence of maps, and transforming them into different sequences of maps. The maps are open (easy to change over time), immutable (impossible to encounter data races, weird equality semantics, or concurrency issues), dynamic (no pre-definition or ceremony required), concise (thanks to a literal representation that does not even require commas between elements), and have a generic access api (no custom functions/accessors/etc).

Because I use the exact same transformation functions on EVERY PROBLEM, there is an enormous amount of reuse of generic operations both within and across Clojure code (even Clojure code that manipulates Clojure code, which is after all, just data).

Because the center of our code is open data, coupled with generic functions open to later extension (multimethods, protocols), Clojure is notably good at handling information systems that evolve over time in requirements (a feature of essentially all of them).

The core constructs are not hard, certainly they are easier to learn and use than complicated things like mutable classes and locking. The unlearning from other languages is often bigger than the learning. Nubank for example is certainly not hiring 100s of Clojure developers - in most cases they are hiring good people and teaching them Clojure. There are other successful companies doing the same.

Large Clojure programs can be hard to reason about because large programs are hard to reason about. One benefit of Clojure programs is that they are often 100x smaller than the equivalent program in a popular OO language. They are also trivial to interact with live in your REPL so that you can inspect the data flowing through them. I will happily take live data and interactive function execution over 1000 classes with custom methods. Both require time to learn but I'm much happier changing the smaller, simpler one.

The idea that "Clojure requires wise developers" is completely backwards. Enormous modern class/annotation based OO programs are the ones that require the smartest developers because that's what it takes to understand them. Clojure is accessible to all.

If you are a budget constrained individual living in a third world country with nothing to invest but your intellect and time, Clojure is a very good language. It lets you to - 1. Create relatively large systems without pulling your hair out. 2. Juggle between different projects with relative ease. Great for managing a projects in maintenance mode. Great for contractors with long term support contracts. 3. Realize your vision of a complete product with relatively low time and money.

Overall, it's a way of doing effective programming. It's probably not a good way of making money if the focus is to siphon investor money with a large team and millions of lines to show for.