As long as Rust doesn't offer something similar as the REPL driven development Clojure offers, there is zero reason of preferring Rust (for me) over Clojure for the same tasks. Which, because of the last point ("Rust is not homoiconic") won't happen any time soon.

Now, if you need to do embedded system development, Rust might make more sense than Clojure, but it won't replace Clojure for the same tasks today.

Also Clojure is doing just fine, not sure what you mean by "dying". The core and the tooling continue to improve, there are lots of libraries, more people writing than ever. I just don't see this death you're describing.

The comments here just strike me as ignorant and incoherent as a whole. Why do people who clearly have no experience actually trying to do something in Clojure have so much to say about it?

Clojure may support things that look daunting to you, but if you actually had any goal other than critiquing the variety of things you actually have no use for, you would not have the difficulties you describe.

Maybe I'm spoiled, I remember JDK setup being a pain on Windows a decade ago when I used it last, if that's the problem then I get it. My spoiled experience on a system with a functioning package manager is basically install-and-go, and zero configuration required to get CIDER going after that.

I just don't get what's so bad about it, it's basically the same experience as Rust with Cargo; is that another "nasty" experience? What language with package manager has a better experience?

Not that you can't do it in Clojure or any given language.

In the end, they're happy with Rust. I really like what little Rust I've done. I still reach for JS/Node first only because I can get something working faster often because of what's in the box and in npm. It's far from the most performant, but often fast enough. C# tends to be my second level, though as I become more familiar with Rust, it may displace this.

You can't be an expert in everything and sometimes a given language will lend itself to the way you think in idiomatic terms.

The article is an anecdote on a personal experience, not an assault on Clojure or the ecosystem. Even if it is critical at a couple points.

- The debugger sucks

- There are other tools for debugging like Portal and Flowstorm, but they involve already knowing what the problem was so you can instrument the function and call it with the same arguments

- Java stack traces make the above very hard to do.

- You're a second class citizen if you don't use emacs. Half of Clojure devs are using the EMACS according to a community survey. Calva, the VSCode extension, does lots of automatic setup to make the REPL work, and when it doesn't work, you have no way to fix it. I have to restart the REPL a lot, which I'm told is the opposite experience I should be having. It took me days to set up a project just so my REPL would switch from Clojure to Clojurescript when I evaluate in different files, and everybody I asked about this didn't understand why I would need it because they were all using emacs.

- Complaining about Javascript and React and then having your whole ecosystem wrap around Javascript and React is really obnoxious. Reagent is falling behind in React versions and it's missing out on performance enhancements. If you need to do niche React things, it's a pain in the ass.

- This might just be me, but I used Citrus with Rum and I found it to be the most over abstracted thing I've ever seen in my life. I know it was inspired by re-frame, so maybe re-frame is the same. But it's like Redux X10 in terms of verbosity.

- Call me crazy, but the Java interop is worse than other guest languages because there's huge impedance mismatch between functional and OOP.

- There are very popular broken libraries. People say "It's okay if a library hasn't been updated in 6 years, because Clojure is so stable!." This is a total myth, there have been several flat out broken libraries being recommended in tutorials.

- While people are working on frameworks (Biff, Fulcro), there are no "best choices" for a lot of problems yet and it leads to frustration just trying to make a simple crud app.

The community hasn't been unfriendly or unhelpful, but sometimes it feels like I'm speaking to aliens.

The official Clojure CLI, for example, is just plain confusing, and that's most people's first impression to the entire ecosystem. The config files, while they use the wonderful `.edn` format, are also not intuitive. Newcomers are the most likely people to encounter the most amount of error messages... which are famously difficult to read.

And that's before you even get into REPL configuration, which involves coordination with your editor process, a client process, and a server process. Even if you have a tool like Calva or CIDER managing it for you, you'll still get confused when something goes wrong unless you grok all the moving parts.

Even if you figure that all out, you still don't have Parinfer or equivalents setup yet in your editor. Also, clojure-lsp tends to require some configuration to get working the way you want. And that's before you get started with ClojureScript, which brings the complexity to another level entirely.

Despite all this, I love Clojure. It's an expert's language, even though it shouldn't have to be. Once you learn this stuff, you respect why much of this complexity exists. It's inherent to the amount of power the language gives you.

But doesn't mean we can't make it easier to use and get started with.

But Rusher isn’t saying “use Clojure because it’s ahead of time as opposed to Rust/Go”. He’s making a point that some (often more niche) languages have built-in features that are better suited to what most of the development work is - debugging - and other languages should look to adopt them.

It takes more than just a language to create a productive development environment in 2020, especially one which is so flawed by designed to the point of not even being statically typed.

Clojure wasn't even optimized for this workflow, it's just the only one that works. So as much as I love the language I keep going away from it because I prefer the freedom of my own workflow.

I find Clojure is a lot more approachable if you start with Clojurescript / Reagent and go from there. You don't need to be running Clojure on the backend to make use of how awesome Clojurescript is, and it's about 10x more approachable.

Rust is competing with C++ for writing low level systems, whereas Clojure is designed for writing business applications.

Low level systems tend to have stable and well understood requirements, whereas the same cannot be said for business applications. Efficiency is not a primary concern of business applications, but flexibility is. The efficiency of Clojure is often "good enough" for business application, and there is no peer in flexibility. This explains the many fintech companies using Clojure, as well as many other B2B companies.

These issues have added noise/confusion to what used to be a much simpler ramp-up for new developers. For those who've been around for awhile, the overall experience definitely felt cleaner previously, with more obvious best paths. While it's hard to argue against more options, the effect on the ground is that it's also needlessly divided the already small community a bit too.

I do recall Clojure/Quil being faster than Rust/Nannou in terms of the feedback loop, because once you’re running a REPL and you start to change and tweak things you can re-evaluate them live in the context of the running sketch.

Neither offers as fast a feedback loop as JS/P5.js, though, and for me Quokka gives much of the benefit of Clojure’s REPL but with less setup, faster boot, and consistency between editors.

I love writing CL but there’s a reason it’s not enjoying wide usage nowadays, and I definitely wouldn’t go around recommending it to unsuspecting people without heavy caveats.

And if you end up concluding some other front-end language is better, Clojure is still a really good choice for the back end.