Fork me on GitHub

1. Do a lot of people use clojure on production? 2. Who? 3. Why is a lot of libs being maintained? (monger, elastic…)


@rcustodio 1. Yes (assuming you mean "in general" rather than just in this channel). 2. There are several lists out there of companies using Clojure in production -- there's at least one on and I saw another one on Reddit. 3. I'm not quite sure I understand what you're asking there?


@seancorfield like mongodb has transactions now, but its lib ( has a PR of 1 month, and nothing, also elasticsearch lib doesn’t even support the newest version yet (6+), which is really bad, I know its open-source, but people don’t maintain it


If you are asking "it seems like many Clojure libraries are not updated much? Are they broken and out of date?" the answer is "It depends. Some of them are working, without needing frequent updates, because the language is stable beneath them."


Ah, you meant to ask Why are a lot of libs not being maintained?


Sorry, I forgot the not


English is not my native, sorry


I think, for MongoDB, a lot of Clojure developers have moved away from it.


At World Singles, we have almost completely stopped using MongoDB, and I stepped down as maintainer of CongoMongo a while back. I suspect the same is true for Micheal Klishin and Monger.


So.. is there a better DB to use than mongo? Why move away from mongo? (if you can answer)


Mongo is a great db (as far as I know) and elastic is a great search engine, getting bigger and bigger


Or there are better ways to use clojure that those tools are not necessary?


But Andy is right that many libs are simply "complete" and don't need much maintenance.


There are lots of problems with MongoDB. But it suits some people. We used it fairly heavily for several years but we've migrated (almost) all our data back to MySQL (Percona) now. We didn't want to maintain two "production-scale" DB clusters and we got everything we needed from MySQL.


The complete I agree, I use a lot of libs that are not being updated, but it really does everything we need


Really… you came back to MySQL, the company I work is leaving MySQL


Going from MySQL to Elastic


We are starting to use Elasticsearch -- I'm working on a spike for that right now actually -- and we're just using clj-http and the REST API. No need for a library there.


If we were starting from scratch with MongoDB today, I'd probably use the Java driver and interop instead of a Clojure library, to be honest.


Yeah… for that I agree.. I know the elastic java lib has socket connection, not sure how much would that help in performance


Other reason that libs are not maintained, people just get the java lib and interop


Part of the problem with wrapper libraries is they need to cover the whole surface of the underlying library -- and that's quite large for MongoDB -- and the "translation" layer is relatively trivial so there's a lot of "busy work" replicating the whole API without much benefit.


Thanks for that article, gonna read it for sure


I was thinking of doing a minimal app for twitch, just for learning more clojure and stuffs, I was thinking in use mongo, BUT I’m really interested in using Elastic so I can learn more about it


(the reason having a Clojure wrapper for JDBC is worthwhile is because the underlying Java API is so horrible 🙂 For more modern Java library APIs that's often not true)


I see, thanks


@seancorfield ha! I was about to bring up the whole bundling-postgres-to-use-its-FDW-powers-as "BI connector" but that post is by the same author who wrote about that!


this article is a great summary of issues. the composability isuse (or rather the lack of composability) is huge


(IIRC mong did end up cooking up their own BI connector eventually, though I have no idea what it is because I never use mongo)


@jesse.wertheim I went to a lot of MongoDB events over the years. They did a lot of one day conferences in the Bay Area in the early days. They were a wild, disruptive startup with dreams of overthrowing our relational overlords -- and it was very exciting to use such a flexible, "web-scale" document storage system -- but over time they sort of became the new Oracle. The last few events I attended felt dull and corporate and it was clear they were reinventing themselves to appeal to "The Enterprise". And that constant reinvention shows in their APIs and drivers: the multiple, incompatible (and often poorly thought out) query APIs, the breaking change to authentication in the 3.x system (they couldn't figure out proper auth in the earliest releases? really?)


And there was this claim of "almost no cost, no effort scalability" which was a complete lie. When we started to scale MongoDB up toward our MySQL data sets, and we plotted out the costs to scale the performance, we quickly saw that we'd be paying the same (or more) to run a high-scale MongoDB cluster as we already were for our MySQL cluster. The math just didn't make sense.

👍 8

That all said, document stores are a great "fit" for Clojure since our lingua franca is maps with potentially arbitrary nested data in them. The conversion to/from a MongoDB DBObject is almost trivial, no matter how complex our data structure -- and no schema was needed. Definitely heavy on the "easy" side of the equation.


@seancorfield so all your constraints where handled at the app layer?


Yeah, because MongoDB doesn't help you out there at all...


...well, in theory it does now, but we migrated off before we moved to 3.x.


Still no relations or foreign key constraints though. Such a pain. Pipelines are cool though.


I feel I am missing something obvious but I cannot figure it out. Everything is fine if I don’t try and use Any pointers gratefully received!

Alex Miller (Clojure team)12:11:40

@tomayerst it looks like the namespace is just java-time so (require ‘java-time)


@alexmiller of course it is. Thanks!


Is there a convention for when to pass in a map (or a adding more to a map argument) instead of making a function take more arguments?


I tend to prefer passing a map if there's more than 2 or 3 arguments, generally. I'll make exceptions sometimes, up to maybe 4 or 5 args, but beyond that I REALLY prefer passing a map.


^ This reminds me, is the keyword args pattern (`(fn [a b & kw-args] (let [opts (apply hash-map kw-args)] ...))`) a bad pattern? It seems to be less common these days.


I believe that many people prefer to avoid that, because having an explicit 'options' argument that is a map makes it a bit more straightforward to modify that map with Clojure functions before passing it down to other functions.

👍 4

If "no options" is a common case for calling such a function, providing another arity that does not have that options map, which calls the 'with options map' arity of the function with a default contents for that map, is one choice.


Makes implementations of such functions more concise too I guess, because we don't have to construct the map by applying hash-map.


Is there any documentation on the various syntaxes to access record properties? For example, with this record:

(defrecord R [a])
(def r (R. 42))
When is it preferable to access r.a using (:a r) versus (.-a r)?

Alex Miller (Clojure team)22:11:46

It’s always preferable to use :a

👍 4
Alex Miller (Clojure team)22:11:19

.-a is interop access - use the Clojure mechanism