undefined | Better HN

0 pointsyogthos3y ago0 comments

Thing is that Clojure is a very different language from Java in pretty much every way. People who use Clojure are typically drawn to it because it's a Lisp and facilitates interactive development. I highly doubt that it's popularity is significantly affected by languages like Kotlin that try to be a better Java.

If you're looking for a Lisp that you can use in production then Clojure is your best bet. This is the selling point of Clojure, and why it's unlikely to be displaced by newer JVM languages from its niche.

0 comments

2 comments · 1 top-level

filoeleven3y ago· 1 in thread

Clojure being a lisp on the JVM is was what first drew me to try it out. Clojure being immutable-first, data-oriented, and having a core library based largely on the seq abstraction was what hooked me.

The lisp REPL benefits are wonderful, and I miss them all the time in other languages, but I also miss the overall design philosophy equally as much. Value-based data structures with atomic updates where necessary is something that ought to be the default for our industry. Give it another 40 years to settle, I guess.

yogthosOP3y ago

Yup, once you come to appreciate the elegance of Clojure, most other languages start feeling very clunky. Completely agree that defaulting to immutability was an excellent decision.

I also find that having everything operate on a common set of data structures makes it very easy to build data processing pipelines. If I use a library, I just have to know what data it takes as an input and what it produces as its output. The data is transparent and inert. I don't need to know anything about the internals of the library worry about any special behaviors.

On the other hand, if I'm working with OO based language, then library APIs are object graphs, and objects are opaque and volatile. I now have to worry about the behaviors of each individual object in the graph, and their state.