I haven’t had a chance to spend much time with Clojure, but I have spent time learning both Groovy and Scala which are similar. Both have a steep learning curve (which I can’t say I’m entirely over), but I have noticed that, in the nearly 3 decades I’ve been programming, I’ve never seen anything with a steep learning curve really catch on. The things that catch on like wildfire are things like Java, JavaScript, Cobol, VB, C#: things that take a moment to learn but a lifetime to master. The reason seems pretty obvious - you can produce results and feel productive (and demonstrate productivity) quickly even if you’re less productive in the long run. Short term results matter more than long term efficiency.
The languages that catch on are the ones tied to the most popular platforms.
Objective C and Swift for iOS.
Javascript for the Web.
Java (and now Kotlin?) for Android.
SQL for relational databases.
Visual Basic and C# for Windows.
Python for scientific programming and machine learning.
Developers don't pick a language because it makes them feel productive. They pick a language that allows them to write for the platforms where they want to deliver their programs. Or because it has the best libraries for their problem domain.
(Back end web development is somewhat of an exception, as every language can talk HTTP.)
It's not even necessarily that they have a steep learning curve, it's that there's such a deep case of TMTOWTDItis in each of those.
I can't speak to Clojure; I'm still learning it and haven't used it professionally. But it seems promising insofar as it seems to be quite opinionated. Groovy and Scala aren't. So they both have a lot of concepts to learn, and those concepts all overlap and interact in surprising ways. On my team, I've started banning certain parts of Scala from the codebase. Not because I think they're bad features, per se, but because carving the language down to some semblance of an orthogonal subset seems to be the only way to ensure that 4 programmers won't solve the same problem 6 different ways in the same codebase.
I run into the same problem with Haskell. Haskell's a great language and I think everyone should put some time into learning it. But it was designed as a language research platform first and foremost, and that's evident everywhere. So I'm hesitant to try using it on a large team. I'm kind of hoping that someday someone will produce the Haskell equivalent of Clojure. It doesn't need to try and be minimalist like Scheme. It just needs to have fewer than 5 string types, and save the senior developers from having to spend 85% of their time coaching the junior developers on when to choose a monad and when to choose an applicative functor.
Sounds like your talking about Idris, Elm(JavaScript), ReasonML([JavaScript] https://reasonml.github.io), or F#(.NET)... Monads are for context-sensitive mini-languages (>>=) (=<<): they have a direction and sort-of sequential semantics, >>= is concat . map, <$>(map) is for context-insensitive languages (can be run in parallel)...
What? Clojure is not similar to Scala at all. Its learning curve is not that steep, because it allows you to learn things "à la carte" - you can pretty much learn it while building things. I have personally met several people to whom Clojure was the very first language they learned. I once give a book to our test automation engineer, and a week later, he has built a dashboard (for test runs) in Clojurescript. He was like: "I am very much surprised myself how quickly I was able to build it." It was a wild mish mash of all sorts of libraries, weirdly looking non-idiomatic Clojure code, but it was a completely functional app.
Like I said, I don't know much about it other than it's a pure functional language that compiles to java byte codes, so I lump it in with Groovy and Scala which are both in the same family. Maybe it is easier - Groovy and Scala (as much fun as they both are) definitely aren't. Isn't it as "pure" a Lisp as they can get away with and still run on a JVM though? Lisp has sent many worthy men screaming for the hills.
This is the primary roadblock to Rust deployment IMHO. It's really hard to get over the hump at the start. You do all of the trivial examples in the manual just fine, but immediately run into issues when you write your own code.
The GUI is an issue for all the non-platform languages..
It took a lot of effort for Java with average results. Python's Qt wrappers seems to be more successful.
On Rust it goes beyond that, because borrow checker semantics still aren't productive in typical GUI programming patterns, like self referencial structs from event handlers, leading to Rc<RefCell<>> and clone() calls everywhere.
Not saying that it won't improve, just stating the current state.
Even with reactive UIs as way to get around those callbacks, relm isn't as easy as Fabulous, SwiftUI, Elm, with the caveat that reactive UIs are heavier on the memory allocator.
I would include C and maybe C++ in that. The perhaps biggest difference between Rust and C++ is that the C++ compiler doesn't bother you up front with memory correctness.
