Live data from Hacker News

Why Clojure?

gaiwan.co

201–210 of 302 posts

Re: Why Clojure?

#201

Earlier quoted context omitted.

> everything is different… I had to go through classpathes, then lein, then boot, then deps.edn All that stuff still works and I don’t think any of them broke their APIs? A lot of people still use lein for example. You’re talking about new choices coming along, which is a good thing. Of all the ones you listed, only one is a product of the core team, so it’s not like there has even been “change” on any official level…

> If your mindset is, “I need to be on the latest hot thing” that’s about you, not Clojure. You’re allowed to keep building your projects using any of those tools, they still have the same capabilities. Beware here: it might sound natural to you, but many (and I many _many_) people are working on stacks where "there has been no update to this lib for 6 months" means "the project is discontinuated and has been replace…

I can't talk about the life cycle of clojure libraries, but i have seen common lisp libraries that haven't been updated for almost 10 years that work perfectly. There is little the maintainer needed to fix.

Re: Why Clojure?

#203

The part about the "stability" is a bit surprising - in my experience, I try playing with clojure about once a year, and every time, everything is different (I mean, I had to go through classpathes, then lein, then boot, then deps.edn - what is the current way to "try and run a program" du jour ?) Also, is running your "hello world" still going to be incredibly slow, or has something changed in the core system (I kno…

If you like the language, don't let that stop you. Install leiningen and run: `lein new app my-stuff`. Then type `lein repl` and you should have a repl running. Alternatively, open the project in IntelliJ with Cursive installed or VSCode with Clava or other supported editors and start evaluating code at the repl. Go through a few tutorials, then go through one of the free books available online. Don't give up when yo…

Well, also, sadly, the first thing I would want to be right now happens to be... a GUI, which seems to be the archnmesis of Java in general, and clojure in particular ;)

Re: Why Clojure?

#204
post #193

Earlier quoted context omitted.

Neither defprotocol nor deftype introduce static typing into Clojure. Errors in their usage are not checked statically and are only discovered at runtime.

So what happens at runtime if errors are found?

you get runtime errors with a long JVM stacktrace

Re: Why Clojure?

#205

Earlier quoted context omitted.

What was it about Elixir that you found dissatisfactory? I am currently evaluating Clojure vs. Elixir for a new project.

I spent a lot of time objectively evaluating languages for a new project I built several years ago. Elixir won out. It has now been 12 years and I still believe Elixir was the right choice for the following reasons (this list is not exhaustive): BEAM handles concurrency better than the JVM. Elixir threads are implemented using private memory where Clojure uses public memory. Mix is superior to Clojure’s tooling. Elix…

If you want lisp on beam there is always lfe .

Re: Why Clojure?

#206
post #192
post #174

Earlier quoted context omitted.

I'd emphasize that it's a problem with your particular code base. If you set it up correctly, all dates are properly parsed at the boundaries and you would only deal with one type of date inside your app. I'm working on a large Clojure app with a lot of date handling and never had any issues. For me, a date is always juxt/tick date.

The parent comment illustrates the problem with one clear example. In real-world code functions pass around amorphous maps, they add, subtract and transform fields. There is no way to know what's being passed around without reading the source of the whole chain. Statically typed languages reduce the need to know how the data is structured or manipulated. The market has clearly chosen this benefit over what Clojure ca…

> There is no way to know what's being passed around without reading the source of the whole chain.

But that's not what a Clojure dev would do.

1) We use Malli [0] (or similar) to check specs and coerce types if needed at every point. Checks can be left on in production (I do), or disable–up to you.

2) If the coercion is difficult, use something like Meander. [1]

3) If even that isn't straightforward and you need actual logic in the loop, use Specter. [2]

4) If you're not sure what going on at intermediate steps, use FlowStorm [3].

5) But you're going to be processing a lot of data you haven't seen before! Use, Malli with test.check [4] and make use of property-based testing with generators.

None of this is "advanced" Clojure, this is bread-and-butter stuff I use every day.

6) Need a Notebook-like experience to get better visualization of intermediate data? Use Clerk [5].

