Other recommendations for early viewing are "Hammock Driven Development", "The Value of Values" and "The Design of Datomic".
I don't know much about how they are doing financially though.
Eg, everything is just a grab bag of functions in an npm module (sometimes with a closure holding some state - I either reject or don't understand FP people when they claim FP doesn't have state).
Each module has tests, dependencies, a README, and if it is reusable by other projects, is even OSSd and published. Writing software as if it's going to be published makes me be more modular. Being modular makes things easier to reason about and therefore has stopped by codebase from becoming complex to work with.
The claim is that there is no hidden state - everything is made explicit.
But that's not what state is, closures are just an easier way to define lots of functions with similar parts.
EDIT: Sure, you can call "whether or not f() or x are defined at the moment of calling (y) => f(x, y);" a form of "state", but this is called late binding and is simply not a thing in purely functional languages like Haskell; the existence of f() and x is checked at compile time.
If a function closes over immutable values, then the resulting closure is an immutable value. If a function closes over mutable state, then its mutable state, often even uglier then mutable objects or structs which actually make the exact contents easier to identify at least.
Of course, these days its about Rust, Swift and LLVM, but it doesn't have those lispy properties we love...
I'm currently working on a single-person (but expected to grow) project in Clojure and really appreciate the concurrency and state primitives, the functional standard library, the ecosystem and community of high-quality standard tools and packages, and (while I seldom write them myself) macros, which enable you to you write amazingly readable code. The community has a strong preference to functions over macros, but used judiciously you can get things like Clojure's core.async. So you get the benefits of a Lisp without a lot of the drawbacks commonly pointed out regarding other Lisps. I enjoy it a lot.
It is great language to work in. I have found it very suitable for solving a wide range of problems. Many companies are using it successfully.
Sounds like your view of reality is based on the HN hype cycle. As far as I can tell there are many more companies using Clojure in production than Rust. (nothing against Rust, but just as an example of the bias)
If only I could find a day job using Clojure...
People just need a change every now and then, you can't get excited about stuff you see or use every day after a while.
I've been waiting for a native Clojure implementation (or on top of Python or the Erlang VM) ever since.
Writing from scratch those Java libraries, including a good quality AOT compiler and GC is not something to do as hobby on the weekends.
The best chance to get it is to extend something that is ClojureScript based. I think you can get pretty close to it.
My implementation was never really targeting production use, but rather exploring some ideas in the VM.
I would love to continue working on it, but I simply do not have time for such a project.
See github.com/clojit if you are interested.
Don't need AOT compilation; if you want performance, just stick with regular Clojure on the JVM.
I'd love to just see a small general-purpose interpreted Clojure (quick start up, small memory footprint, easy access to C libs), even if it lacked concurrency features.
There's the abandoned ClojureC project (https://github.com/schani/clojurec). There's also JVM-to-native compilers like gcj or ExcelsiorJet.
But at the moment, it doesn't seem like there's an established way to do all that.
* literal syntax for maps, vectors, sets, and regexes
* clear separation of functional constructs (`for`, `map`, etc.) vs side-effecting ones (`do`, `doall`, `when`).
* large standard library of built-in functions, with overall fairly nice naming of things.
I've looked at Scheme, but it appears to be missing those things. I think some of them may be provided by srfi's, but upon a quick reading I couldn't make much sense of how to include and use them.
In my mind, this is a product of containerization. Java solved a lot of problems that we faced with deployment. Containers have made deployment even simpler, and suddenly the Java runtime is no longer as valuable as it once was. Furthermore, in a service-oriented architecture we don't really need too much interop with existing code.
I think that Clojure is a fantastic language, and I use it for my side projects as much as I can. But the promises made by Clojure dont sound as sexy as they did several years ago, hence the lack of hype.