Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I wonder how much of this is actually tied to the very partial clojure support for java annotations. Most other popular JVM languages have a much better integration story for annotations but they also embrace the OO approach.
Can, and most importantly should, clojure better support java annotations? Is it possible without harming its philosophy? Aren't we looking through the ring at the larger issue of clojure departure from the OO mindset which remains a strong assumption from all java (enterprise) API?
by fmjrey - Hello, I'm the author.
Clojure has some limited support for Java annotations, it's just that support is a bit ungainly, and that introduces enough difficulty that it leads to frameworks like Quarkus having no real adoption in the Clojure community.
Quarkus also relies on byte-code rewriting which may also cause difficulty for Clojure, but that's an aside.
Better annotations support wouldn't necessarily improve the ease of annotation-driven web frameworks in Clojure because the issue is more fundamental than that.
The real problem for Clojure is, from the original article:
> It's because in Jakarte EE 11 Context and Dependency Injection (CDI) officially becomes the single, unified component model across the entire enterprise Java ecosystem ... CDI is entirely driven by annotations, and annontations are entirely not Clojurish.
What I mean here specifically is CDI is the 'blessed' solution for DI in Java, CDI is clearly derived from many years of innovation by Spring, other DI frameworks in Java. Annotations is the path forward.
That means DI in Java is driven at a code-oriented, not data-oriented. Code-oriented is more natural in Java, and to give you a counterpoint, when I first worked with Spring (and very briefly with Rod Johnson for a couple of weeks on a client engagement, boring story) it was possible to configure Spring in XML.
Spring XML would be the equivalent of data-oriented in Java. Nobody in Java wants to do that, they want annotations instead.
In the article I say:
> configuring systems in code is a pale imitation of configuring systems in data. I much prefer my data-oriented system config library in Clojure to annotations in Java.
As it turns out I wrote something on reddit about this recently, you can find that here:
https://www.reddit.com/r/Clojure/comments/1vm668q/comment/p3...
Sorry for quoting myself and links back to reddit, feels a bit odd.
The point is - when you start configuring things in code, you are leaning into Java objects and/or code-level constructs for dependency injection, rather than the frankly far better approach in Clojure of using the wonderful Integrant library which relies on Clojure datastructures:
https://github.com/weavejester/integrant
And then of-course Slipway, which is also entirely Clojure maps.
If you are using annotations to configure your web server, you are better to write your webserver code in Java and have the server handlers call out to Clojure at the handler level. It inverts your entire codebase back into 'Java is in charge, clojure is an adjunct to that'.
by d_t_w - (as discussed in clojurian slack):
The argument seems to take the leap from 'Ring is the wrong abstraction for what I want to do' (fair enough) and concludes 'Ring is inadequate, and therefore Clojure has a viability problem.'
Ring is explicitly designed to be web-server agnostic and therefore intentionally does not expose the full Jetty/Jakarta surface. Many using ring aren't using Jetty!
If your app requirements are specifically EE/Jetty-centric, then bypassing Ring may be entirely reasonable, but I don't see how that becomes an argument against Ring's design, much less against Clojure’s viability for enterprise applications...when enterprise means "serious business" not "Jakarta EE".
There are a few actual issues with Ring's design (that are in the issue tracker) I can think of when it comes to it's ability to express valid HTTP semantics. But "it doesn't OIDC" isn't one of them (that's sort of a category error?)
All that said... The charitable reading of "Clojure has a larger problem for its future [...] in which we can produce enterprise-grade web applications" is one where the "we" is limited to Derek's company/team, which yea, sounds like they need more Jetty/Java EE than Ring provides. But if the "we" is the Clojure community as a whole, then I would dissent.
by ramblurr