While I like Clojure as a language - I have never seen a language that engendered such hatred in PMs, EMs, sales, etc. I don't know that it survives long term (in industry, it'll survive for a long time as a hobby language.)
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).
My impression is that Clojure (and Lisps in general) are about maximizing the productivity of an individual where other languages try to maximize the productivity of an entire team. There are trade-offs to be made in either direction and much of what affects the feel of languages on either side of that comes from the choices they make around those trade-offs.
Clojure is really good at self-selecting for people that really care about innovation in programming languages. The other jobs in a tech company care about innovation in their domain. They rarely align.
So for every weird, cool innovation you see, the productivity is immediately lost because people equally care about how you deal with state on app startup, or routing, or database interaction. And since none of those other things move the needle much in how you compete in your business domain, competitors who are not concerned wind up eclipsing you. While you're arguing integrant vs. mount, people are just running dotnet new and bikeshedding over things closer to the business domain.
PMs/EMs/QAs/etc. may not have technical knowledge, but they smell something off about programmers arguing about what library to use for routing. Why didn't people complain about this at their past jobs? Surely if it was important, it would have come up. They just perceive you as having hired a bunch of senior people who are incredibly slow relative to their past companies. It really breeds resentment.
I have seen clojure-first companies creatively hive off parts of their engineering org to have a separate org that is allowed to use a different stack. They're not super transparent about it to avoid a big exodus of people, but I've personally seen it happen more than once.
> Clojure is really good at self-selecting for people that really care about innovation in programming languages. The other jobs in a tech company care about innovation in their domain. They rarely align.
To me it seems people typically like Clojure because of its simplicity, stability and productivity with the REPL. There are innovations in Clojure (its data structures, transducers...) but overall it is a pretty conservative and minimal language with laser focus on pragmatism.
Also in terms of slowness it seems the opposite is the case from my limited knowledge. OS authors and contributors seem to be extremely productive and creative. There are some notable Clojure shops (see: OP) that have been growing at an incredible pace.
Maybe I see this differently because I come from a [insert two very popular languages] background where everything breaks every couple of months and the culture is severely fad driven. To me Clojure is refreshing, calming and more powerful on top.
Sometimes with time SW based companies seem to migrate towards "easy to hire maintenance devs" style stuff once the products mature and slow down. It seems to happen to Ruby and Python projects too. But you might not have gotten it built in the first place if you started that way.
(Though I don't think Clojure is really "innovation in programming languages" stuff, it's a rather straightforward Lispy language and has changed much less than eg Java, C#, JS in the last 15 years, and is simpler too)
I like Clojure, but unfortunately for web development, there isn't a great stack and for data science/ML/AI (which is a great fit for clojure), python dominates the market. What is the niche for Clojure, or why should keep using it in 2023?
P.S: I like it a lot, but either I do golang or ror for web dev, or python/pytorch for data sciences/AI stuff, C# for game development. I don't think i can get more productive with Clojure in any scenario, that I'm exposed too, what I'm missing?
>Frontend development is simply awesome in ClojureScript
Is that still tied to that google closure abomination ? I've not been in CLJ ecosystem for >5 years now but last time I used CLJS I remember they went all in on google Closure and it was a major PITA to use the rest of JS ecosystem because of it.
Every time I use React I think how it would be great to use Clojure for that, but last time I tried the tooling overhead just killed it for me.
> Is that still tied to that google closure abomination ? I've not been in CLJ ecosystem for >5 years now but last time I used CLJS I remember they went all in on google Closure and it was a major PITA to use the rest of JS ecosystem because of it.
This has been solved now--there's a blessed CLJS solution[1][2] as well as a third-party compiler with NPM support[3] which many prefer.
Yes, ClojureScript is definitely on my learning list, we however decided to avoid one more transpilation tool, and accepted the fact that we have to write typescript.
> Give me Reagent + Shadow CLJS over plain React (or React Native) any day.
So that is for heavy js based applications, not for something light like rails + stimulus.js, right?
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!
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.
The choice is between Leiningen and deps.edn AKA the official Clojure CLI. Personally, I switched to deps.edn back in 2020 and haven't looked back. I like that it's simpler/does less out of the box and I also use the Git dependency feature all the time (you can reference a git sha as a dependency, not just Maven coordinates).
Something like 90% of it is just listing dependencies (the same packages as it's all just Maven anyway) and for the remaining 10% of configuration there's plenty of resources available for both. They can also interop to some extent.
Other ecosystems have it much worse than Clojure in this regard.
Boot died, sadly. There was some talk of a Boot 3.0 but it never materialized. I think deps.edn took all the steam out of it. Duplicated a lot of functionality and none of the esoteric-ness.
If you want a complete, integrated "stack" that stitches some of the most common libraries together in a uniform structure you might have a look at kit:
If you're coming to Kit from Luminus make sure you understand Kit's use of Integrant which involves passing `query-fn` down from the route to every function which accesses SQL. It was a deal-breaker for me.
I recently have been building a internal web app for managing customers and am super happy with shadow-cljs (develop/build) + reagent (view) + re-frame (state/events) + garden (css).
I especially like how easy shadow-cljs makes it to utilize both clojars and npm pacakges. I have been using JS/TS for a long time and feel like any webdev without npm packages would not be worth my time, especially for projects at work.
Re-frame has a very robust api for dealing with events, side effects, and state. Once I got used to the concepts in the documentation, very good docs but a little goofy, It has quickly become the most efficient and fun tool I have ever used to prototype complex frontend interfaces :)
Glad to be using cljs at work, but I'm not sure I would use this stack for non-internal tooling though.
> I like Clojure, but unfortunately for web development, there isn't a great stack
What do you feel is missing? Certainly there are options (something as frameworky as Fulcro, something as barebones as a React wrapper like Reagent), so there must be some itch you can't scratch?
Yeah, it's too heavy for some things, but it's situationally very awesome. Fulcro takes the fantasy of "reusable components" very seriously, more seriously than any other frontend framework I'm aware of, and designs from the ground up to allow for that. Be sure to go to #fulcro in the Clojurians slack with any questions/comments--it's a very friendly community in there.
