Live data from Hacker News

My thoughts after using Clojure for about a month

acdw.net

141–150 of 204 posts

Re: My thoughts after using Clojure for about a month

#142
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…

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.

You might be speed-running to a conclusion and squinting too hard if you use the word "panacea". Similar to the weird childish name-calling people do in Rust threads (somebody met one brainless zealot and now of course they'll judge a community of hundreds of thousands of devs by that one loony).

I used Java, Golang, Rust, Elixir (so Erlang).

My opinion is informed. STM / share-nothing-actors lend themselves amazingly well to online services for many reasons, better explained by other people and documented elsewhere (and I did not come here to advocate but to express preference and offer the take of somebody who has been around).

I am not denying that the JVM might have almost caught up in the meantime. More than a decade ago it did not.

And yes the BEAM VM is absolutely and markedly _not_ a panacea. It has a few weird sharp edges. It's just that in my work I have found having to avoid them still worth it compared to the alternatives (global mutability and more primitive parallelism which was the case for the JVM for decades).

Re: My thoughts after using Clojure for about a month

#143
post #118

> "I do wish there were an easier way to move in the ]}]})))}-ness of block ends though." If he means navigating the AST, there is Parinfer: https://shaunlebron.github.io/parinfer/ Paredit / Parinfer ruined other languages for me. It lets you navigate up/down/in/out of the Clojure AST with keyboard commands and mutate those expressions, e.g. "Split" will split open the current data structure you're in: `(a| b)` =Spli…

Indeed. The incredibly clumsy way we choose to edit source code has baffled me since I was first acquainted with parinfer. Having to keep the source in the shape of a valid AST almost entirely manually is really annoying.

In the blind community, navigation by indent level is pretty popular, no idea why it hasn't caught on anywhere else.

I find it a nice middle ground between the craziness of vim and the slowness of traditional cursor usage.

Re: My thoughts after using Clojure for about a month

#144

Earlier quoted context omitted.

All true. And I loved trying Clojure for 3-4 weeks some years ago. Still want Erlang's runtime though i.e. the many green threads with share-nothing architecture that can communicate with each other.

Clojure on JVM with virtual-threads (green threads) and communicating only via core.async channels (CSP inspired) using immutable data structures is pretty neat, FWIW.

Cool. I might have to revisit, if I ever find the time. Thanks, your comment aligns with what multiple other commenters expressed.

Info gets stale. Fair.

Re: My thoughts after using Clojure for about a month

#145
post #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...

I do love immutability. If a language does not have it I am very weary of using it. I only made exception of Rust because of how good is it for so many things + you can design with immutability first and only use mutability when you truly have no other choice and/or just want more performance and are willing to shoulder the extra effort of verification (potentially fuzzy testing even).

Re: My thoughts after using Clojure for about a month

#146

Earlier quoted context omitted.

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

LLM bashing aside (although I tend to agree), I agree with midnight_eclair. The claim that Erlang or Go are outright superior to the JVM doesn't really stand up. They're better at some things, and worse than others. Regarding language syntax, it definitely matters. In the same way the vocabulary we use shapes our thoughts, the expression of a programming language shapes the implementation. Of course, as Clojurists kn…

I don't think you, I, him and others necessarily disagree at all here, it's just that living language has defects and I can't spend 30 minutes clarifying beforehand like I am doing a math proof.

To me the strengths of Erlang BEAM VM and Golang's runtime nullify their weaknesses (and of course they do have weaknesses, some are pretty hard to swallow too). To me they sit on the positive side of "right tool for the job".

I just can't work with global mutability anymore. It's an endless hopeless pit of determinism bugs. I picked my battles. Respect to whoever wants to make a career out of chasing them but that's no longer me. I want to make measurable business progress when I work and not babysit defects that should have stopped existing two decades ago.

I can agree with other posters that the JVM has come a long way. I might reassess if I get the time. And I am not bashing on anything here. I am saying what my experience showed me. To me it's tiring to pretend that all languages and runtimes are equal and I'll keep claiming they are not.

As mentioned above: I don't think we necessarily disagree at all.

Re: My thoughts after using Clojure for about a month

#147

Earlier quoted context omitted.

"As a rule of thumb, if your application never has 10,000 virtual threads or more, it is unlikely to benefit from virtual threads." https://docs.oracle.com/en/java/javase/21/core/virtual-threa...

Obviously. But it's really nice to have the option, and none of us knows the future. I've been bitten by those "0.1% chance" things much more times than I would be not-embarrassed to admit, and I know I a not alone.

I believe the point they were making is you can have millions of virtual threads on the JVM no problem. Your information on the JVM is outdated.

Re: My thoughts after using Clojure for about a month

#148

Earlier quoted context omitted.

Well, you are kind of using my comment to vent your frustrations about AI while it has barely anything to do with it -- but you tried to link the two, unsuccessfully. Which is not fair as you have no clue of my stance on AI and are extrapolating a bit too much. Syntax does not matter simply because it's an extremely leaky abstraction of the runtime below, is my point. Of course syntax must be high signal/noise ratio,…

> you have no clue of my stance on AI and are extrapolating a bit too much apologies, but maybe next time try to elaborate more on sweeping statements like "syntax doesn't matter", because in current context my assumption for why you would say that is not all that outrageous. > Syntax does not matter simply because it's an extremely leaky abstraction of the runtime below, is my point. that would be the reason why syn…

> that would be the reason why syntax does matter, wouldn't it? nobody wants leaky abstractions!

Well I thought we were describing our current reality, not our _desired_ one? Yes nobody wants leaky abstractions and yes they are everywhere.

Syntax matters insofar as to discourage bad habits, is what I'd refine from my previous statements. Most programmers go for the default so defaults and syntax that steers you the right way to think and write matter a lot.

That being said, people write FP Rust (myself included) and have plethora of JS libraries where immutability and FP patterns are the default. Which is a sad state of affairs but much better than nothing -- as it's introducing programmers to immutability and FP and they otherwise would never know.

> as evidenced by the fact that it has been implemented on top of a variety of runtimes with decent control over cross-runtime code reuse.

That was my top 1 reason to try it btw; I was intrigued by the fact that people are interested in making it work universally in at least two very different runtimes. To me that signals good language design and good architecture. Which I already knew; Clojure and Racket are amazing on their own.

> you're stating this as if it's a fact, but what is your evidence? afaik jvm has a very extensive actor model library (Akka) and clojure does include a solid STM implementation (https://clojure.org/reference/refs).

As already said multiple times in the thread -- my info is stale (as claimed by multiple posters).

That being said, has Akka started making full use of JVM's new green threads? Has Java itself started introducing immutability and STM / share-nothing as first-class citizens? If not, then by the "programmers reach for the defaults first" rule above I'd think Java is not yet ready. OK Clojure has these amazing libraries, kudos. Has anybody rolled up their sleeves and said "Alright, BEAM VM's reign is over, I am making the same or better runtime as them in Java / Clojure!"? If not, I'll not yet revisit.

I just don't want to deal with the endless pit of determinism bugs that global mutability nets us. The gift that keeps giving.

If Akka / Golang's runtime / Rust's various actor-emulating libraries catch up to the OTP, I'll very likely drop Erlang/Elixir because it's a struggle to have a good stable employment (or even contracting lately) with them.

Even if the BEAM VM is slower and has a few annoying sharp edges, its strengths nullify its weaknesses due to the nature of my work (HA web / API servers and also API gateways and orchestrators).

Re: My thoughts after using Clojure for about a month

#149

Earlier quoted context omitted.

Obviously. But it's really nice to have the option, and none of us knows the future. I've been bitten by those "0.1% chance" things much more times than I would be not-embarrassed to admit, and I know I a not alone.

I believe the point they were making is you can have millions of virtual threads on the JVM no problem. Your information on the JVM is outdated.

Good, thanks for the grounding. I'll have to reevaluate at one point then.

As I just posted in another comment (https://news.ycombinator.com/item?id=48384622), I'd probably drop Erlang/Elixir due to difficulties of employment and contracting -- if the more popular languages get those STM / share-nothing runtimes.

Re: My thoughts after using Clojure for about a month

#150

Earlier quoted context omitted.

Web / API services during bursts. Or just when you _really_ don't want to scale horizontally. Elixir / Golang can do this very well. And they do. I have supervised, led and authored such projects that are in production to this day. Rust too but it's lower-level and you kind of have to hand-roll OTP which of course will always fail.

from experience, during bursts it's never actual web/api server that is bogged down, it's the downstream io bottlenecks. if your accepting layer is abstracted away and implemented correctly, there is very little performance difference between different concurrency approaches and all you're exposed to as developer is implementation of your handler functions.

(Upvoted for a really relevant and valuable refinement to the thread.)

Admittedly that layer is almost always abstracted i.e. AWS / GCP and various other smaller hosted solutions that handle a good chunk of load balancing for us. In that landscape BEAM VM's strengths shine even brighter. I've seen firsthand that you can in fact bring a BEAM VM to its knees if you expose it just like that to the net. It's not pretty. Golang fares a touch better and Rust seems almost immune (provided one does not screw up their caching layer and don't do elementary N+1 query mistakes).

Post reply on HN