This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (50)
- # cider (6)
- # cljdoc (2)
- # cljs-dev (19)
- # clojars (2)
- # clojure (20)
- # clojure-dev (35)
- # clojure-italy (2)
- # clojure-norway (12)
- # clojure-uk (17)
- # clojurescript (7)
- # data-science (3)
- # datomic (10)
- # emacs (2)
- # events (1)
- # figwheel-main (2)
- # fulcro (8)
- # graphql (1)
- # juxt (3)
- # nrepl (4)
- # off-topic (23)
- # parinfer (1)
- # pathom (63)
- # re-frame (7)
- # reagent (1)
- # reitit (5)
- # ring-swagger (1)
- # shadow-cljs (23)
- # tools-deps (16)
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 http://clojure.org 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 (https://github.com/michaelklishin/monger/pull/175) 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."
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
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
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.
BTW, this is a good read for concerns about MongoDB https://www.linkedin.com/pulse/mongodb-frankenstein-monster-nosql-databases-john-de-goes/
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)
@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.
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.
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 clojure.java-time. Any pointers gratefully received!
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.
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
Is there any documentation on the various syntaxes to access record properties? For example, with this record:
When is it preferable to access r.a using
(defrecord R [a]) (def r (R. 42))