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 - (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