Fork me on GitHub
#aleph
<
2023-12-16
>
Matthew Davidson (kingmob)10:12:09

To Aleph users: Would you prefer the new compression codecs (Brotli, Zstd, etc) get included by default in Aleph, or would you prefer to add them as deps manually? > Include them by default > Leave them up to us to add React with the relevant emoji

4
3
oyakushev12:12:20

I might be a minority in these questions, but I overall don't like the dependency bloat, especially if it's avoidable. For example, I find the inclusion of Malli just to validate a few HTTP client options icky. But the ship has sailed on that one.

oyakushev12:12:49

Up to now, Aleph has been pretty conservative with dependencies. Yes, it shipped plenty of Zach's other homegrown stuff, but each dep was used extensively enough to justify the inclusion.

Matthew Davidson (kingmob)04:12:39

@U06PNK4HG I understand. Unfortunately, we have limited resources, and supporting modern codecs without requiring the deps started consuming more effort than I'd like, and I'm concerned about future maintenance burden. I originally designed it all to keep the codec deps optional, but that's trickier than it looks, it turns out. At its root, the issue is the Clojure language uses the same syntax for static member access and static function calls, and the compiler requires reflection to distinguish between the two. Twice this led to tricky ClassNotFoundExceptions compiling codec interop code (that Java itself has no problem with). I ended up writing a whole Java class just to provide a Clojure-safe facade for the problem. Despite that, the problem cropped up again in a new form. While I think I can still make the codecs optional, both choices started to seem equal overall, so I thought it worth asking the users if they had a preference. Other consequences: for Brotli, it's effectively https://caniuse.com/brotli, and I have no problem making it a default, and if optional, fewer people would enable it. Zstd's future is less clear, but including the Brotli deps and not the Zstd one would just be the worst of both worlds. Dependency conflicts are always a possibility, but that seems unlikely in this case. People with pre-existing Br/zstd deps are probably trying to modernize Aleph, if I had to guess.

👍 1
Matthew Davidson (kingmob)04:12:48

(Side note: I actually wish we could strip out some of Zach's deps, like Potemkin, and replace the object pool half of Dirigiste. Not sure if primitive-math still makes sense, either.)

👍 1
Matthew Davidson (kingmob)04:12:07

We discussed the same thing with Malli, and I wanted it included, because I (still) hope we'll use it to validate more than it currently does. It's a vote for the future, though I admit we don't use it enough yet. I'm curious, would you feel the same way if we'd used core.spec.alpha instead?

oyakushev12:12:04

I wouldn't feel the same since spec is an always-present facility, even though I don't like spec much. Malli feels like an app-level choice to me, not a library-level choice. But, in the end, reducing the dependency surface is an uphill battle that few people want to be involved in, so I don't try to overpush it.

Matthew Davidson (kingmob)11:03:10

> Not sure if primitive-math still makes sense, either.) (edited) Follow-up: primitive-math still makes sense, because the default Clojure math fns still don't warn about reflection. I ran some numbers in https://gist.github.com/KingMob/7ae74e2ba0b4700d1549a1b913a4e496, and accidentally using reflection was 35x slower.