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

Why Clojure?

gaiwan.co

Post reply on HN
Print view View original

101–110 of 302 posts

Re: Why Clojure?

#101

Post by asa400 »

th0ma5 wrote: post #88
Lyngbakr wrote: post #58

Earlier quoted context omitted.

Personally, I prefer it when there is a solid default tool chain for a language rather than having to choose from one of several. That way, I know pretty much what to expect when I open any project in that language. I feel like this is one of the few places where Clojure dropped the ball and that deps.edn should've been there from the get-go.

What language ecosystem does this right?

Both Rust and Elixir get this right. I have used both in anger, for money, to ship real stuff, and while neither is perfect, they are both great.

To a first an approximation, every Rust project uses Cargo and every Elixir project uses Mix, and they are both first-party tools so they have a level of stability, approachability, and ubiquity that comes with being tied to the language. I’d kill for Clojure to have something half as good as Cargo or Mix and have it be the only build tool, but that ship has sailed.

Re: Why Clojure?

#102

Post by jwr »

newlisp wrote: post #81
jwr wrote: post #62

Earlier quoted context omitted.

Hard disagree: I never used Datomic and likely never will, and I don't feel like I'm "losing some of the language's value". Datomic is a database. You can use any database you like.

Datomic feels like a natural extension of Clojure for storing data—you get no impedance mismatch, you continue working with Clojure's data structures for storing, querying, and writing data instead of dealing with clunky query builders(or SQL strings), and you gain immutability. Sure, you can use any database you like, but then you're playing the same game as every other programming language, ultimately getting less…

I disagree. I tried to use datalog and it was not a natural extension at all, because of the lack of nil handling. I also found that I do not need (or want) full immutability.

I would not compare it to SQL: I do not use SQL because there is no distinction of in-band and out-of-band data (your data and your commands/queries travel in the same channel, which causes a world of pain). But there are other database approaches that work very well. It's not a problem at all to serialize your data and store native Clojure data structures, even better than datomic does.

In other words, I disagree that Datomic is somehow natural or superior: it is "a" database, excellent for certain applications, not necessarily the best choice for every application.

Re: Why Clojure?

#103

Post by jwr »

rednafi wrote: post #75
jwr wrote: post #61

Earlier quoted context omitted.

These articles are necessary to counteract armchair critics who are afraid of unfamiliar things and feel insecure. This crowd is loud: you can hear the choir of "but no one is using it, I tried it once and there were parentheses, I tried it and it was too hard, I hate the JVM" — there needs to be a voice that says it works (and works well!) for some people. FWIW, it works for me — I would not have been able to build…

It’s probably geared toward someone like me. JVM and parens are one angle. Another is that I get paid to work with distributed systems and databases, and Clojure isn’t even part of the discussion in that sphere. Go, Rust, and the usual Python and Node dominate there, so it’s hard for me to care. However, I dislike language monoculture and am curious about why people like the things I might not care about. This blog i…

> distributed systems and databases, and Clojure isn’t even part of the discussion in that sphere

I'm not sure what a programming language has to do with distributed systems and databases, but as another data point, I happily work with distributed systems and databases, using Clojure :-)

