Live data from Hacker News

My thoughts after using Clojure for about a month

acdw.net

41–50 of 204 posts

Re: My thoughts after using Clojure for about a month

#41
post #40
post #6

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

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.

Re: My thoughts after using Clojure for about a month

#42

Earlier quoted context omitted.

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.

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.

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.

Re: My thoughts after using Clojure for about a month

#43
post #6

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…

> 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 Ja…

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.

Re: My thoughts after using Clojure for about a month

#44
post #6

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…

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

Re: My thoughts after using Clojure for about a month

#45

Earlier quoted context omitted.

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.

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 happ…

^^^ This.

Re: My thoughts after using Clojure for about a month

#46
post #6

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…

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

Thousands of share-nothing actors (fibers / green-threads) with first-class support for communication between them, for a start. Erlang/Elixir -- immutability as well.

Re: My thoughts after using Clojure for about a month

#47
post #6

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…

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

Low memory usage.

Re: My thoughts after using Clojure for about a month

#49
post #6

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…

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

Re: My thoughts after using Clojure for about a month

#50

Earlier quoted context omitted.

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.

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.

Those differences are not due to the syntax, they're due to much deeper things like the differing type system.
Post reply on HN