Clojure Turns 15 panel discussion video

The cljs stack I hear about a lot (and use) is ShadowCLJS with reagent (https://reagent-project.github.io/) and re-frame (https://day8.github.io/re-frame/). ShadowCLJS is more of a build tool, but is really well documented and easy to use. Reagent is basically react but a simpler API, and re-frame is a layer on top of that kinda like redux. It's overkill for some apps but I find it's actually super easy to work with and not as much complexity as I thought.

For backend there is luminus (https://luminusweb.com/) or Kit (https://kit-clj.github.io/). They are basically project templates that wire together a ton of popular solutions for various things - database access, migrations, security, html templating, etc. Also includes frontend frameworks like re-frame if you want.

edit: forgot to mention fulcro (https://fulcro.fulcrologic.com/) which is an interesting full stack solution. I haven't used it though so can't comment, but it sure seems documented well!

This is a reasonable comment, even as a Clojure fan, I think this fits with how the community thinks of itself to some extent. I can't provide a specific citation but I know there is at least one talk (maybe Simple Made Easy but don't quote me lol) where Rich Hickey talks about the fact that one reason "easy" tools -- which in his view provide fast uptake but more problems down the line due to being "complected" in how they deal with various concerns of the underlying problem -- are so popular is that people who manage programmers (like some of the positions you mentioned) want to be able to easily put butts in chairs, to readily replace engineers like they are cogs in a machine, so they are very willing to make this trade of short term ease for long term pain because less training is required to get to a near term deliverable.

It's also clear (see Hickey talk Effective Programs, 10 Years of Clojure, where he surveys the room) that Clojure programmers tend to be senior (real senior not 5 years experience "senior") and a little grumpy about the state of the art, opinionated, and don't want to be cogs. This may also explain the allergic reaction among people who manage programmers/engineers. Managers as a rule (especially at certain orgs) tend to want people who are more compliant and less free thinking and likely to push back.

Anyway I think you make a good point except I disagree about its survival long term. I think there's something to be said about the value of being more popular among older more seasoned programmers vs PMs. How many PMs in the 90s foresaw the rise of Linux (vs proprietary unix and Windows), how many go overboard on "agile", how many were into ruby on rails before it picked up among programmers, etc. Managers tend to be a lagging indicator (speaking very broadly).

Been using Clojure professionally for 9+ years now and while I'm thankful that I can make a living writing the language and using Emacs all day, I've found these points to be spot on.

These issues have added noise/confusion to what used to be a much simpler ramp-up for new developers. For those who've been around for awhile, the overall experience definitely felt cleaner previously, with more obvious best paths. While it's hard to argue against more options, the effect on the ground is that it's also needlessly divided the already small community a bit too.

Clojure user here since 2010(my earliest Clojure project on Github), and while I agree with the fun point, the iceberg wart for me at this point is the inelegance of the interface hierarchy and its structure behind the scenes.

Clojure's forward-facing interface (a hundred functions that operate on one data structure) ended up breaking down for me at some point and became 10 functions on 10 data structures and those data structures became AFn, APersistentSet, APersistentMap, APersistentVector, IFn, IPersistentSet, IPersistentMap, IPersistentVector, ITransientMap, ITransientVector, IndexedSeq, LazySeq, &c, &c, &c.

Maybe I started writing code wrong. Maybe I dived too deep into the internals, Maybe it was something else. But at the end, there wasn't one data structure, there were dozens and dozens each with justifiable differences, but even so, that's not what was advertised. It took a decade to reach that point and perhaps the vast majority of folks never will.

The sad part is that I know none of it is up for change without creating a Clojure2, and that highlights the problem. Why should changing the internals need to break backwards compatibility? There is one unspeakable reason: the illusion wasn't complete and they weren't really internals to begin with.

Thank you. What about leiningen vs boot vs deps.edn? Did any of this come ahead as a winner in the recent years? It's been a while since I've looked into this.