Interesting enough, JUXT has put Clojure Deps (https://clojure.org/guides/deps_and_cli) into "Adopt" and apparently seen the ecosystem quickly adopting it. Great to see that the ecosystem is getting less fragmented this quickly.
This is what they write about Clojure Deps:
> We have many older Clojure projects that use Leiningen, and a small number that use Boot (now on hold), but in recent years we’ve switched to deps.edn and clj. We like that builds are simple and fast, and since tools around deps.edn have accumulated rapidly we now use it confidently on all new projects, so we’re placing deps.edn in Adopt.
If you plan on creating your own radar, or you're just interested in how we went about it, there's also a blog post about the process at https://www.juxt.pro/blog/radar-2021.
Can't honestly say. Some people on #emacs told me that with some config SP was a superset of paredit. It's just that paredit was first and did 90% of my needs. It was also that weird mode that made me think structurally. It's some sort of a tradition you know.
Clojure looks like almost my ideal programming language, nice tooling, features that work well together, and not too hard to learn thanks to great beginner resources, awesome REPL, frontend support.
But I do like my types, so basically I'm conflicted.
Is there a better model than this for assessing dependencies? I've never given the problem any thought before this article. The organisation here is appealing, and it is a fast way of communicating thoughts on the ecosystem strength.
This is what they write about Clojure Deps:
> We have many older Clojure projects that use Leiningen, and a small number that use Boot (now on hold), but in recent years we’ve switched to deps.edn and clj. We like that builds are simple and fast, and since tools around deps.edn have accumulated rapidly we now use it confidently on all new projects, so we’re placing deps.edn in Adopt.