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

I too liked Clojure when I tried it some years ago (agreed on the composition and data structures; both are _great_). But 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 -- I am talking concurrency / parallelism here (for memory management I have no doubts Java is very good). And I know: green threads and stuff. Well, call me when you can do what Erlang / Golang can do. Then I'll look again, very seriously too.

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.

▲

manoDev a few seconds ago | parent | next [-]

> Programming language syntax scarcely matters.

Clojure brings more than syntax though... there's an opinionated take on making all data structures immutable by default. That's a huge difference in how you architect the program and debug it.

▲

scruple 24 minutes ago | parent | prev | next [-]

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)

	▲	pdimitar 19 minutes ago \| parent [-]
		I have and I did kind of like it but ultimately admitted to myself that I no longer want to use too niche or too new PLs. Elixir has a fairly solid ecosystem at this point and I am only going to switch to something even bigger (I already use Goland and Rust as well). Love the idea of LFE but it needs a bigger ecosystem.

▲

raspasov 13 minutes ago | parent | prev | next [-]

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

	▲	pdimitar 10 minutes ago \| parent \| next [-]
		Thousands of share-nothing actors (fibers / green-threads) with first-class support for communication between them, for a start. Erlang/Elixir -- immutability as well.
	▲	Thaxll 9 minutes ago \| parent \| prev [-]
		Low memory usage.

▲

weavejester 2 hours ago | parent | prev | next [-]

> 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.

▲

pdimitar 2 hours ago | parent [-]

I mean runtime guarantees and features. In this case: effortless / near-invisible concurrency and parallelism.

As mentioned, I did like Clojure. I'd switch to it if it was running inside the Erlang runtime (like Elixir does).

▲

weavejester an hour ago | parent | next [-]

To be clear, I'm not questioning your choice of runtime or language. I'm just curious why you think that "Programming language syntax scarcely matters", as to me that seems the same as saying "How a codebase is architectured and designed scarcely matters".

▲

pdimitar an hour ago | parent [-]

I don't see how the latter follows from the former? The former is much bigger and more abstract; syntax is just one of the vehicles to try and codify it.

F.ex. if you have an universal construct of green threads / fibers then 7 PLs could express it 7 different ways, yet underneath they'd all be the same.

▲

weavejester an hour ago | parent [-]

The programming language informs the design of the system. As I said in my earlier comment, an idiomatic Java codebase is going to be designed very differently to an idiomatic Clojure codebase, even if they both intend to solve the same problem.

	▲	pdimitar 18 minutes ago \| parent [-]
		But that's still not a function of the syntax per se; Java has no immutability encoded in its runtime, hence it does not offer it as a syntax either.

▲

jerf an hour ago | parent | prev [-]

I can't endorse it because I've never used it, but: https://zread.ai/clojerl/clojerl/12-clojure-to-erlang-code-g...

▲

bcrosby95 3 hours ago | parent | prev | next [-]

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.

	▲	pdimitar 3 hours ago \| parent [-]
		I agree Golang is a worse version of OTP, no question about it, but if you are not allowed to code in Erlang/Elixir/Gleam (which sadly is 99.9% of the projects on the planet) then Golang is the next best thing. It has footguns, sure, but with library support and discipline it can get you very far. To me it's embarrassing that PLs still tout syntax and various other goodies, completely glossing over runtime. I might be missing something. But faux humble statements aside, I feel many others are the ones who miss something -- and that's the fact that doing stuff in parallel is a fact of life for 20+ years now and it's time all popular PL runtimes finally wake up to that fact. If not, I am simply not considering them. And I am not saying that arrogantly though it sounds that way; there are some PLs that I _really_ liked and was almost heart-broken that I had to abandon them and not work professionally with them. But I have enough experience to know that runtime choice matters, a lot. For the record, Racket was one of those PLs I abandoned. I know they started working on parallelism some years ago but I had to make a decision next week back then so, Elixir + Golang + Rust it is for me.

▲

chamomeal 3 hours ago | parent | prev | next [-]

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

▲

pdimitar 3 hours ago | parent [-]

If they are, I have not heard about it (which does not mean much, I check Java once a year). And if they really are then I'd give Java a serious look again because it's a mature ecosystem that was gimped by ancient runtime decisions for literal decades.

▲

cogman10 2 hours ago | parent [-]

As of Java 24 (Java 25 being an LTS) I'd say they are equivalent. You can use a virtual thread just like you use a regular thread and there's basically no handicaps or gotchas. In Java 21, when they were released, there is a gotcha that the pretty normal use of the `synchronized` keyword would pin a "carrier thread" which ends up blocking all virtual threads from running on that carrier thread.

Pinning can still happen in some much more rare cases, same with go. For example, FFI.

The memory usage, performance, etc are all go like. You can spawn millions of virtual threads with hardly and memory requirements and without overburdening the OS with context switches. The JVM also enjoys faster GC performance with virtual threads.

	▲	raspasov 12 minutes ago \| parent [-]
		^^^ This.

▲

agambrahma 3 hours ago | parent | prev | next [-]

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.

▲

TacticalCoder 32 minutes ago | parent | prev [-]

> 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.

	▲	pdimitar 14 minutes ago \| parent [-]
		Elixir has all that _and_ Erlang OTP's amazing guarantees. Hence I landed on it. Elixir also offers LiveBooks i.e. you can create pre-made recipes with which you directly remote into your staging / prod and do stuff. All that with immutability and potentially 6 digits of actors / green threads with a share-nothing architecture. --- RE: early Amazon / Google, sure. They made do with what they had and it was and still is a heroic effort. But can we agree that they succeeded _despite_ the numerous warts and defects of the PLs and their runtimes at the time? Not _because_ of them? I feel that people latch onto the misleading "they succeeded with language X and are big, hence the language X is great" thing way too often. No. It's not true. The only thing that follows from "big company A made it big with language X" is: "company A has an amazing engineering team". Nothing else.