Clojure is about its rigorous and pragmatic "immutability first" paradigm that you simply don't get from other PLs.

LISP is much more than just a runtime syntax, such as its distinct evaluation model and metalinguistic core.

The JVM was chosen for Clojure because of its reach and vast ecosystem. People have ported Clojure to other runtimes, even Beam (Clojerl), where it enjoys decent success, too.

> Programming language syntax scarcely matters.

Clojure brings more than syntax though... there's an opinionated take on making all data structures immutable (as in, structural sharing [1]) by default. That's a huge difference in how you architect the program and debug it.

[1] https://softwarepatternslexicon.com/clojure/core-concepts-of...

> With respect, this topic in particular has been beaten to death.

Yes and no. From the discussion here I've learned about the existence of jank, which wouldn't have come up a year or so ago and might be an interesting solution to a problem for me as it evolves (that problem mainly being me not wanting to use C++ or any of the other directly supported languages in a plugin ecosystem). So these things are worth bubbling up every now and again just for the discussion to have a chance to play out.

Have you tried Lisp Flavored Erlang [0]? I never got around to trying it out. I used Elixir for a couple of years, building web backends, and I truly loved the experience. I remember wanting to try out LFE but never got around to it before moving on to a different employer/stack.

[0]: https://en.wikipedia.org/wiki/LFE_(programming_language)

When it comes to concurrency, what can golang's runtime do that is so special? When I tried it, it seemed like a worse version of Erlang's for people that prefer C style syntax. Depending upon your design space pervasive immutability is a huge boon too and golang doesn't have that but Clojure does - Erlang obviously having that and more.

I always wished clojerl took off.

> the real value-add is in the runtime, not the syntax. Java has a solid runtime but it's not yet as good as Erlang's, maybe even not up to the standards of Golang

won't lie, this is hilarious. you got me from nodding along to being the spitting out food meme guy in a span of couple seconds.

JVM runtime is undeniably the most well researched and optimized runtime in history of runtimes, specifically in realm of concurrency and parallelism, it literally carries like half the world on it's back.

not to throw any shade on erlang vm - i've been a fan for well more than a decade, but other than making some interesting, but limited in practice, tradeoffs with regard to concurrency architecture, it doesn't really offer much more.

go's runtime is just a different beast altogether designed with different goals in mind and with no baggage of backward compatibility with legacy.

one particular detail i'm very grateful to Clojure for, is exactly the ability to use JVM runtime without having to touch any Java.

> Programming language syntax scarcely matters

on the contrary, it matters quite a lot.

you might be drinking some of that AI koolaid, conflating our suddenly hypertrophied abilities to produce code regardless of our familiarity with the syntax or the APIs with ability to produce and deliver good quality products, but this delusion is getting reality check as we speak.

a realization is propagating through the industry that being able to produce more code than you're able to review, comprehend and internalize is actually not a great thing.

and that's where syntax matters - it has to be high signal/noise, it has to expose you to right abstractions and it has to be pliable to allow the codebase reflect the problem in a way that minimizes cognitive load both during production and during consumption.

LLMs are language models and syntax is a crucial part of any language.

The JVM is perfectly capable of Golang-style green threads now. As for Erlang, the creator of Clojure have commented in the past on why he dislikes the Actor model, and I think it is a fair criticism. Sometimes I see people praising Erlang VM as some panacea in which all the VMs should strive to be like. This is overly simplistic in my opinion, and ignores the huge trade-offs that the Erlang VM has.

Are JVM virtual threads not on par with golangs's concurrency? I think core.async even uses virtual threads now

I think you might reevaluate the runtime claim, since the JVM is perfectly capable of stackful coroutines these says.

What can the Erlang / Golang runtimes do that the JVM can’t?

> Programming language syntax scarcely matters. It does to some extent but we the programmers tend to over-romanticize it. The runtime and its properties are the much better thing to optimize for.

I'm not sure I understand this argument. Java and Clojure share a runtime, but an idiomatic Java codebase is going to have a very different architecture and design to an idiomatic Clojure codebase. Conversely, a codebase written in Go may end up looking very similar to a codebase written in Java, despite using different runtimes.

Good thing you have a variety of those nowadays. Clojure runs in the browser, Node.js, cross-compiles to Dart, works stand-alone via babashka and has a brand new C++ interfacing implementation in Jank.

The ergonomics of using a proper REPL and interactive programming is hard to beat.

Yeah, the content + feel felt like I'm reading this in 2013.

Nothing wrong with that, it's a good thing that stuff is discovered anew [as opposed to being lost/forgotten], but it did bring a smile to me.

Yeah, the content + feel felt like I'm reading this in 2013.

Not even to optimize for, but to write correct programs you really need to understand the runtime which is usually broader than the syntax.

All Clojure (lisps) do is remove the stupidity of syntax.

Even if syntax is the minor thing, why wear a stupid, uncomfortable shirt while running when you could wear one so comfortable you scarcely feel it?

> Programming language syntax scarcely matters. It does to some extent but we the programmers tend to over-romanticize it. The runtime and its properties are the much better thing to optimize for.

But that really depends on what you're doing. For example if I'm not mistaken Amazon was run for a very long time on a Java backend. And so was GMail's backend (and back then GMail's frontend was, IIRC, Java converted to JavaScript using GWT).

And by "early Amazon" and "early GMail", we're already talking about massive scale. It's not as if the JVM got worse since then (as someone commented: a recent addition is that Clojure now use Java's virtual threads) and it's not as if it didn't scale.

So I'd say having Clojure on top of Java (for those using that Clojure: there's also ClojureScript, babashka, etc.) ain't really a problem, as long as you're fine with the occasional Java stacktrace and Java ecosystem (GP mentions that btw: that he's not familiar with Java and that, I think, can be a bit of an issue).

I'm not sure Clojure is about it's syntax: I like the focus on immutability / pure functions and I do really dig the REPL a huge lot. In addition to that something has to be said as to the incredible stability of the language and many of its libraries.

The big value add to me is that I can have a REPL and inspect, in dev (or in prod but that'd be wild), the app I'm working on. And manipulate it: redefining variables and functions etc. And it's not some hacky hot-reloading bolted on as an afterthought kludge: it's a real Lisp REPL. There's value in that IMO.

> Programming language syntax scarcely matters.

Certainly it matters much less in the modern era.

However, certain fundamental decisions of a language can be dealbreakers.

Requiring declarations on your functions and giving those declarations sigils so that they can be parsed quickly is an important syntax decision. Almost every modern programming language has converged to this idea.

Or take, for example, Lua. For me, personally, the 1-based-ness of Lua is simply a dealbreaker no matter how good anything else about it is.

For the "Lisps", I LOATHE the fact that you traverse lists and vectors in completely different ways--you can't just drop any container-ish thing into something that iterates/collects it. This is something that both Clojure and Racket seem to agree on--you have something that acts like a "collection" and you can walk across it the same way regardless of the specific type of collection it is. Of course, that is why a bunch of Lisp purists loathe Clojure and Racket while I like those languages. Shrug.

I find RAII (Resource acquisition is initialization) to be the source of all things evil if it infests a programming language. The popularity of C++ and Rust speaks to the quite large number of people who think my opinion is bullshit.

So, yeah, base syntax matters far less than it used to. But the engineering decisions that went into making that syntax correspondingly are far more important.