(see also https://jepsen.io which I would very much call a "part of the discussion in that sphere", written in Clojure)

Re: Why Clojure?

#104

Post by rootnod3 »

hlship wrote: post #93

I've been working in Clojure now for about 12 years. Maybe 12+ years of Java prior to that. I've created some great apps, and great libraries (in both Clojure and Java). I often describe Clojure as "the least worst programming language", which is an off-handed complement, but I think accurate. Things you don't like can generally be fixed (at least locally) using macros and libraries. The core is strong, a good basis…

Haven't worked much in Clojure, but I have the same experience with Common Lisp. The malleability and live image workflow is just very pleasant to work with.

Re: Why Clojure?

#105

Post by huahaiy »

yogthos wrote: post #24
moi2388 wrote: post #3

Because you want the type safety of lisp with the simplicity of the jvm /s

I've used Clojure for over a decade and the JVM has never been an issue. The only people I see complaining about the JVM are people who never actually worked with it. Meanwhile, there's zero evidence for the notion that static typing has any impact on code quality. https://danluu.com/empirical-pl/

For someone who needs static typing, Clojure give them defprotocol, deftype and defrecord.

Interestingly, most of the low level libraries in the Clojure ecosystem are programmed that way. If you open up the code of many popular Clojure libraries, you see defprotocol everywhere.

So really, Clojure does both: dynamic typing for application programming, mostly static typing for infrastructure library code. As they should be.

This tired argument of "Clojure bad for dynamic typing" just doesn't hold water. Keep repeating it is a sign of lack of critical thinking.

Re: Why Clojure?

#106

Post by MarkMarine »

chamomeal wrote: post #74
rednafi wrote: post #71

It’s great, and I learned a ton from Rich Hickey, despite not fully grokking Clojure or FP in general. I briefly worked at a small Clojure shop with an extremely talented crew. People were excited about FP and writing real business logic with it. My stack was different there. The problem started when the honeymoon phase ended, and the codebase grew as the business gained traction. Dynamic typing became a burden, and…

I’ve been having a lot of fun messing with clojure, but the dynamic typing really grates on me. At your clojure job, we’re y’all using spec? I haven’t looked into it yet, and I’m wondering how much it mitigates the annoyances of dynamic types

Coming from a love of strong typing (scala) clojure dynamic typing was a real adjustment.

One thing I grew to really love is how small my changes were when I’m just adjusting a decidedly brownfield chain of functions that operate on data. With go in place at work, I added a couple fields to a core data type in my business and I ended up with thousands of lines of changes to pipe them everywhere. Doing the corresponding change in clojure would be List[A] tells me almost nothing about the reverse function.”

Re: Why Clojure?

#107

Post by eddd-ddde »

hlship wrote: post #93

I've been working in Clojure now for about 12 years. Maybe 12+ years of Java prior to that. I've created some great apps, and great libraries (in both Clojure and Java). I often describe Clojure as "the least worst programming language", which is an off-handed complement, but I think accurate. Things you don't like can generally be fixed (at least locally) using macros and libraries. The core is strong, a good basis…

How does the REPL approach scale in very large codebases? I.e. code that talks to multiple services, complex configurations, etc..

Re: Why Clojure?

#108

Post by gavmor »

hlship wrote: post #93

I've been working in Clojure now for about 12 years. Maybe 12+ years of Java prior to that. I've created some great apps, and great libraries (in both Clojure and Java). I often describe Clojure as "the least worst programming language", which is an off-handed complement, but I think accurate. Things you don't like can generally be fixed (at least locally) using macros and libraries. The core is strong, a good basis…

I played with Clojure just a bit in 2014 because I wanted to write GUIs in Om, and this gave me a seriously warped habit of calling React.el('div',...) for a while. Sorry not sorry.

I'm used to using TDD for fast feedback as I'm molding my code. Do you miss unit testing? Or, do you find that the REPL in no way obviates unit testing?

And, do you miss static typing?

Re: Why Clojure?

#109

Post by huahaiy »

newlisp wrote: post #81
jwr wrote: post #62

Earlier quoted context omitted.

Hard disagree: I never used Datomic and likely never will, and I don't feel like I'm "losing some of the language's value". Datomic is a database. You can use any database you like.

Datomic feels like a natural extension of Clojure for storing data—you get no impedance mismatch, you continue working with Clojure's data structures for storing, querying, and writing data instead of dealing with clunky query builders(or SQL strings), and you gain immutability. Sure, you can use any database you like, but then you're playing the same game as every other programming language, ultimately getting less…

Not really. Database is where immutability may not be a good fit, at least not all the time.

In many use cases, database is where application state resides, hence a mutable database is a better fit.

There are Datomic flavored database in the Clojure ecosystem that is specifically design to address this point, e.g. Datalevin.

Re: Why Clojure?

#110

Post by MarkMarine »

wooque wrote: post #57
ilrwbwrkhv wrote: post #9

I run a multi-million dollar business which I started with common lisp. I since moved away to go and then rust but I've been looking at clojure again lately. For a team that needs to get s** done and has more per employee productivity than Faang combined it's hard to beat the speed with which you can build things when you have the repl and interactive programming. The jvm while doesn't have great error messages is a…

Why did you move away from go? I don't use it, but seems like productive language, being simple, fast to compile and performant.

You can make really shitty code in any language, and the go community’s patterns around essentially brute forcing things (or code generation when that fails, which is horrible. Time to learn another custom DSL just to have an abstraction) rather than have good abstractions built into the language… it becomes painful if you’ve worked in a language with a better systems.

Pointers and null values are inescapable in go, and people treat them worse than they do in C. Generics are too limited (I can’t define a scala flatmap like function) And I can’t make data immutable or control access in any fine grained way in go. Compile time in my go monorepo is minutes now. Someone added a bunch of go lint rules.

Post reply on HN