The context (per my limited understanding) is that Leiningen, the older and still quite popular way of scaffolding and packaging Clojure projects, is easy to use but not simple; if you want it to do something a little different, it’s tricky because various tasks are complected together (I remember hearing this was due to its heavier reliance on Maven?).

Meanwhile the newer and officially more blessed way of making projects, deps.edn, is simple but not easy; to do basic things you need to assemble the pieces yourself, but if you want to make your own custom build pipeline it’s probably more intuitive than Leiningen.

borkdude’s new project seems to be trying to bridge the gap by providing some pre-canned equivalents of popular Leiningen commands, but built on top of deps.edn. Instead of lein this is neil.

(I only use lein myself at the moment but curious about deps.edn)

When I briefly played with Clojure a few years ago, I was surprised and disappointed that there was no official toolchain (just the informally-agreed-upon leiningen, which it sounds like they're moving away from now?). It was bewildering and a turn-off for me as a new dev, and very surprising given how cohesive and practical the language and standard lib themselves are

Easy or simple- I could see arguments for either. But I can't understand why they'd just punt on something so important in this day and age

tools.deps, which is mentioned above, is the official solution. It's been around for more than a few years.

This was in mid 2019, so I'm not surprised things have evolved since then. It's good they've got an official solution now, but when official tooling only gets introduced to an ecosystem after the fact, there often ends up being a schism in the ecosystem that can keep hurting for a long time; just look at Python (it's far from a perfect comparison, but still). And the original comment reads like a confirmation that this is happening with Clojure:

> Leiningen, the older and still quite popular way

> borkdude’s new project seems to be trying to bridge the gap by providing some pre-canned equivalents of popular Leiningen commands, but built on top of deps.edn. Instead of lein this is neil.

Maybe the story will be different for Clojure and people really will converge on the official solution eventually, who knows

I think in 2007, when Clojure first released, it wasn't common the way it is now that a language comes already with a full set of official tooling maintained alongside it.

I feel this trend started later on.

That said, it's also because Clojure is not its own runtime, so its actual tooling is the same as Java's.

This is how it started, just expecting you'd use Maven as was standard in Java back then.

Its the community that kind of decided they didn't like to use the Java tooling and on their own brought Clojars and Lein as replacement.

So I think that's why at first there wasn't any, and later the core team thought, okay, well, if people want Clojure tooling and don't want to just Maven as maybe it was first intended, then they'd rather take it over and do it how they think is best.

This is my interpretation of the history at least.

That makes sense, thanks for the context

Yes, there is a divide in the ecosystem for existing projects and knowledge, however new projects have a choice between two excellent, well documented and capable toolchains with sizable populations.

I understand that as a beginner this is painful. You generally want to be told what to do with tooling, then ignore it for a while when you learn the language. As you mature as a developer in that ecosystem, the choices become a great benefit. It's true in Python as in C as in Common Lisp as in Clojure.

I am a professional Clojure developer, and despite using Leiningen for many years I would say right now that I barely even know how to create a project or how to read a non-trivial project.clj. tools.deps on the other hand I feel confident with and believe it's one of the better systems out there. There are people who feel the opposite (in all ways), and I think that's _awesome_.

Nice use of complected. Rich, is that you?

I think it has snuck into the diction of many of us who've seen his talks

This looks great. I was just getting back into Clojure with some spare time while on my beach vacation, and I have to say... Lein was much more n00b friendly than deps.edn. Neil looks like just the thing I wanted.

Also, Borkdude is a beast. He's the Shakespeare of Clojure in that five hundred years from now it will be common knowledge that "of course, he was actually a team of people". Or possibly the common knowledge will be "he was the first sentient AI". I'm not sure.

Every week there's a new clojure thing, it's "them" 80% of the time.

A lot of the Clojure community seems to be like that. And the biggest beast of them all, aphyr.

I’ve written tiny little apps in clojure and really enjoyed it. But I did find getting started to be a bit tricky.

Cool to see stuff like this tool. I think one of the best getting started tools I’ve seen lately is Calva for VS Code.

I've never used Clojure but it's a JVM language so does Gradle work? I know Scala has its own tool but from the little I've played with Scala, Gradle seems to work just fine (though Scala tests didn't work with Scala 3 through Gradle last time I checked - might be fixed now).

Yes Gradle works, same for Ant and Maven as well.

Some people use those as well, you can find some set of tasks for each that add a bit more Clojure-awareness to them as well such as https://github.com/clojurephant/clojurephant for Gradle.

That said, tools.deps did add a feature which renders some projects who are built with tools.deps and use that feature no longer work with just Gradle/Ant/Maven/Lein/etc.

tools.deps allows you to depend on git repos directly, so if a library is published in that style, it can only be consumed with tools.deps (which is the now official dependency manager)

How does this compare with https://github.com/practicalli/clojure-deps-edn ?

Basically, tools.deps is configured through a deps.edn config file.

clojure-deps-edn is just a pre-configured deps.edn file to get you started.

`neil` is a command line that lets you edit your deps.edn using commands, instead of manually having to edit the config file by hand in an editor for example.

I found setting up Leiningen and the JVM and deps.edn so difficult and confusing on my old Mac that I gave up on learning Clojure because of it.

This might be less painful.

    brew install openjdk
    brew install leiningen
    lein new project
    cd project
    lein run

Ditto for the linked article.

Thank you. Will try that!

You can also do:

    brew install openjdk
    brew install clojure/tools/clojure
    brew install babashka/brew/neil
    neil new app myapp
    cd myapp
    clojure -M:run-m

If you're interested in trying out what the article is about (which I would say is more likely to become the new standard way as things evolve).

Except you now need an extra JVM instance just for Leiningen.

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. - Donald Knuth

This small inefficiency is not something worth creating complications over. The thing about baby steps is that when you use that sort of language you're already making things sound easier than they are. The first baby step is the hardest step to take. It takes months of work and many falls.

My hope is that they manage to write (+ 2 2) or something similar; I'm not trying to make learning the language hard.

You can also just...

  $ clojure some_code_you_wrote.clj

It's a shame that this is either missing or well-hidden in the official docs, common intro guides, etc. It's not how you make a "real" application or whatever, but if you're just trying to play with it, this way works great.

I hate having to make a "project" just to even Hello World. I much prefer the bash/Python/Groovy/etc approach of "drop some code in a file and run it".

you can even just shebang it. if the startup time sucks too much, babashka has you covered! just s/clojure/bb.

Is there a de facto NextJS of Clojure/script?

I’m really not qualified to comment but someone else will be able to keep me honest here.

Fulcro maybe? https://fulcro.fulcrologic.com/ It’s a bit more than NextJS though. I’ve never used it but there’s some clever ideas in data management in there.

There’s luminus too but that’s again more than Nextjs, i’d compare it to something like blitz in nextjs world.

The folks that created luminus are working on something new too.

There’s reframe which is less than nextjs but is so refreshingly simple to write in. The domino model is so easy to grok and work with in my limited experience.

I can vouch for Fulcro. We're using it at my startup and it's been great so far, from standing up a prototype quickly to now a 1-year-old codebase with many paying customers. The data management stuff is pretty novel and comes with a learning curve, but is worth it in my opinion. As an enterprise app, we've been able to turn around features in days if not hours. Happy to answer any questions.

neil

lein

babashka

uberjar

clojure

clj

nrepl

scratch.clj

bb.edn

Bit of a mess.

while it's a sign that Clojure ecosystem is evolving, I won't like an ending being like this.