Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My thoughts after using Clojure for about a month

acdw.net

Post reply on HN
Print view View original

101–110 of 204 posts

Re: My thoughts after using Clojure for about a month

#101

Post by Jeaye »

Hammershaft wrote: post #91
Jeaye wrote: post #38

Once you learn Clojure's syntax and semantics, you're no longer bound to the JVM. There's ClojureScript (JS), ClojureCLR, ClojureDart, jank (C++), Basilisp (Python), babashka (SCI), and many others. This means that, if you don't know Java or don't like the JVM, you can likely use Clojure wherever you already feel most comfortable. For the most part, any Clojure code which doesn't use host interop will work on all dia…

As someone who loves Clojure, I wonder about the real portability across host languages. Do you have experience with any of these other dialects? (beyond the obvious CLJS & Babashka?)

I am developing a test suite for portability of clojure.core across dialects. You can find it here: https://github.com/jank-lang/clojure-test-suite

Currently, we have Clojure, ClojureScript, ClojureCLR, Babashka, Basilisp, Phel, and jank running the test suite.

I have only used Clojure, ClojureScript, and Babashka in production. But I am the creator of jank.

Re: My thoughts after using Clojure for about a month

#102

Post by rcarmo »

Jeaye wrote: post #101
Hammershaft wrote: post #91

Earlier quoted context omitted.

As someone who loves Clojure, I wonder about the real portability across host languages. Do you have experience with any of these other dialects? (beyond the obvious CLJS & Babashka?)

I am developing a test suite for portability of clojure.core across dialects. You can find it here: https://github.com/jank-lang/clojure-test-suite Currently, we have Clojure, ClojureScript, ClojureCLR, Babashka, Basilisp, Phel, and jank running the test suite. I have only used Clojure, ClojureScript, and Babashka in production. But I am the creator of jank.

I’d like to say thanks for that - I’ve been using it on my IR version of joker: https://rcarmo.github.io/projects/go-joker/ and it’s been very helpful to pin down bugs.

Re: My thoughts after using Clojure for about a month

#104

Post by xoxolian »

Hammershaft wrote: post #94
gertlabs wrote: post #2

The functional paradigm is a bit uncomfortable at first, but it does make problem solving feel... different. I personally find OOP to be the most intuitive for large scale systems design, but that's just me. Most models do not perform particularly well in Clojure, but OpenAI models fully utilize the power of the language. Subjectively, it kind of seems to match the personality. Data at https://gertlabs.com/rankings?p…

It's fascinating that Clojure has consistently the best performing solutions and yet at the same time such a low success rate. Do you have an idea as to why that is? If I had to guess, two things lowering reliability: A) Balancing parens might be tough on an LLM one-shot. B) LLMs generate tokens sequentially, but s-expressions mean the first forms to be evaluated in a body are usually the last to be written, so the L…

If B), then maybe the LLM should be instructed to prefer things like the -> and ->> operators. So the first forms evaluated are also the first written.

Re: My thoughts after using Clojure for about a month

#105

Post by fp64 »

HiPhish wrote: post #3

> I am now generating this website with Clojure As everyone knows, you are not a true lisper until you have written your own static site generator. It gave me such a great high with how easy it was to add my own "templating engine" on top, implemented all using macros. The downside is that the crash came hard; there is so much more to a good static site generator such as optimizing the output, supporting scoped CSS,…

Funny, learning Janet I exactly did that. Was quite a fun experience with the built-in PEG, so I did markdown parsing from scratch. Maybe eventually I will be a true lisper (fell in love with Scheme over 20 years ago but could never really use any lisp professionally. Now I at least do some small things in Clojure and babashka. I love babashka)

Re: My thoughts after using Clojure for about a month

#106

Post by jwr »

Hammershaft wrote: post #94
gertlabs wrote: post #2

The functional paradigm is a bit uncomfortable at first, but it does make problem solving feel... different. I personally find OOP to be the most intuitive for large scale systems design, but that's just me. Most models do not perform particularly well in Clojure, but OpenAI models fully utilize the power of the language. Subjectively, it kind of seems to match the personality. Data at https://gertlabs.com/rankings?p…

It's fascinating that Clojure has consistently the best performing solutions and yet at the same time such a low success rate. Do you have an idea as to why that is? If I had to guess, two things lowering reliability: A) Balancing parens might be tough on an LLM one-shot. B) LLMs generate tokens sequentially, but s-expressions mean the first forms to be evaluated in a body are usually the last to be written, so the L…

First, we would need to agree on what "such a low success rate" means. Programmers have a thundering herd mentality: there are usually 2-3 "top things" that are in fashion at any given time and the herd tends to go towards these top things. They are not necessarily good or "successful" (however you define that term), they are just popular today.

From my point of view, Clojure is a very successful language. It has been in stable development for >10 years now, with no major breaking changes (!). I was able to start a business using it and now make a living from it, all of it possible largely because Clojure reduces incidental complexity so much.

Now, as to LLMs, I can see this discussion is mostly theoretical, so let me pitch in with data. I've been using LLMs for Clojure for a while now and it works fantastically, from what I read about other languages, quite a bit better for me than for others. Balancing parens was a problem for early LLMs without tools, Claude Opus with clojure-mcp tools doesn't encounter that problem at all.

Additionally, the ability to try things in the REPL means that LLMs are very effective: all hypotheses and solutions are immediately tested, with automatic feedback.

Overall I get great value from LLMs and I am able to solve large problems with them.

Re: My thoughts after using Clojure for about a month

#107

Post by [deleted] »

jwr wrote: post #106
Hammershaft wrote: post #94

Earlier quoted context omitted.

It's fascinating that Clojure has consistently the best performing solutions and yet at the same time such a low success rate. Do you have an idea as to why that is? If I had to guess, two things lowering reliability: A) Balancing parens might be tough on an LLM one-shot. B) LLMs generate tokens sequentially, but s-expressions mean the first forms to be evaluated in a body are usually the last to be written, so the L…

First, we would need to agree on what "such a low success rate" means. Programmers have a thundering herd mentality: there are usually 2-3 "top things" that are in fashion at any given time and the herd tends to go towards these top things. They are not necessarily good or "successful" (however you define that term), they are just popular today. From my point of view, Clojure is a very successful language. It has bee…

[deleted]

Re: My thoughts after using Clojure for about a month

#108

Post by midnight_eclair »

pdimitar wrote: post #70
rashkov wrote: post #68

Earlier quoted context omitted.

What kind of software actually requires this? Honest question. Anything I can think of would probably be written by C++ devs

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.

Re: My thoughts after using Clojure for about a month

#109

Post by adrian_b »

bsder wrote: post #62
pdimitar wrote: 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. 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…

I agree with most of what you said, but I am puzzled about your claim about RAII.

Whether it is good for any kind of resource acquisition to look the same like an initialization is debatable.

On the other hand, I cannot see any counterargument to the principle that releasing any resources should not be done explicitly, but only implicitly, upon leaving a block (using reference counts for shared resources).

I doubt that you advocate for the use of explicit release commands for resources, which are a notorious source of bugs, so what is that you consider as not being the same as RAII?

RAII was a not very useful acronym that was just another form to say that the C or C++ programmers should never use the PL/I style of explicit free commands, despite the availability of functions like "free()" or "close()" in the standard library, but both memory and files and any other kinds of resources should be managed with automatic releasing.

I do not see how this sound principle can infest any language.

Obviously, I have seen examples of bad RAII implementations, like I have seen examples of misuse for any other programming principle.

Re: My thoughts after using Clojure for about a month

#110

Post by midnight_eclair »

pdimitar wrote: 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 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.

Post reply on HN