Clojurians Log v2

((complement map?) 123) => true It should cover collections only. I think the shortest way to write the predicate I am talking about would be (every-pred coll? (complement map?))

I love me an every-pred. Super handy

Indeed, but I am not a fan of the naming of that fn either since there is really nothing that ties it to some . They are related functions, but seem totally discrete. They should have called those and-pred and or-pred instead or something to that effect.

of those two, some is definitely the most weirdly named one, though

I always need to look up whether I need some? or some

I don't see the need for a connection to some ... there's already some-fn

sorry, you're right... yeah, but that whole space is just not as consistent with the naming as the rest of Clojure IMO

My rule of thumb is that some? is only what I want if I'm asking for any value at all (i.e. "some value, any value")

With all of the Clojure dialects around, I wonder if anyone ever took the time to try and do a better (or just different!) version of just the names.

I think there is an experimental Clojure fork somewhere on Github where they author did a bunch of renaming. I stumbled into it years ago, forgot what it was called.

dunaj?

There's certainly some room for improvement. The Clojure core is generally great, but I agree that the naming is a little odd and inconsistent in places.

right @daveliepmann, that's it, but it seems dead now

I've seen a claim that Rich would change the some name if he had the chance https://www.reddit.com/r/Clojure/comments/cijg22/some_some_every/ev9iplh/

In the mid-2010s I started a list of "changes if Clojure ever had a v2" and I've been surprised by how sparse it is. I had a feeling of "OK, once contains? is has-key?...what else?" Similar to how short this list from Arne Brasseur is: https://github.com/piglet-lang/piglet/blob/d65d598a341f82d060c7ba86ef850a3c07b1e3ad/doc/porting_clojure_code.md?plain=1#L7

Some pretty good suggestions

even if short

I renamed a few things in Piglet (https://github.com/piglet-lang/piglet), maps are dicts, so map? becomes dict? (can confuse beginner to have map vs map?), and contains? becomes has-key?

uh sorry my reading comprehension isn't very high today 🙂 what Dave said

upcase/downcase is the rubyist in the me speaking

the class/type stuff is to lean into the semantics of the JS substrate, so class creates a class value, like the JS keyword does

Clojure v2 is intriguing to me. But then I think about how exhausting Python 2 vs 3 was for that community, and I hold my horses 😅

(I wrote half of this yesterday, passing it along today!). ——— We (mostly Christian) have some of our own stuff on top of the Java OTEL libraries. I would't recommend using either our Clojure stuff or the Java libraries below. Lots of Java versions to manage. Extra many java versions if you want to use GRPC instead of HTTP, with potential dependency conflicts with other Java libraries from Google. I haven't tried clj-otel, but from what I can tell, it relies on the same OTEL Java libraries I'd like to avoid (https://github.com/steffan-westcott/clj-otel/blob/9a1017e90f0b2e9d4668e3db33b4d0af2a245160/clj-otel-api/deps.edn). Mulog has experimental support for OTEL, see https://github.com/BrunoBonacci/mulog/tree/master/mulog-opentelemetry. Currently only available as a -SNAPSHOT release.

So no definite answers from our camp, other than "Java Otel libraries has caused some pain".

Oh… I read this after a bunch of other pro OTEL posts, particularly people being positive about clj-otel…

I will proceed with caution, bearing in mind your warnings - 🙏 thanks

Used otel extensively at previous work on top of Java, lots of hand rolled parts I can say it was extremely painful and I hate otel with a passion. Changing specifications, dependencies, just a ball of yuck.

Oh boy... That is more worrying

I haven't tried it but my hunch is this is less of a pain in a monorepo as all your services will end up using the same semantic versions and dependencies

Hmmm... The project that I am working on is a monorepo, so perhaps that is an up-side.

I have to be honest I am locked in the headlights of decision paralysis. All the reading I've been doing and all the comments on here have got me no closer to making a decision. NewRelic is a great tool / service, but I am aware of a serious cost implication that is not going to be an option. I have used Sentry in the past and I am tempted by it, but again the cost could potentially be a sticking point. Open Telemetry seems to perform very similar if not functionally identical role in terms of being able to see "under the hood" of an application and that is appealing, but I don't want to massively over-complicate the solution that I am working on while potentially damaging performance to only show myself that what I see working because of side-effects that I can measure already is true at runtime in the code.

I am a firm believer in being accountable and making code / software observable, but I can observe this code's effectiveness already and I am wondering if I am just over-thinking the whole thing.

I have had a good steer from @steffan with regard to figuring out if OT is a good fit for what I am trying to achieve, so I am going to go and look at it from that angle. Thanks everyone for your thoughts / comments.

OTEL's cost is not just technical, it can be the cardinality of attributes you're indexing so keep that in mind too

OTEL is not BAD, I just wish to use it in ten years from now

I think that I get what you mean, in that if I were to observe too many "things" with too much uniqueness based around the traces there is a maintenance implication AND a storage and usage risk along with that, all of which merits consideration, right?

> "OTEL is not BAD, I just wish to use it in ten years from now" This does seem to be a big part of a lot of people's response(s) - do you think that using a solution like Sentry, which is less of a moving target, makes more sense at this point in time?

I have no experience with it so I cannot say

I have used it in the past, really before OT was a thing, back in 2019 and I liked the experience, but the bean-counters didn't like the cost, even though I felt it was invaluable, and a LOT cheaper than New Relic was at the time. New Relic appears to have altered their pricing structure, and Sentry seems very reasonable to me at $26 / month for unlimited projects and users, so really Open Telemetry's USP is no up-front monthly or annual bill, but it will clearly alter the cost of maintaining and ongoing development, not to mention the cost of maintaining the data back end which are all burdens that are lessened by simply paying someone else to handle them, and using a stable library / API to interact with it.

Other approaches: #telemere or #mulog

I only have experience using mulog, works great and you can have lots of other publishers to send data to. But all three are viable solutions from what I gather in the respective channels (#clj-otel has one too).

Thanks very much

Using #clj-otel, works very well

That is good to know, as I am heading that way.

I recently started using telemere, since that seems to be a catch-all solution, though I haven't really used it for anything other than basic logging

It seems (I am 40% certain of this), that telemere does https://opentelemetry.io/docs/concepts/signals/logs output only. We primarily need https://opentelemetry.io/docs/concepts/signals/traces clj-otel only had traces when we started using it (before Telemere existed), and now has logs as well We export to AWS XRay via https://github.com/aws-observability/aws-otel-collector

Thanks 🙏 that seems definitive to me clj-otel it is…