I've heard more than one story of investors pushing to not use Clojure, or move away from Clojure, presumably for exactly this reason. They prefer technologies with a large pool of available developers, lots of reusable off-the-shelf components, lower degree of expertise required. I personally think it's a good thing Clojure does not fit in this list. We're not participating in this race to the bottom. Companies pick Clojure because they see the benefit of the language, and understand that they will be able to find enough people to hire, generally with some experience, or at least a good dose of intellectual curiosity. I was listening to an interview with one of the Nubank founders yesterday, and he said most people they hired did not yet know Clojure, but that the prospect of having to learn Clojure already served as a pretty good filter for candidates. But it does help clarify what to expect of Clojure. There's been a lot of talk about growth the last few years. I do think it would be helpful if Clojure could get a bit bigger. But it will never be the technology of choice for a big class of companies, because it's not in the business of suppressing developer wages. Instead it's in the business of getting more value out of your (fairly compensated) developers. It lets you ship quality software at a decent pace with a comparatively small team. Maybe that's a story that we need to tell better.

A company choosing Clojure can also be a filter for companies (from the dev's perspective), in that it signals a reduced possibility that the shop is run by bean-counters.

A company choosing Clojure is a signal to bean-counters to stay away from it :thinking_face:

Thanks for articulating these concerns. > it will never be the technology of choice for a big class of companies, because it's not in the business of suppressing developer wages. Instead it's in the business of getting more value out of your (fairly compensated) developers I suspect it might even be worse than that. Using a tool that helps techies deliver more with less is a competitive advantage (and can really help getting more money faster in the pocket of stackholders, even leaving more to devs, everyone wins), but this can't be seen at all by a large population of so-called managers which see hand-on contributions as a second class activity (contrasted to what they call leadership) which has to be delegated to second class contributors which are seen as disposable cogs, not actually performing a rather challenging intellectual/creative activity (which software development is). Being all cogs more or less equal (in their eyes, not ours for sure) why even bothering with those niche ones which seem to cause all this friction with their learning curve, different jargon and reduced pool of exploitable cogs? There are also other factors, the other big one being (IMHO): complexity feeds itself (see also https://en.wikipedia.org/wiki/Parkinson%27s_law). Speaking simplicity to a complexity addicted mind reminds me of the old times at middle school, ancient times when it was possible to stumble on teachers preaching how typewriters are better than computers. I'm sure there's always room to become more persuasive and convincing (both myself and the wider clojurians community as a whole) but there's no way around a learning challenge without giving it a serious, non trivial go.

I think the article is about as wrong about things as something could possibly be.

Oh yeah? You disagree with the notion that certain technologies are popular because they make people easily replacable?

I most certainly do.

Ok 🙂

Us vs them is such a bad perspective on things.

I'm on both sides of that equation so I don't think that's how I would phrase it. I do try to understand market forces, and how investors and executives are talking and thinking about these things, since that is a world I (we) need to navigate.

Anecdotally I've had multiple Clojure jobs that leadership was pushing the language out and they explicitly said it was to have a wider and cheaper hiring pool

My understanding of proglang history is that Java and successor languages (including but not limited to Dart) were designed and popularized specifically to make people replaceable in large companies. And to your point John, I've seen a similar phenomenon around SQL/Datalog and JSON/EDN. It's a completely understandable urge and even correct in certain contexts; it's when it runs unchecked that it causes problems.

See also: golang

> Not in the business of suppressing wages > Ironic as a savvy business owner would rather pay 2x to two clojure devs over a team of ten $Language devs

having more, actual power over a larger pool of people trumps both math&money I guess

The big elephant in the room is a concept called Managerialism. Choices aren't even aimed at maximizing utility for the organizational, but for making life easy for mid management and for them to hit short term goals

This also overlaps with the principal-agent problem

The same logic applies to Clojure shops in the small, btw. Everyone should be using Electric and or Rama right now. Resistance is purely a function of middle management. Top management is happy with whatever gets them results

Wow, @U0ETXRFEW, thanks for this answer. I honestly read the article, and I agree with you... but because I've been disagreeing with some posts in a row, I was afraid to say 😄

As for the article itself, I don't know how to discuss it. For me, it sounds like the author though about the conclusion, and then back-tracked to explaining why things are the way they so that it fits with the conclusion. Maybe only the "Rails" and "Django" part is the one that I actually agree, honestly...

The "Electron vs Tauri" is a feat on itself. When he mentions react-native, I feel like I'm reading about someone arguing why Aliens from Venus will save us from the impeding doom that's a mass of corrosive material that will destroy the Earth in the next ten years - it's such a weird take that I don't even know how to counter...

(I also disagree about "everybody should be using Electric or Rama", too)

> it sounds like the author though about the conclusion, and then back-tracked to explaining why things are the way they so that it fits with the conclusion That sounds like all opinion pieces

I kind of wish that the author's backtracking hadn't led with labor arbitrage being the cause of tool popularity. He has to add all these caveats to make a weak side point, while the idea of "companies want interchangeable cogs" stands fine on its own.

I don't agree, actually. In this article, it sounds like he decided that NodeJS exists because people want to sell more expensive SSDs, even though this correlation doesn't exist. For example, this part about React: > helps them erase the various specialities – CSS, accessibility But... it doesn't. It actually doesn't

I think even "companies want interchangeable cogs" is an over generalization. It's local immediate incentives that lead to this emergent behavior

React have nothing to do with CSS or accessibility. There's nothing in React that eases CSS, for example. Even other tools, like Tailwind, still don't help with layouts - you still needs to understand how CSS will actually behave on the browser...

> I think even "companies want interchangeable cogs" is an over generalization. I wrote that and yes, is 100% a generalisation/approximation (more likely to be correct for massively large corporations, less so for smaller ones), as the take of the article is generic. Never intended to attempt an overall in-depth nuanced analysis in the context of a rather quick slack chat (that would be a thesis and I don't plan to attempt one today).

I loved the author's unusual take and hard-hitting writing style. It's a theory, as made clear in the beginning of the article. We need theories to explain reality: technological trends, outsourced labor, VC funding, the complex tangled mess of our economy. Whether or not collective bargaining would address the spread of dumbed-down software and deskilled workers remains to be seen. The author rushes through the argument (as others pointed out earlier in this thread), and urges us to read a book instead. Fine. As for looking at Clojure through this lens, I think the author would argue that no matter how well we tell our story, nobody takes note by design. Glum, I know.

disclaimer: I didn’t read article, because I am busy right now, so I shouldn’t reply, but I read a few comments, so just wanted to add this: • I know mid size company in Poland which made decision to stop coding in Clojure, because they can’t find developers in Poland. • I know big corporation in US switching from Clojure to Rust. Besides of rationale for choosing tech, this will let them cut cost of 1000 servers. The main big reason why Clojure is so great during developing is REPL which let experimenting on running system. It speed up things. Everything else doesn’t matter as much vs other good languages. My private opinion. Not a long time ago I put myself mentally in position what I would do if have to make a project and hire developers. The assumption was I can’t code myself, only hire people. Would I choose Clojure, living in Poland or maybe even EU? Probably not. In US? Make more sense. Java was made to run apps in all systems. I am not expert about Rust, but it can compile to each system and also build Wasm to run virtual things. New solutions pop up and get faster growing community.

I would also say “Clojure developers are more experienced” is a myth. It was probably true on the beginning (5 years ago?), but not today anymore. Today we have variety of experience as software developer.

From people do really bad code to people who do highest quality code.