I don't agree that Clojure suffers heavily from the Lisp curse. The prevailing paradigm in Clojure code is the almost exclusive use of the built-in data literals as function input/output (as opposed to using custom datatypes). For this reason, we don't really use frameworks as Clojure libraries are usually quite simple to glue together.
The main reasons why it is still fairly niche I would say are
- having to learn a new editor paradigm, e.g. paredit and/or parinfer
- functional programming
- people who think Java/JVM tech is icky
- an overall lack of promotion by Cognitect
Furthermore, you will need to both like the properties of Lisp as well as the the restrictions of functional programming on top of coexisting with Java on the JVM. This is a fantastic proposition to my ears, but it sounds horrible to some other people.
It seems really nice to work with but investing in a niche ecosystem that adds another layer of complexity on top of a tall stack is a hard sell for me personally
We build a product in Clojure that runs on the JVM and in the browser (https://kpow.io).
Clojure/Clojurescript gives us a language/toolset that works in both the front and back ends. In some cases we have we have code in a single source file (.cljc) that works in both the browser and on the JVM with no modification.
The feature that cross-environment functionality implements in a single source file is complex in some cases (e.g. a grammar / parser / interpreter for a subset of JQ).
Both the front and back end use the same core functions and same datastructures to implement the product. Data is moved between front/back via Transit (and encoding format for Clojure datastructures).
In my experience the reduction in complexity through the stack is staggering. Once you've learned Clojure that is..
My experience with guest languages for the last 30 years is exactly the opposite, not only one needs to master the platform, there is also the need to add on top extra tooling, libraries and the occasional dark magic debugging knowledge for the guest language to decipher how the compiler chose to represent the guest language to the platform infrastructure.
Hence why I only play with them to learn about new concepts, but always go back to what gets delived in the box for production code.
Indeed, my point applies to all of them, to anything !JavaScript on the browser, to anything !C#/F#/VB/C++/CLI on .NET, to anything !Objective-C/Swift/C++ on iOS,...
Basically whatever gets added on top of what is available when platform XYZ SDK (or equivalent), gets installed on a fresh new computer.
That's a good reason. You are working above Java, JavaScript and others, and that's often something that you need to be aware of and the details of those layers leak in a little.
It's still worth it for me personally, but I recon the additional challenge.
If you try babashka and nbb it won't feel as much of an extra layer, but they're both interpreted, so expect only Ruby like performance out of them. That said, it's a good way to get started if you don't want an extra layer under Clojure.
I actually did learn Clojure on the JVM. I read two and a half Clojure books, built a number of side projects, and I worked as a Java developer for a few years so the JVM wasn’t an issue. But even with all that, building a web app is far easier for me using Python/Flask, even with minimal experience with the language or framework.
And if I want to build a web service, I reach for go because it’s faster and the memory footprint is much smaller. I guess maybe if I was working on a super complex project that justified using Clojure to build elaborate abstractions, I would use it, but most of what I work on is pretty straightforward.
ClojureScript I’ve avoided because I keep anything frontend-related that I work on as dead simple as humanly possible to avoid churn.
And babashka seems neat too but I’m already comfortable with bash, and shellcheck works well.
It sucks but I just can’t seem to find a good use case for Clojure, even though I love the tooling and the language.
I don't know that there are good use cases, you just use what you want. For example I use Clojure and its variants for writing command lines, scripts, websites, backend services, Cron jobs, programming exercises/practice, and desktop applications.
Sometimes I use it for data analysis and visualization as well.
I use it at work and for personal stuff.
It's not that it has some awesome superior or full featured framework or feature for any one of those use cases, just that it's overall a language I like to use and which I have more fun with, and it's sufficient at everything you'd need to seriously use it for all those things. I prefer working interactively over a running program, I prefer the flexibility to extend language to my own needs with macros and higher order functions, I like the simplicity of working directly with data instead of ADTs or single use containers like Classes, I prefer structural editing for navigating and modifying source code, I prefer functional programming over OOP, I prefer immutable defaults and value semantics, and I prefer Clojure's well thought out core sequence manipulation functions.
My point is that Clojure is well rounded, there's a few things it's not good enough for, but those are rare, stuff like embedded systems, AAA games, high performance audio or video processing, raw number crunching, etc. For everything else Clojure is adequate, so it's just up to what you want to use, if you enjoy Clojure and it brings you joy, you can just use it, you don't need to find a perfect use case that it's uniquely best at.
It is a layer of protection against JS madness, and just a plainly better designed language. State management is much less verbose and easier to reason about.
But it is hard to justify outside of SPA and for “in between” use cases that for example Next solves very well.
The tooling is far from simplistic to setup and the available options can be overwhelming. Its all the pain of the JS stack but with less easily available help and tooling that produces less helpful error messages.
I think the tooling nowadays is pretty simple to setup, but the information out there doesn't speak to that new simple way, so everyone starting is following something that pushes them to outdated tooling.
Install Java:
brew tap homebrew/cask-versions
brew install --cask temurin17
Install Clojure:
brew install clojure/tools/clojure
Type `clj` at the command line and play with Clojure!
Now install VSCode and get the Calva plugin for Clojure from the marketplace.
That's it. You'll have autocompletion, jump to definition, code formatting and highlighting, linting, support for editor integrated REPL, debugger, etc.
Then you can run:
clojure -Ttools install io.github.seancorfield/deps-new '{:git/tag "v0.4.9"}' :as new
And now you can create new projects from various templates using:
clojure -Tnew app :name myusername/mynewapp
This creates a new basic application project for example. Open it in VSCode and you can connect a REPL to it and start working.
The errors are bad, but understandable in 99% of cases with a little experience (like 2-3 weeks).
And the stuff about the tooling is flat out wrong. The CLJS tooling is light years ahead of JS tooling in my experience. Maybe that was different back in the day, but shadow-cljs is seamless. Vastly superior to working with package.json/babelrc/postcssrc/webpack.config.js/etc/etc/etc
If you are going to compare modern CLJS tooling against JS - you should also compare against modern JS tooling like esbuild/vitejs which operate at light-speed.
There are some critical reasons for several people. Performance is one of them and lack of support for async/await is another. JS has also significantly become better in the last 5 years while Clojure has remained mostly static.
