Cross posted from reddit https://www.reddit.com/r/Clojure/comments/dp1p2t/any_mature_open_source_system_to_learn_about/
Watching the talk “The Language of System” (https://www.youtube.com/watch?v=ROor6_NGIWU) inspired me to learn practical clojure programming, by studying the source code of some open source systems written in clojure.
My criteria for such systems are:
- Not a library, not a framework, not a command line tool - but a full-fledged system or application. This is because designing/implementing a system has many unique considerations, e.g. a command line tool can simply abort on error, but a real-world system has to bear with it.
- stands to the tests of real world usage (no research/toy projects even if it has lots stars on github)
For other languages it’s easy to find lots of candidates:
- python: zulip, openstack, ansible, etc.
- go: tons of CNCF projects (docker, kubernetes, etc)
- java: tons of apache projects (hadoop, hbase, zookeeper etc.)
- c/c++: countless of open source applications (xwindow, chromium, etc.)
However for clojure it’s hard to collect candidate projects, maybe due to me short history with clojure itself, here are a few:
Do you have any suggestions?
Hello @lins05! Welcome to Clojureverse.
I’d check out cljdoc if I were you. cljdoc auto-builds documentation for a large number of ecosystem libraries. It follows best practices, and gives a good chance to play around with a real-world system. Source is on Github, and the developers are responsive.
Thanks! The author of cljdoc also mentioned it in the reddit post
Then I guess you have two data points, haha
Are two more I can think of.
There is also the clojurians-log app, which was created exactly so people could use it as a learning project, and which is always in need of more helping hands.
I am also looking for examples. What I am missing in all the projects I have seen is how to deal with reusable modules.
Say I have a few modules which I want to reuse in multiple applications. Each module has its own routes, its own re-frame events, subscriptions and ui elements.
Then having a routes namespace for the application seems not the right thing to do. Some framework seams to be required. I would like to see such a system built by experienced clojurists.
I would consider myself an experienced Clojure programmer, and I have never experienced the need for this kind of wholesale reuse of vertical slices of an application. If there are things I want to share between code bases i try to extract them as a library, and wire them up in each project.
Routes are functions, re-frame events and subscriptions and components are functions. Stick them in a namespace, require it, and use them.
The other option would be to build your project around a framework that, given you follow certain conventions, can do some of the wiring up for you. As a whole the Clojure scene has generally stayed away from these kind of frameworks. Why that is exactly is a separate (long) discussion, but it does seem like the pendulum of discourse is swinging back, and some people are arguing in favor of more frameworkiness again. Duct and Fulcro come to mind. (The answer to whether you are better off with a framework or without is of course: it depends).
JUXT Edge is pretty much about it. There, modules are re-used via deps.edn’s :local/root, which is essentially a library extraction (but without the need for an artifact or remote git repo).
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.