7) Need special checks on API usage within your codebase? Use clj-kondo [6] with custom linters. They're less than 10 lines each.

Unlike default-mutable languages, or typed, it's safe and easy to use libraries with Clojure and they tend to have very little churn. Total opposite from Python or JavaScript (if you're used to that).

It's almost impossible to give the impression of what it is like to develop with Clojure if you've only ever used languages with static typing, or languages from the Algol family.

Honestly, I hated Clojure's syntax at first BECAUSE I COULDN'T READ IT, and I loathed "structural editing." After 2-3 weeks, I read it just fine and it's hard to remember I ever couldn't do so. Now I like it, and structural editing makes it so easy to change your code, I couldn't live without it at this point.

Basically, all my "fears"/dislikes were unfounded—it was a skill issue on my part, not a problem with Clojure.

[0] https://github.com/metosin/malli

[1] https://github.com/noprompt/meander

[2] https://github.com/redplanetlabs/specter

[3] https://www.flow-storm.org/

[4] https://github.com/clojure/test.check

[5] https://clerk.vision/

[6] https://github.com/clj-kondo/clj-kondo

Re: Why Clojure?

#207
post #200
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…

> Things you don't like can generally be fixed (at least locally) using macros and libraries. What macro do I use to make it not run on the JVM? :)

That's one of it's best features!

But it runs on other things—Microsoft's CLR, Dart's runtime, JavaScript's runtime, Erlang's runtime, and with Jank, on top of LLVM.

Re: Why Clojure?

#209

Earlier quoted context omitted.

I'd argue defprotocol, deftype, and defrecord provide much weaker guarantees than a type system. Dtuff like defprotocol tends to serve a similar use case to using an interface in Java. You specify the signatures for the functions, and then a concrete implementation can be provided using a library. Ring servers are a good example of this where you can easily plug different server implementations by just swapping a lib…

Nobody would argue that Java is not statically typed. That's my point. Clojure offers the same as what Java offers. If you write code in a defprotocol everywhere style, as many Clojure libraries do, your code won't compile if you got the types wrong. The same as Java. How's that not static typing? Which part of that is weaker? So what exactly this "Clojure dynamic typing" nonsense is about, I fail to see. Automatical…

That's not quite true though. Java tracks types in the signatures of the functions, defprotocol does not. If I make a protocol and then pass a wrong type as a parameter to it then I'll get a runtime error. It's not going to tell me that I passed in a wrong type at compile time.

I find using defprotocol in Clojure tends to be an antipattern because it just makes code harder to read by introducing indirection. The libraries using defprotocol use it to solve a specific problem of creating a contract for how the API looks.

Re: Why Clojure?

#210
post #188

I would like to learn ClojureScript for webapp development with react. But, in 2025, I don't know how to get started. In 2024 I had the same problem. Lein, Shadow, Deps? What do I have to use? How do I get started with REPL driven development? Any in depth video-tutorials on how to take advantage of nREPL in 2025? If I want to use React, how to use third-party packages? Should I use reframe, fulcro, or retit with ohm…

One part of the joy that came with using Clojure is that there isn't really any bad choice. For example, I wanted a quick and dirty internal web application for admin purposes. I went with reframe. Why? Because I wanted to try it. And I knew, that I could get things done with it.

This is probably not the easiest "framework" (not sure this is a good name for it) but it was very fun. I think, if I had to progress from just a toy to a really strong, user facing UI, I think it would still be a pretty good choice. If some feature is missing, or something doesn't work as I would have liked, I know it will not be difficult to correct it myself.

I know that this could feel overwhelming, but this is freedom in a world where you expect there exists a single "best practice". As long as the tool is powerful enough it will be fine. On my end, I appreciate the fact there is not a single "web framework" in Clojure. Instead you have tons of libs you can use that work well together because they are all tied with a few common concepts (like ring for example). If you don't like to choose the libs. There are a few people that provide a starter pack with somewhat nice bundle of libs in a single system like pedestal or luminus for only citing two of them.

My recommendation is to not lose too much time looking for the best choice. Most of them will be good.

Post reply on HN