[HN Gopher] Clojure needs a Rails
___________________________________________________________________
Clojure needs a Rails
Author : janetacarr
Score : 146 points
Date : 2022-07-30 16:57 UTC (6 hours ago)
(HTM) web link (blog.janetacarr.com)
(TXT) w3m dump (blog.janetacarr.com)
| phtrivier wrote:
| And clojure is actually in a better position than other niche
| languages because _at least_ you have the option of calling the
| boring and maintained java library to ship _something_ (it might
| be something non lispy, maybe a bit less efficient and
| maintainable but at least you solved the business issue.)
|
| Try doing that in some other languages were your underlying
| platform has even less libraries than a JVM...
| janetacarr wrote:
| Interesting insight. I've never tried to call Erlang libraries
| from Elixir, but I'm not sure I'd want to either :)
| tyre wrote:
| It's very easy, as someone who went from Ruby to Elixir and
| had little understanding (to start) about Erlang.
|
| It might be more natural than going down to Java because
| you're mostly dealing with immutable data and Elixir is very
| consciously building on top of Erlang. In comparison, Clojure
| has always struck me as wanting to build on top of JVM but
| being an entirely different thing.
| vendiddy wrote:
| It's surprisingly seamless to call Erlang libs from Elixir.
| kartoshechka wrote:
| because you write erlang with some fancy macros :)
| phtrivier wrote:
| Oh don't get me wrong, it _is_ transparent to call an
| Erlang library from elixir.
|
| It's just that there are even _less_ library to call :P
| shakow wrote:
| I did it for some zip stuff that was already implemented in
| the Erlang stdlib, it was surprisingly easy. I assume the
| very small numbers of types in Elixir helps with that.
| [deleted]
| roguas wrote:
| Yes, you get the eco system. But to what extend, the very thing
| mentioned in article rails-like framework is not really
| accessible right? I am ok with clojure not backing web
| framework, but also this one place where interop with
| springboot would be nice is not there (right?).
| vemv wrote:
| I also thought "Clojure needs a Rails" some 5 years ago. Nowadays
| (multiple, real-world Clojure jobs later) I don't.
|
| I also learned that trying to second-guess why developers spend
| their time in certain libraries and not in other endeavors (like
| frameworks) comes across as pretty disrespectful and actually
| ignorant (considering that those people are very often more
| skilled/experienced than most of us).
|
| (Good related read: Open Source Is Not About You)
|
| So I'd recommend to anyone, open your mind, be ready to have some
| preconceptions changed, and contribute a significant deal to
| (Clojure) OSS to truly appreciate what we have. And write more
| interop ;)
| jayceedenton wrote:
| In my experience Clojure teams use high quality Java and
| JavaScript libraries all the time. It's more often than not a
| piece of cake.
|
| 'Clojure needs a rails' has come up perennially for that last 10
| years. I don't disagree, as I think convergence on one web
| solution rather than a constant churn would have great benefits.
| The idea that you can't use sysdig, or whatever, because there is
| no Clojure library, is nonsense. Interop is good and Clojure is
| nicer than Java for writing Java :)
|
| Also, you can overload functions with further aritiss in
| protocols just fine. Nothing to do with variadics.
| janetacarr wrote:
| I never said it can't be done. I did write this in a hurry, so
| I may have muddled my central thesis.
|
| I'm arguing two things:
|
| First, Clojure has missing or rotting libraries, requiring re-
| implementing logic we've all done at least once because people
| are fixated building the Rails for Clojure.
|
| Second, that the business case for using Clojure becomes weaker
| because the lack of open-source efforts on this front (due to
| the 'Rails Vacuum') causes either interal library building
| (extra time) or, more likely, interop. Interop, to _some_
| management, sounds an awful lot like using Java, but with very
| expensive Clojure developers to do it.
| huahaiy wrote:
| What are the "missing or rotting libraries"? Maybe a few
| examples might be helpful. In my over 10 years of using
| Clojure in production, I am not sure I have "re-implemented"
| a lot of logic that are not already covered by some Clojure
| libraries. Such examples are rare.
|
| Sure, I have used Java interop for working with Stripe, but
| that's because it is futile to maintain a 3rd party Clojure
| library if Stripe decided not to do it themselves. These
| proprietary APIs are constantly changing. It is perfectly OK
| to do Java interop in these cases. Any niche language will
| have the same problem, and Clojure interop with Java is quite
| pleasant to use, compared with using Java itself.
|
| As far as I can tell, using ring and related things are
| fairly standard on the server side, and re-frame and related
| things are fairly standard on the client side, so I am
| honestly not sure what is missing for Web development in
| Clojure, as Web development is the most common use case of
| Clojure.
|
| I am honestly confused.
| jacobobryant wrote:
| It seems unlikely to me that efforts to build web frameworks
| are causing a decrease in time spent building wrapper
| libraries. Developer time (particularly, open-source
| developer time) isn't a homogeneous commodity; people tend to
| work on things that they personally need. Anecdotally I can
| say that if I were to cease development of my own Clojure web
| framework, I would not immediately start writing a Syslog
| library instead :).
| justinhj wrote:
| I see exactly the same thing in the Scala community. Your first
| instinct when you need a library is to find a pure Scala one,
| when many times there are far superior (in terms of maturity,
| stability and documentation) in the Java word. Sometimes it makes
| sense to write an intermediate wrapper but not always.
| hombre_fatal wrote:
| I think this is just a cultural thing where the ecosystem prefers
| to compose things together. The Node ecosystem also hasn't
| centralized around a Rails. People tend to just use Express.
|
| Also, the syslog server example doesn't seem like something a
| Rails would solve.
|
| > can we please just get together at the next Conj conference
| decide what our "Rails" is going to be?
|
| I think these days we, OP included, tend to use "Rails" to not
| just mean a monolithic framework, but also one that monopolizes
| the ecosystem which is one thing that made Rails good.
|
| But since it's been tried before in the Clojure and Node
| ecosystems, maybe people just don't care for it.
| antupis wrote:
| I think what Clojure needs is to be best at some very practical
| real world usecase so kinda what Rails was 2007 or Python and ML
| were 2013.
| janetacarr wrote:
| Since it keeps coming up, I'd like to clarify that I'm not
| advocating for a port of Rails or some kind of analog. I should
| have chosen a better post title.
|
| I have never used Rails.
|
| I'm arguing Clojure has missing or rotting libraries, requiring
| us to re-implement logic we've all done at least once because
| people are fixated building web frameworks, and I think it's
| motivated by people trying to build the Rails for Clojure. I
| really can't think of any other reason for people to build so
| many web frameworks at this point.
|
| The Rails for Clojure is an idea, one the community rallies
| around, one where people won't reinvent the wheel over and over
| again, so that we can have a lot more non-web packages for
| Clojure.
|
| I'm quite literally saying, the effort could be better spent
| elsewhere.
| slifin wrote:
| Clojure typically doesn't attract the kind of developers who want
| to work on "boring" things
|
| So there is an imbalance there
|
| On one hand I'm kind of happy there's no one true way in Clojure
| to do web dev, because as I think Rich said, it's not a solved
| problem
|
| So if we couple too heavily to one opinion on web dev then it's
| going to fail us as a community on a big scale and be hard to
| move away from
|
| Sets of libraries are typically easier to swap out
|
| In reality I think most Clojure businesses end up on reagent or
| and reframe and they are the defacto ways of doing web dev
|
| For "solved" problems like stripe calls it would be nice if we
| had more people working on maintaining libraries but as a
| Clojurian myself I know I wouldn't do that myself so I only have
| me and people like me to blame
| keithasaurus wrote:
| > Clojure typically doesn't attract the kind of developers who
| want to work on "boring" things
|
| I kind of have the opposite opinion. I worked on a large
| Clojure codebase for several years. There was so much effort
| put into building tooling and libraries in Clojure because the
| ecosystem isn't huge, (and some of its bigger pieces are just a
| misadventure, ie spec). It was really frustrating to me because
| I felt like we were spending 50% of our time writing inferior
| versions of code that Python, Ruby, or even JavaScript already
| had as libraries. I'd have preferred that time to be spent on
| interesting things like business concerns. Of course, you can
| use java interop, but it's much more natural in Scala and
| Kotlin.
| huahaiy wrote:
| Care to mention a few examples of missing libraries that you
| spent 50% of time writing on the job?
|
| I can hardly recall a case where I could not find a Clojure
| libraries for. The only exception would be wrappers for
| proprietary APIs, such as Stripe.
| keithasaurus wrote:
| I have a little trouble remembering all the details, and
| I'm not sure I can speak to where things are now. Maybe
| it's more helpful to mention where I thought we got off-
| the-rails with building our own stuff?
|
| - unit tests with ephemeral dbs
|
| - db migrations
|
| - ORM library
|
| Many of these things exist in Java and in retrospect, were
| probably the way to go. One other pain point was that
| Clojure libraries would stop being updated, lag too far
| behind the java libs, or lack features. I remember this
| being the case with Google Cloud and AWS, and I think
| Elastic Search. I remember a number of times just
| completely swapping out the Clojure wrapper lib for the
| java lib.
| capableweb wrote:
| > Clojure typically doesn't attract the kind of developers who
| want to work on "boring" things
|
| I'm quite the opposite. I love Clojure, just because it is
| "boring". Maybe not "boring" as in well-known, but "boring" as
| in the core language and it's runtime doesn't change and is
| stable, like really stable. I've upgraded projects using
| "ancient" Clojure versions (released +5 years ago) and not
| having to almost do any changes, as both the language, the
| runtime and most libraries are so stable over time. It simply
| just works. If people want to introduce breaking changes, they
| tend to prefer to create entirely new libraries instead.
| thom wrote:
| I don't understand this at all. Clojure's all over the place in
| banks and fintech startups and they're all boring as hell.
| People don't spend a lot of time on random proprietary wrappers
| because they don't provide a lot of leverage, not because
| they're 'boring'.
| eternalban wrote:
| This is the second appearance of "boring" in this thread.
| There is also "boring" libraries. Somewhere someone should-
| be/is writing a thesis on _the psychology of programming and
| programming languages_.
| janetacarr wrote:
| I agree. Boring is tough to work on.
|
| I thought about touching on this in the article. Re-frame and
| reagent have become the default for Clojurescript development,
| but I have no idea how.
| seancorfield wrote:
| Could you elaborate on that? I don't do ClojureScript, but
| I've dabbled with it on and off since 2013 (I've been doing
| Clojure in production for over eleven years). When I first
| started looking at ClojureScript, Om was "the thing" and
| Reagent was the new kid. I built a prototype at work with Om
| and then rebuilt it with Reagent and found the latter much
| more pleasant and idiomatic to work with.
|
| Last year, I dipped back into ClojureScript and built some
| simple projects with re-frame and I really liked it. I can
| definitely see why re-frame has become so popular.
| ttymck wrote:
| At some point, do we have to consider that the problem might be
| Clojure itself? Does LISP lend itself to "Rails" -- a Rails that
| people want to work with? I ask, genuinely, as a near-total
| outsider.
|
| The comparison to Elixir got me really thinking. I appreciate
| your "call to action", but community consensus gathering wasn't
| necessary for Phoenix to emerge as an option-of-choice, it gained
| traction because it is _good_.
|
| Surely there are large organizations using full stack Clojure,
| similar to the Lawrence World-Journal. Is there something about
| LISP that makes it hard for them to abstract their "framework"
| bits into an open source package?
| jayceedenton wrote:
| > Is there something about LISP that makes it hard for them to
| abstract their "framework" bits into an open source package?
|
| No. I don't know what else to tell you.
| ttymck wrote:
| That's fair, I didn't intend to sound entitled, but "let's
| all decide what Rails-like to use" doesn't seem to be working
| for Clojurists, so I was hoping that poking at other avenues
| might spark some productive conversation.
| mark_l_watson wrote:
| It might be that simply committing strongly to a language, any
| language, has benefits? Years ago, a long term consulting
| customer hired me on a short fire-drill job. He had also hired
| some Clojure celebrities like Stuart Sierra and Stuart
| Holloway. They were incredible productive and fast. It was a
| very long time ago, but as far a I remember they had a small
| set up libraries they used. BTW, I was hired for a few hours a
| week to help with dev ops, not code.
|
| EDIT: I am currently working (part time) with an all in Common
| Lisp company. It is really nice to see a group of people who
| all love a programming language using it. As much as I like
| virtually ALL Lisp languages, I do sometimes feel guilty not
| just using Python when there are much better libraries
| available (e.g., machine learning, linked data, etc.). When a
| programming language has 1000x as many developers you simply
| get a richer ecosystem.
| jmcgough wrote:
| "community consensus gathering wasn't necessary for Phoenix to
| emerge as an option-of-choice, it gained traction because it is
| _good_"
|
| I think it also because there's two camps of elixir devs -
| those who came from Ruby and those who came from Erlang. The
| Rubyists have a fairly easy time being productive quickly with
| Phoenix because it (at a glance) is very similar to Rails. From
| there you learn about supervisor trees, genserver, etc.
| duncan-donuts wrote:
| The something is probably more philosophical within lisp
| communities. I'm relatively new to lisp (writing clojure/cl for
| about a year) and from what I've seen people prefer to bolt on
| small things instead of big frameworks. The full stack
| frameworks exist but they're hardly frameworks. They're closer
| to project templates than anything.
| davedx wrote:
| I don't think API wrapper libraries add that much value and I
| usually only use them if it's absolutely necessary. Most APIs are
| just REST calls...
| janetacarr wrote:
| This is mostly true tbh.
|
| But API wrappers handling things like retries, pagination,
| client-side business logic, and coercion from JSON. Having to
| account for all of that for two API calls is somewhat tedious
| and repetitive, and I'm sure we've all solved those problems at
| least a dozen times.
| huahaiy wrote:
| Retries, JSON coercions and so on do have Clojure libraries
| for them, so I am not sure why you want to solve these
| problems yourself, let alone a dozen times. Really not sure
| what your exact point is.
| the_duke wrote:
| Writing high quality ergonomic API bindings is a surprising
| amount of work, especially in statically typed languages.
|
| Every API has its quirks, sometimes returns different data, has
| edge cases for certain calls, has different error reporting
| patterns, rate limiting, authentication methods, sometimes has
| intended or unintended breaking changes, ....
|
| Sure, you can usually just manually whip up the code for an
| endpoint or two in a few minutes , but then you need to
| continually add endpoins, fix the edge cases, adapt to upstream
| changes, ...
|
| Good bindings make your life a whole lot easier.
| nickjj wrote:
| The blog post mentions Elixir and while Elixir has its own mini-
| Rails with a lot less opinions, you'll still run into the same
| problems as Clojure around things like wanting a Stripe supported
| library, or PayPal, or Braintree, or Paddle or a ton of other
| popular 3rd party SAAS SDKs that exist in Ruby, Python, Node,
| PHP, Go, etc..
|
| It's one of the reasons I stopped using Elixir. When I reached
| out to Stripe (and other 3rd party tools) they said the demand
| wasn't there to justify the dev time to maintain an official
| library internally. I think this is the reality to expect when
| using a more niche language. That may be ok if you're ok with
| that but it's important to know that's what you're getting into
| when you choose languages like this. It's a personal preference.
| bestinterest wrote:
| This brings up another point I hope someone tries to solve in
| programming. Every time a new language comes out we have to
| recreate millions of baseline libraries and it just sucks. As a
| dev I want to be able to make use of great libraries oblivious
| to what they are created with.
|
| GraalVM is trying to solve this with its polygot VM idea
| https://www.graalvm.org/22.1/reference-manual/polyglot-progr...
| nickjj wrote:
| > Every time a new language comes out we have to recreate
| millions of baseline libraries and it just sucks. As a dev I
| want to be able to make use of great libraries oblivious to
| what they are created with.
|
| Technically this tool mostly does exist already with the
| OpenAPI specification if we're talking about REST APIs. If
| you as the API provider put in the leg work to create a very
| detailed specification which is a YAML file, you can generate
| programming language specific SDKs out of it as long as the
| language has an OpenAPI library to consume this spec in an
| accurate way.
|
| Stripe has publicly mentioned[0] they mostly use this spec to
| generate their SDKs (even as of a few years ago), but I guess
| auto-generated code still requires some developer time and
| there's a quality assurance level of "hey we're dedicated to
| internally supporting this". It's a huge deal having a
| provider internally support your language's SDK.
|
| [0]: https://github.com/stripe/stripe-
| python/issues/694#issuecomm...
| jrochkind1 wrote:
| Honestly, as a rubyist, I more and more often run into new
| "SDKs" that don't have an official _ruby_ version supported!
| Ruby is no longer always considered popular enough to get an
| SDK from a vendor.
|
| I think the fundamental truth here is that so much of writing
| software these days is having open source to rely on. That
| applies to things like an SDK for a vendor API, but also
| applies to things like consolidating community effort on _one_
| approach to back-end web app -- instead of having a bunch of
| not really mature options, and also so effort can be
| consolidated on building additional things that work with that
| popular tool.
|
| I don't think these two areas are actually related like the OP
| does -- if we can just reach consensus on a web framework, then
| somehow we'll get things like a Stripe SDK, I'm not sure about
| that.... but I think the general challenge of "how do we get a
| sustainable, supported, mature/polished open source ecosystem
| of software that we can use that works together" is kind
| something we don't really understand, how _does_ that happen
| (or not) for a new language? I don 't think it's just "well, if
| we only get popular enough it'll happen on it's own", and of
| course there is a chicken and egg issue there too.
| nickjj wrote:
| > I think the general challenge of "how do we get a
| sustainable, supported, mature/polished open source ecosystem
| of software that we can use that works together" is kind
| something we don't really understand
|
| I think one problem is people who tend to flock to niche
| languages like to write libraries so what happens is you get
| a random person on the internet who makes a library, then
| they eventually stop using it personally and the project dies
| because they were the sole maintainer championing the
| project. You have this happen in parallel and the next thing
| you know you have 3-4 libraries that are either missing big
| features, fall out of date, go into maintenance mode, etc.. I
| saw this a lot with Elixir's community libraries (Stripe, AWS
| SDK, pagination, etc.).
|
| There is a chicken / egg aspect to it because I think the fix
| here is to eventually get popular enough where you have a
| large enough of a community around the language and ecosystem
| that the most popular projects for a specific feature get so
| popular that they can't die because too many people depend on
| it and then a bunch of folks start to contribute to it and
| the community informally blesses 1 solution as "the"
| solution. The chicken / egg problem here is that a lot of
| people want to use Stripe, not create a library to use
| Stripe, etc. so it never gets mass adopted.
|
| I think the best way for this to happen is organically.
| Trying to create a committee with an org with specific
| contributors trying to invent solutions is going about it in
| the opposite way. The best libraries tend to be extracted out
| of real projects and grow to become popular because the
| person or people behind it have a skillset around not only
| creating high quality software but also a dedication to
| create great documentation, can handle support, have lots of
| tests and generally have created a maintainable code base
| that makes it easy for others to contribute.
|
| > Ruby is no longer always considered popular enough to get
| an SDK from a vendor.
|
| Do you have a bunch of examples here? I haven't come across
| that with the usual libs I use (Stripe, Braintree, PayPal,
| Sentry, Datadog, Mux, AWS, etc.).
| lolinder wrote:
| > If we used interop for everything mundane, Clojure would really
| just be an S-expression shaped husk over Java code. Not a very
| good solution.
|
| I don't have a lot of experience with Clojure, but speaking as
| someone who uses Kotlin on the server side, this attitude strikes
| me as odd. _Most_ of the reason to use a JVM language is to take
| advantage of the mature and well-maintained Java libraries for
| basically everything.
|
| If interop is considered a last resort (to the point where you
| reach for a 3-year-old unofficial Stripe library over the
| officially maintained Java one), what's the point of running on
| the JVM at all?
| mark_l_watson wrote:
| On Twitter, PureDanger had a nice comment, something like: it
| is better style to directly call into a Java library than to
| write or use a wrapper.
|
| I am not sure if this really answers your comment, but I really
| liked his comment because I tend to write wrappers and re-
| evaluated my habits.
| janetacarr wrote:
| That's surprising. I listed the interop caveats here because
| sometimes it feels like a bandage intended to bridge some gap
| until Clojure matures.
|
| But if Alex said that, then maybe it's not. -\\_(tsu)_/-
| huahaiy wrote:
| Clojure is intended as a hosted language and embracing the
| host is the philosophy, so interop with the host is never a
| bandage.
|
| Again, I am curious where you get all these impressions
| that are contrary to most people in the community take for
| granted, such as:
|
| * Clojurians prefer libraries over framework, but you said
| we spent too much effort in developing "big web framework".
|
| * Clojure is intended to be a hosted language, so seamless
| interop with the host is the norm, but you thought interop
| is a bandage until Clojure matures.
|
| It's very interesting.
| mark_l_watson wrote:
| Janet, I hope I didn't misquote him. I save his tweet, and
| I am going to look for it.
| mark_l_watson wrote:
| "Idiomatic Clojure code calls Java libraries directly and
| doesn't try to wrap everything under the sun to look like
| Lisp... Where Java isn't broken, Clojure doesn't fix it."
| fmakunbound wrote:
| Perhaps that stance has changed over time. In Clojure,
| there's the clojure.string namespace just functions
| wrapping java.lang.String methods
| https://clojuredocs.org/clojure.string
| casion wrote:
| This is much more than "just wrapping". It allows strings
| to be used more readily with existing Clojure
| abstractions and/or allows idiomatic use without the need
| for being on guard to avoid reflection.
|
| Notably, Alex didn't write this library and only has a
| minor contribution to it.
| moomin wrote:
| I think the problem is that if you want to write code
| portable between clj and cljs, you're gonna need a
| lightweight abstraction. With that said, I'm still not
| sure how exactly the maintainers feel about portable
| code, having written a portable http library.
| janetacarr wrote:
| Thanks for the quote Mark, it's an interesting
| perspective.
| waffletower wrote:
| You should take Alex's words contextually, and with a grain
| of salt. You can easily see his commits in this project, for
| example: https://github.com/cognitect-labs/aws-api
| joe-user wrote:
| This library doesn't wrap the AWS SDK, explicitly calls out
| existing Clojure wrappers that do in the README, and none
| of his commits seem to conflict with the referenced Tweet.
| Am I missing something?
| mark_l_watson wrote:
| Thanks, point taken!
| [deleted]
| stingraycharles wrote:
| When I started out with Clojure, I was using wrappers
| everywhere, but after about a year or so realised that they
| added very little value, hurt performance, and made the code
| less simple. On top of that, wrapper libraries were often not
| complete in functionality.
|
| The pivotal moment for me with this was when dealing with
| Kafka, just using the "raw" Java library ended up being so
| incredibly much simpler than any of the wrapper libraries.
| code_biologist wrote:
| It's been more than a decade since I've used Clojure so I
| say this with a big grain of salt.
|
| Where there weren't good wrappers, just a few functions
| "wrapping" Java libraries for my project's needs always
| felt lightweight and lispy. The little internal APIs I made
| almost always passed around the library's raw Java objects,
| but with more Clojure idiomatic ways to construct them, or
| slapping some seq on the library outputs.
| brightball wrote:
| One point to running on the JVM is that you can leverage all of
| the existing Java app server infrastructure in your company for
| deployment.
|
| That stuff removes 90% of the arguments against using another
| language in a Java shop.
| hibikir wrote:
| It Kotlin it makes a lot more sense to use Java libraries,
| because for most purposes, the interfaces you'd write in Kotlin
| and the ones in Java are not all that different, other than
| coroutines. From Scala or Clojure, the differences in interface
| design are far larger. You are going from languages where
| mutable state is an optimization you want to hide, to libraries
| full of setters that return void. A land of monads, and maybe
| macros vs imperative programming. This makes the ergonomics of
| many mature java libraries just too much of a bother to use
| directly. There are cases where the effort to rewrite is
| bonkers (say, ApachePOI), and others where wrapping is sensible
| (see a variety of json serialization libraries which support
| different parsing backends, some of which will be straight
| java), but there are many libraries that are sensible from
| Kotlin, but are worse than a rewrite if you are using an FP
| language.
|
| Still, I think you are undervaluing the JVM itself, which is
| almost magical when it comes to production observability. It'd
| be a whole lot of work to come anywhere near that tooling
| support for ops if you were avoiding the JVM. Scala, for
| instance, can also transpile into Javascript if you feel like
| it, and there's a native project that compiles to LLVM, but the
| JVM has the vast majority of the use cases, and it's not due to
| the libraries.
| lolinder wrote:
| Yeah, I get that. Even in Kotlin there definitely a number of
| places where I prefer the Kotlin library to the Java, and I
| can see that it would happen more often in Clojure.
|
| That said, the example in the article is the Stripe API, and
| I cannot see a good reason not to just use the official Java
| one. I've used it a ton, and it's as simple as can be--you
| pass a map in and get back an object. If that's a problem,
| either Clojure has a way worse interop story than necessary
| or the author is suffering from a variant of not-invented-
| here syndrome.
| golemiprague wrote:
| googlryas wrote:
| One problem with interop is you import the design/ergonomic
| considerations that may come from other languages, while
| neglecting what is uniquely powerful about your own language.
| thom wrote:
| I think the thing people most struggle with in Clojure is that it
| looks like it should be an incredibly pure, deeply opinionated
| language but it's actually extremely pragmatic. There is never
| going to be a long lived, vertically integrated, do everything
| framework for Clojure. If it was going to happen it would have
| already. Rails took off because burnt out enterprise Java
| developers wanted to quit and have fun again. Clojure happened
| because enterprise Java developers wanted to do enterprise Java
| better.
| roguas wrote:
| This is true, clojure is not super opinionated as people tend
| to think. Its nice, as you get to ramp up easily. There seems
| to be a steady path where you start with writing "java" in lisp
| and end up with pure functions and 1 reduce + something to
| trigger side-effects. I have worked with 4 codebases and they
| differed vastly.
| egypturnash wrote:
| Suzi just needs to find an excuse to spend a couple years
| building a serious thing _entirely in Clojure_ , no matter what.
| And then to disentangle all of the logic particular to her thing
| from the application framework she's built for this (or the
| existing one she used as a starting point), as well as
| disentangle anything that she thinks should be an external
| library, and release it all for free.
|
| Suzi may need to wait to do this until after her current gig has
| won the Startup Lottery. Or perhaps she may need to quit her
| current gig and figure out how to get a bunch of other Clojure-
| lovers to pay her rent while she does this. Good luck.
| janetacarr wrote:
| One can dream ;)
| egypturnash wrote:
| Good luck! Getting this post on the front of Hacker News is
| probably a step in the direction of finding a way to pay your
| bills while spending a year or two building Canals For
| Clojure to the point where it attracts other people to build
| libraries and plugins for it.
| fmakunbound wrote:
| This might be what happens when the community seems to follow
| "composable libraries over frameworks". You still have to do the
| composing, and it's not obvious how to do that.
| rubyist5eva wrote:
| Stop trying to make Rails in things that can't be rails. Rails is
| Rails uniquely because it is RUBY on Rails. It plays uniquely
| into Rubys strengths, that's what makes it what it is.
| dustingetz wrote:
| clojure is about simple composition not magic, so any solution
| starts by solving frontend/backend data sync in a composable way.
| Absent that you are just in the tarpit so most commercial shops
| might as well be in the typescript tarpit with everyone else and
| benefit from the larger ecosystem.
| polote wrote:
| If you need a Rails, why not directly use Rails? For what kind of
| web application Clojure is better than python or Ruby or nodejs?
| LesZedCB wrote:
| its not object oriented, for one.
|
| i work in rails, and my main hobby lang is clojure. i hate the
| thinking patterns of OO more and more every day.
| wirrbel wrote:
| I developed for fun in Clojure and ClojureScript probably for 3
| years, it was tremendous fun and got me into Lisps. In many ways
| Clojure does still hit the sweet spots from a language design
| perspective for me.
|
| I have revisited Clojure every now and then after and IMHO its in
| a weird state, too popular and successful to completely die, but
| also limited to reach wider adoption.
|
| When revisiting old projects I have seen countless of Clojure
| dependencies having died in the meantime. I have replaced utility
| libraries with more recent utility libraries sometimes several
| times. Very annoying. Paradoxically the core API is really stable
| to a degree that bugs aren't fixed that are a behaviour userland
| code might rely on.
|
| But its overall I think more of a symptom than a cause for
| frictions when developing Clojure. Community management is bad,
| even worse that RH nourishes this elitist aura around himself.
| Then the JVM integration is of course the blessing that led to
| Clojure's initial success but is at the same time limiting. The
| Java community by majority seems to gravitate towards Scala
| (weird scala version incompatibilities incoming, Scala DLL Hell)
| and Kotlin.
|
| So overall Clojure is in a strange situation. For picking it up
| on-the-job its not the responsible choice probably for most
| situations I work in. For my private tinkering the JVM dependency
| feels just a little too heavyweight. I don't see that Clojure
| will hit an inflection point of adoption in any way in the future
| that would make it a viable candidate for me to use at work.
|
| I really would hope that a Clojure-on-guile or Clojure-on-racket
| implementation becomes ready at some point that would make me
| want to switch from Scheme to Clojure for the toy projects at
| least.
| cr__ wrote:
| > Community management is bad, even worse that RH nourishes
| this elitist aura around himself.
|
| I have never seen Rich say or do anything that matches this
| description.
| roguas wrote:
| I think RH emits fun grumpy vibes, the good kind. Seasoned
| dev who is tired that his way of dealing with programming is
| not more prevalent. Very down to earth, lets just do it
| better.
| draw_down wrote:
| huahaiy wrote:
| "countless of Clojure dependencies having died"?
|
| What exact does it mean by "died"? It does not work any more?
| Very unlikely.
|
| In the Clojure world, it is the norm that a 5 years old library
| works as well as a one-week old one.
|
| If you mean "died" by "not updated any more", sure that's the
| norm in Clojure as well. Some libraries are done, and some
| authors moved on. But most likely, these libraries can still be
| used just fine.
|
| My production code base contains plenty of libraries that are
| not updated for ages, but I consider that a benefit, not a
| fault.
| lgessler wrote:
| > Paradoxically the core API is really stable to a degree that
| bugs aren't fixed that are a behaviour userland code might rely
| on.
|
| Can you give an example? As a medium user of Clojure I struggle
| to think of anything in the core that could rightly be
| considered a "bug" and fits this description.
| wirrbel wrote:
| Its been a while, I remember some strange behaviour of
| generic functions on sets* that differed from the behaviour
| in lists and bug reports about it.
| krn wrote:
| > When revisiting old projects I have seen countless of Clojure
| dependencies having died in the meantime. I have replaced
| utility libraries with more recent utility libraries sometimes
| several times. Very annoying.
|
| Yes, the "best in class" libraries change every few years in
| Clojure's universe, but they always bring huge improvements
| that require completely new APIs.
|
| For instance:
|
| https://github.com/plumatic/schema ->
| https://github.com/metosin/malli
|
| https://github.com/juxt/bidi ->
| https://github.com/metosin/reitit
|
| https://github.com/bhauman/lein-figwheel ->
| https://github.com/thheller/shadow-cljs
|
| https://github.com/stuartsierra/component ->
| https://github.com/weavejester/integrant
|
| https://github.com/technomancy/leiningen ->
| https://github.com/practicalli/clojure-deps-edn
|
| > So overall Clojure is in a strange situation. For picking it
| up on-the-job its not the responsible choice probably for most
| situations I work in. For my private tinkering the JVM
| dependency feels just a little too heavyweight. I don't see
| that Clojure will hit an inflection point of adoption in any
| way in the future that would make it a viable candidate for me
| to use at work.
|
| I think about programming languages as tools for different
| bottlenecks.
|
| - Computational: Rust
|
| - Networking: Go
|
| - Business logic: Clojure / Python
|
| And for many people Python has everything that Clojure is
| missing: a very low barrier to enter, and a very stable and
| well-documented ecosystem of frameworks and libraries.
| huahaiy wrote:
| "very stable" and python in the same sentence? I am not sure
| about that.
| wirrbel wrote:
| Do you want to back that up with something else than the
| Python2-to-3 migration? Python 3.4 was released in 2014 and
| ever since stability was never an issue for me.
| huahaiy wrote:
| Of course. I have plenty of cases when working django,
| flask, and tensorflow code stop working after bumping the
| dependency versions.
|
| In fact, it is rare that I do not need to change code
| after I upgrade python dependencies. Most likely I have
| to change my code.
| krn wrote:
| What I meant, is frameworks like Django, Flask, and
| PyTorch. Also, libraries like Pandas, SciPy, and NumPy.
| That's what Clojure is missing the most for an average
| software engineer: simple and easy choices, that can remain
| relevant for decades.
| huahaiy wrote:
| So what you mean by "stable" is in the names only, but
| not in substance.
|
| What I mean by stable, is that my code remains working
| after I upgrade the dependencies, which is definitely NOT
| the case for python frameworks, but it is mostly the case
| for Clojure libraries.
|
| In Clojure, Web related things have remained relevant for
| a long time as well. For example, I do not anticipate
| that the standard things such as Ring, Reagent, Re-frame,
| etc. are going to change any time soon.
|
| If you have not used Clojure, you just have not
| experienced what a stable ecosystem looks like. You have
| too used to changing your own code just because of a
| dependency bump. This is very rare in the Clojure world,
| but a norm outside.
| krn wrote:
| Yes, these are two different meanings of "stable".
|
| In Clojure, "stable" means that your code remains working
| after the upgrades of its dependencies.
|
| In Python, "stable" means that the dependencies
| themselves remain upgraded.
|
| I am not suggesting that one thing is better than the
| other. What I meant, is that one thing is more
| _attractive_ than the other for an average developer.
|
| Currently, there are very few Clojure libraries from a
| decade ago that are still being actively maintained
| today.
| huahaiy wrote:
| Clojure itself is not much more than a decade years old.
| Even that, there are quite many libraries that have
| stayed all these year, e.g. the standard things I
| mentioned, such as Ring, Reagent, etc.
|
| As I have already mentioned, "actively maintained" is not
| a requirement for many Clojure libraries. Many are just
| done, as in "nothing needs to be changed".
|
| As long as they are still working, why do you want to
| update them? As I mentioned, many production code bases
| in Clojure contain libraries that have not been updated
| for ages, but they still work. Why fixing things that are
| not broken?
| casion wrote:
| > Community management is bad, even worse that RH nourishes
| this elitist aura around himself.
|
| That's a weird take, considering it's consistently called out
| as one of the most positive aspects of Clojure on surveys.
| wirrbel wrote:
| I assume this is on community management. I am not taking
| part in Clojure surveys so its fairly obvious to me why my
| opinion is not reflected in the community surveys.
|
| I got to admit that maybe community management might have
| improved in the last few years.
| weavejester wrote:
| What would a 'Clojure on Rails' framework look like? I think
| that's the primary reason why such a framework has yet to find
| traction; there's no single, obvious way to go about it.
|
| The efforts made so far in this space have taken many different
| approaches, because they're all experiments. Explorations of what
| an idiomatic Clojure web framework might potentially look like.
| Clojure has been around for over a decade now, and it's fairly
| mature as a language; but it's ideology is young in comparison to
| more established paradigms like OOP.
|
| To make matters more complex, Rails came to prominence in an era
| where web applications were mostly of one type: server-side HTML
| with a sprinkling of JavaScript. Nowadays there tends to be more
| options, e.g. a web application may consist of a single HTML
| shim, with a thick React client that talks to a GraphQL back end.
|
| So on the one hand we have a language that's still exploring its
| identity; on the other we have a rapidly changing idea of what a
| web application should be.
|
| My _guess_ is that an idiomatic Clojure web service would look
| like a client-accessible relational database with a strong
| security model and datalog queries, along with some system for
| adding in side-effectful hooks to respond to data change. In
| other words, something rather different in design to Rails.
| suprfnk wrote:
| Something like Phoenix? Elixir is a newer language, with a lot
| of similarities to Clojure. Phoenix even made the most loved
| web framework in the Stack Overflow 2022 survey.
|
| Why did they converge on something so, apparently, great, in
| such a low amount of time? And why is this so hard for Clojure?
|
| Not taking sides or trying to be negative, just honestly
| curious what the driving factor is.
| weavejester wrote:
| I haven't used Elixir enough to be particularly confident in
| an opinion about it. However, Phoenix _appears_ to have a
| similar design to many other MVC frameworks, and if a
| conventional design works for a language, there 's less need
| to experiment. Initial development can converge around
| something that's tried and tested.
|
| A conventional framework doesn't fit Clojure particularly
| well, so the community has been forced to tread new ground to
| figure out what works with the language.
| [deleted]
| [deleted]
| bcrosby95 wrote:
| Phoenix looks like rails because many people moved from
| ruby to elixir. Jose Valim was a part of the rails core
| team.
|
| At the core of Phoenix is independent libraries, macros,
| and a robust distributed design. It's just packaged in a
| familiar interface.
|
| Elixir would give Clojure a run for it's money when it
| comes to unique considerations.
| newlisp wrote:
| _along with some system for adding in side-effectful hooks to
| respond to data change_
|
| Curious, can you elaborate on what you mean by this?
| janetacarr wrote:
| Thanks for the reply James.
|
| I agree with everything you said.
|
| To clarify, I'm not advocating to re-create Rails for Clojure,
| rather, I'm arguing open-source efforts are too focused on the
| search for Clojure's Big Web Framework TM. However, I do like
| your guess as to what a Clojure Web service might look like.
| huahaiy wrote:
| Your observation is simply not true. To the contrary, the
| consensus of the community seems to be that there's no need
| for a rails-like framework for Clojure. Most of Clojurians
| are satisfied with what we have in the Web front, and are not
| worrying about the lack of "big Web framework" at all. I
| don't know where you got your impression from.
| bcrosby95 wrote:
| This is kinda like when go developers said the go community
| doesn't want generics. The people that really want these
| things will self select out of your community.
| janetacarr wrote:
| I got that impression from the relentless amount of web
| frameworks for Clojure that keep popping up. Anytime I see
| Clojure on the front page of HN, it's about some new
| Clojure web framework, so this post is a protest of that in
| a sense.
|
| The big web framework is an idea, one where people won't
| reinvent the wheel over and over again, so that we can have
| a lot more non-web packages for Clojure. I'm quite
| literally saying, the effort could be better spent
| elsewhere.
| seancorfield wrote:
| I must admit, I do not understand why (some) people seem
| to get so excited about the latest "Web Framework" for
| Clojure, over and over again.
|
| Yes, there seem to be a lot of them but they are mostly
| failures -- they rarely get any traction, and the
| creators often quickly move on (several to other tech
| altogether).
|
| I don't think those people would have directed their
| efforts into other things -- libraries -- to any degree
| that would mitigate some of the other points in your
| article. People tend to work on what interests them and
| if someone wants to design and build a web framework,
| persuading them not to isn't going to encourage them to
| work on a "more useful" library I suspect.
|
| I think the abandoned API library problem is real but
| partly because they were wrong-headed in the first place:
| Clojure is designed as a hosted language, specifically to
| take advantage of the vast, mature ecosystem that already
| exists on the JVM. When we got started with Clojure at
| work over a decade ago, it was common to see "all-
| Clojure" as a mindset and reject interop as a solution. I
| think that has changed a lot over the years and people
| now leverage interop and Java libraries as a "first
| solution" these days, perhaps with a thin wrapper around
| those libraries just to provide a more fluid, more
| functional approach.
|
| At work, we've certainly taken a conscious decision to
| switch away from "all-Clojure" where there are mature
| Java libraries that are reasonable to use via interop
| (unless, of course, the "all-Clojure" equivalent is very
| well-maintained and really adds a lot of value).
| huahaiy wrote:
| I don't think the HN mentions of Clojure is
| representative of what the Clojure community thinks. If
| you are talking about the frontpage of HN, it is even
| less representative.
|
| The Clojurians slack, Clojure Reddits and Clojurverse are
| more representative, and you can hardly see anything
| about Web frameworks in those places.
| avanai wrote:
| I think this article vastly undersells the value of Java(script)
| interop. The ability to call out to a well-maintained library in
| two of the most widely-used languages in the industry is one of
| the major selling points of Clojure as a pragmatic LISP, versus
| e.g. Racket or CL. The reason why there are so many half-baked
| wrappers around popular Java libraries is that it's reasonably
| trivial to write one yourself on demand, so that's what people
| do.
| waffletower wrote:
| Clojure libraries target microservices with a precision that no
| other language ecosystem has. In essence, Clojure web services
| developers rail against Rails and other bloated, unnecessarily
| complected (https://www.infoq.com/presentations/Simple-Made-
| Easy/) frameworks of the 90s. As a Clojurist I too rail against
| Rails. I don't think that expansive model fits the problem space.
| I have had painful experiences in the past maintaining Rails
| projects wondering why they didn't know of DRY. If there is a
| essence within Rails that you feel could be distilled into a lean
| Clojure model, build it out in a library and share it.
| janetacarr wrote:
| My central thesis seems to be getting lost here.
|
| I'm not advocating for a Clojure Rails because I love Rails.
| I've never used Rails to be honest. I'm arguing open-source
| efforts are repeatedly being spent on trying to build the next
| web framework/library/toolkit (Rails) for Clojure and not much
| else, so it would be great if there was one, so we can get on
| with filling the gaps in the Clojure ecosystem.
| huahaiy wrote:
| "open-source efforts are repeatedly being spent on trying to
| build the next web framework/library/toolkit (Rails) for
| Clojure and not much else", really?
|
| That's contrary to what most of us know. There are some
| efforts in the Web front, but not much. At least, the
| community is not paying much attention to these efforts.
|
| Let's look at the list of community funded projects, e.g.
| those in Clojure Together: the only Web related projects
| funded were clj-http in 2018, ring, re-frame and reagent in
| 2020. None of these are Web frameworks, and the rest of the
| funded projects are not Web related at all.
| aantix wrote:
| Keeping things DRY is about the discipline of the developer.
|
| It's nothing specific to the language or framework.
| ben_jones wrote:
| Im sorry I couldn't get past a hypothetical Org allowing a single
| developer to yolo-yeet bespoke languages, frameworks, tooling,
| into internal-critical-business-project after internal-critical-
| business-project.
|
| If your Org behaves like the above you could have the best Rails-
| Closure framework in the world but you're still destined for
| implosion.
| troutwine wrote:
| It's an interesting argument. However, I'm not sure about it.
| Consider Rust doesn't have a Rails per se but the ecosystem it is
| thriving. It seems more like an indication that the Clojure
| community of developers is either focused on things other than
| the article is concerned with, or its period of popularity has
| waned and the libraries that do exist from that time are slowly
| rotting. I think about Erlang before Elixir. In its niche Erlang
| had a very good set of libraries, primarily centered around lower
| level network communication type things. But for integration with
| popular APIs etc. not so much. After Elixir and an influx of new
| people the off-the-shelf library situation got significantly
| better. I don't think that's because they were doing Rails type
| things necessarily but more because there was a more diverse pool
| of developer community, whereas the Erlang community was slowly
| shrinking through attrition.
|
| If you want Clojure to thrive again you'll have to stop the
| attrition of its developer community. Maybe that's by building a
| Rails but even your example in-article where Go is more suitable
| isn't really a web type problem. What problems can Clojure solve
| that other languages can't, in a way that is worth the effort for
| someone new to the ecosystem?
| janetacarr wrote:
| I think you've answered you're own question here, in a sense.
|
| Erlang was created by Ericson for use in telecom systems. (OTP
| stands for Open Telecom Platform) which gives credence to the
| idea that Erlang didn't need a Rails. Once Elixir came along,
| being a bit more general purpose, people started building those
| things.
|
| Clojure, from the beginning, was intended to be a general
| purpose language, not a web language. So I think it would be
| fine to expect Clojure to be able to solve non-web type
| problems. Maybe the community has attrition, but I don't think
| so. The Clojurians slack seems bigger than it ever was, more
| companies are using Clojure than I've ever seen.
|
| edit: general not generate
| troutwine wrote:
| Minor quibble, OTP _used_ to stand for Open Telecom Platform
| but that acronym was removed in the push to open-source.
| Ericson had hoped to sell the Open Telecom Platform to other
| telecoms but that didn't work out, hence the modern
| Erlang/OTP. Anyhow, Erlang's niche was and is fault-tolerant
| middleware, yeah, the kind of thing you see deep in the
| bowels of systems. The community built up a sizable bulk of
| code to support the kind of middleware you'd find in
| Enterprise-y type places in the early 2000s and then slowly
| started to fall off, leaving an ecosystem that slowly bit-
| rotted in much the same way you describe in your article.
| That, specifically, is what I'm referring to as the off-the-
| shelf rot problem. Perhaps I could have been more clear.
|
| I agree with the argument that Clojure was intended to be a
| general purpose kind of language, but I think you article
| also suggests that -- unless you're tied to a JVM model _and_
| you refuse to use Java -- that Clojure gets out-competed by
| languages like Go in that kind of work. It's not clear to me
| how or why building a Rails kind of thing for Clojure would
| reverse this situation. I think, also, the size of an online
| community and tally of companies can be misleading. Erlang's
| IRC and company use was at an all-time high even while the
| actual pool of developers had reached its peak and was
| declining, slowly but surely. It's argument from analogy,
| sure, but what you're describing in the article for Clojure
| looks damn familiar from my time with Erlang, pre-Elixir.
| Macha wrote:
| I think the lack of a Rails or other flagship framework has
| arguably hurt Rust if you compare it's trajectory to that of
| Go. Go had Docker and Kubernetes as early flag bearers to
| indicate it's a "real language", while Rust has only really had
| the critical mass to start getting treated as one in the last
| two years.
| troutwine wrote:
| Ah yeah, very fair if we're talking "Rails" as a signifier of
| a big project that gives a language and ecosystem is
| "flavor". For what it's worth, I imagine Go has a broader
| remit than Rust even today. Go is a very good update on the
| pain points of Python for domains where integration with
| existing C libraries can be a little wonky, resource
| consumption isn't a major concern. Rust puts resource
| consumption and fitting into existing systems projects as a
| first class design concern, which is great for me because
| that's the kind of thing I work on, but I do admit it makes
| for a more challenging language to use.
| liveoneggs wrote:
| This comes up a lot and, I think, Laravel provides a great model
| for competing with rails. Stripe integration -
| https://laravel.com/docs/9.x/billing
| blain_the_train wrote:
| MVC don't help with strip payment integrations.
| georgeoliver wrote:
| >If we used interop for everything mundane, Clojure would really
| just be an S-expression shaped husk over Java code. Not a very
| good solution.
|
| IMO some programmers pursue purity (no pun intended) over
| pragmatism, at their own expense. I understand the appeal, it's
| like hand planing a board with your vintage No. 8 instead of
| sending it through the Powermatic.
| janetacarr wrote:
| I understand this. Contrary to what I wrote, I do use interop
| to get work done when I have to, but it's certainly not an
| inviting solution.
| seabird wrote:
| It's a lot more like buying a board planing robot cell,
| replacing the robot with a human operator because you couldn't
| get a teach pendant for it, replacing the automated part
| loading/unloading because you're now running parts that your
| fixtures can't handle, and ultimately replacing your low-cycle-
| time planer with a Powermatic because the vendor went under and
| you can't get any spare parts. Now you just have a Powermatic
| with a human operator and a distant memory of your initial
| machine.
|
| You (at least should be) picking oddball stuff like Clojure
| because the unique advantages outweigh the problems. If you're
| just using it as a wrapper over another language that doesn't
| provide those advantages, you're taking the balls off the bull,
| and you probably should have just used Java, C#, Go, etc.
| draw_down wrote:
___________________________________________________________________
(page generated 2022-07-30 23:00 UTC)