I see a lot of myself in you, both proclivities, journey and the question. I don't think lisps strengths can be matched by piecemeal feature adoption. The GC,

I see a lot of myself in you, both proclivities, journey and the question. I don't think lisps strengths can be matched by piecemeal feature adoption. The GC, the REPL, the ability to reload code in a running process, the macro system, the minimal syntax - it _all_ comes together and it shapes your development process. Case Study: My finest work was written in Clojure, I'm pretty sure I wouldn't have a clue how to achieve the same in Go, Rust or whatever else the broad programmer base is typically interested in. The single most challenging project I've ever worked in, domain-wise, had so much churn in the spec because we laid the track as we went. We changed data storage products (Postgres -> Datomic), we frequently re-wrote the UI (back when ReactJS was popular and Redux etc were being proposed). We re-architected mid-way to use event sourcing as we needed to be able to recreate the system state at historical points in time. And so on. A lot of dysfunction as well. But Clojure was probably the biggest reason we managed to limp along. I can't imagine having to r-earchitect so furiously while pleasing a borrow-checker which tends to make refactoring much more extensive. Recommendation: If you want to give it an honest shake, but you're afraid (as I read it) of painting yourself into a corner, consider Clojure. Clojure is a fringe language, like all Lisps, but rides on top of two massive ecosystems: the JVM (Clojure) and Node (ClojureJS). Additionally, if Emacs/(Neo)vim is not your thing, there's an IntelliJ plugin, Cursive, and it all works _beautifully_. Additionally, the community, and its designer, have many interesting takes on software design which I found very educational. Where I think Lisp shines ? * When things are _complex_ or projects drift, revise and change often. The ability to be functional, to build custom DSLs, border-line custom interpreters with way less effort pays off. * If I had to teach programming to _complete_ newcomers, gun to my head * When valuing _genuinely_ different perspectives. Picking up Lisp offers more than yet another C-like language * When you have limited mental capacity for more stuff, i.e. you have a family life and a complex, demanding job already - maybe pick something that won't drag you through borrow-checker nonsense or category theory. Observation, why programming in the large tend to suck: Why normal languages kind of suck. -- Essentially, enterprise code tends to require a lot of lines, those lines can have bugs. People want to reuse code (write less code, really), so they start writing abstractions, leveraging the many different (flawed) tools their language provides. These are typically a _lot_ harder than Lisps function composition and macros (say, Rust macros, Python metaclasses+inheritance), this means complexity goes through the roof. Over time requirements shift and abstractions become less suited, now you're fighting on two fronts. I would say you either need Lisps ability to write terse code (macros being the unique feature), or you need a _good_ code generation tool. And we seem to have neither in most projects. Conversely: where is Lisp less useful ? -- The well-paved roads where a popular language has a set of finely developed libraries for solving your issues. But once your domain itself, your business logic, gets complex, there won't be a NPM, PyPI, or crates.io to save you.