[TacticalCoder]

Weirdly enough I do believe Clojure ticks the boxes from that checklist.

It's familiar in that it both "supports popular language runtimes" (runs on top of the JVM or transpiles to JavaScript) and it's a Lisp dialect (or close enough) and Lisps have been around since a very long time.

It's incredibly stable: so stable some libraries commonly used haven't been updated in years. There's also very little code churn inside Clojure's own codebase.

It is very reliable.

It's limits and trade offs are well known.

Somehow I though my language of choice was "edgy" but I realize it may actually be "boring": a dialect from a very old family of language running on top of a boring tech (the JVM).

[lacker]

I like Clojure, but it's really the exact opposite of the sort of "boring technology" that this post advocates. If MongoDB costs you 2 innovation tokens, Clojure costs at least 2, perhaps all 3.

The cost of innovation is not so much in the core of Clojure itself, but that once your company gets larger, you will want to integrate with more and more things that have not put effort into Clojure compatibility, just because the language is not very popular. Also hiring.

[jayceedenton]

What is this 'Clojure compatibility' of which you speak? Seriously though, Clojure runs on the JVM so the entire Java ecosystem is available. There are ways to run an external process too of course. I can't really think of an example where 'Clojure compatibility' is something we would require people to have thought about.

[lacker]

A simple example is, let's say you're making a small web service. Are you going to use a Clojure framework or a Java framework via JVM compatibility? If you pick a Clojure framework, then all the subsequent choices you have to make, you'll run into the "non boring tech" issues. Has someone already built a GraphQL plugin, a plugin that integrates with the Twitter preview API, etc etc it depends on your project but you'll run into things. If you pick a Java framework, you'll end up running into a bunch of cases where you can't use the "normal solution" for that framework because you're running Clojure.

It's not the end of the world or anything, and for a smaller project Clojure might be the perfect solution. But if it's something that you're trying to scale into a startup with dozens of engineers then you're probably going to pay a higher incompatibility cost for using Clojure.

[Scarbutt]

you will want to integrate with more and more things that have not put effort into Clojure compatibility

The answer to that is to just use java interop.

[throwaway1777]

Or even to have some clojure services and some Java ones. And then work toward more clojure over time if there’s good reason to do it.

[smackeyacky]

And the rebuttal is just use Java as it requires less integration.

[lmilcin]

The problem with Clojure is that it is too good. It gives you, the programmer, too much freedom.

Most people do not have problems that require so much freedom.

Most people do not know what to do with that freedom -- they don't have enough experience actually organising their applications.

Most people benefit from using a language/framework that requires them or at least rewards them to put things in a certain way. For example Java Spring rewards people for following a certain application design -- you can break rules but then you are on your own and Stack[Exchange|Overflow] examples can no longer be copied/pasted directly into your codebase.

As much as I love Clojure, every single corporate Clojure project I have seen in the past was an utterly unmaintainable mess.

I have never actually participated in a Clojure project (I use Clojure mostly for rapid prototyping/PoC-ing), but what I figured is that Clojure requires minimum maturity from the developer and especially drive to be constantly simplifying things -- which is unfortunately very high bar. Most developers I work with / interviewed do not really understand what it means to refactor and simplify. Most people are only focused on the part of the work when they get something to produce expected values and everything else just isn't high priority in a corporate environment.

[Cthulhu_]

How about hiring though? If you have a vacancy for a Clojure developer, how many applicants could you expect?

When it comes to programming languages, I'd stick to the top 10 languages if your company isn't hip enough to attract a certain kind of developer on its own.

[olieidel]

When hiring / recruiting Clojure devs, there are quite a few second-order effects which are quite unintuitive.

Clojure devs are much more senior - they've typically been burnt by at least one tech stack, often more (Java, JS + React, Fortran, Cobol, punching tape, etc.). Clojure devs also tend to be really passionate about, you guessed it, Clojure, which commonly turns out to be a good thing. People passionate about that level of language-detail tend to be meticulous about many other useful things, like choosing the right tools and building simple and maintainable applications.

There's sometimes a slight tendency towards over-engineering which is understandable. People who dive deep into other programming languages and go through the pain of learning lisp sometimes tend to lose focus of the actual (business) problem to solve. But I wouldn't say this tendency is significantly higher than elsewhere. Still, sometimes, the pragmatism of a rails dev just churning out code is missed.

Also, because Clojure jobs are scarce and there's a high number of "secret Clojurists" (people who code Clojure at night and secretly dream of using it at their day job), you actually get a much higher number of applicants than you would have estimated based on the most recent Stackoverflow survey.

Also, you get a real shot at hiring rockstar devs. This is huge and cannot be overstated. If you're hiring for a standard JS / Python stack, you're suddenly competing with FAANG companies and their salaries. If you're hiring for Clojure, you're hardly competing with anyone. And you get a good pre-selection of senior devs. Like, those which were burned at a FAANG company, who finally came to their senses and now want to code Clojure. What's not to like?

I guess a drawback would be that you couldn't instantly hire a local team of 100+ devs, even if you take secret Clojurists into account. But who would want to work at a place which hires 100+ devs in a short amount of time?

(I interviewed around 200 people, many of them for Clojure roles, sometimes even comparing Python and Clojure applicants for the same role)

Relevant talk: https://youtu.be/kNiGu_VaoTg?t=1566

[clusterhacks]

"because Clojure jobs are scarce . . . you actually get a much higher number of applicants <and> you get a real shot at hiring rockstar devs"

I have felt this to be true for many years. I was an early Clojure adopter, deployed Clojure apps into production shortly after attending the very first Clojure/conj, and did quite a bit of hackerrank and similar competitive programming exercises with Clojure for fun and learning.

I didn't have much luck getting job offers for Clojure positions but was mostly successful in getting job offers for other tech stacks during that same time. It was kind of funny to me - I really wanted to move to a Clojure-only shop but kept getting offers for SQL and Java/C# positions despite not really being an enterprise dev type.

[dwohnitmok]

All the points you're saying here are the usual arguments for choosing non-boring technology (I think I've seen this argument essentially verbatim for CL, Haskell, Clojure, Elixir, etc.), which is fine in isolation, but doesn't really fit in a thread about Clojure as boring technology.

[gregors]

From what I heard, Nubank hired a good deal of Elixir developers when they aqui-hired Plataformatec. I suspect having functional programming experience matters more than having concrete Clojure knowledge. It definitely didn't seem to be a problem in this case anyway.

https://medium.com/building-nubank/tech-perspectives-behind-...

[exdsq]

On the other hand you attract a certain kind of developer with those roles than generic languages.

[Steltek]

If you're using your tech stack as a hiring filter, it doesn't count as "Boring Technology".

[exdsq]

No I appreciate that - my point is you can get better engineers that you might deserve at your startup by using a language like Clojure to entice them. I know people who work for a good discount if it’s on a tech stack they enjoy and is fairly rare to find.

[radiator]

It almost sounds like you don't believe that developers can learn new languages.

[whakim]

Of course people can learn new languages, but:

- A nonzero number of excellent potential applicants aren't going to work for your company because they don't want to invest their own development into learning the Clojure ecosystem deeply. (This might be somewhat balanced out by folks who are stoked to learn Clojure.)

- Every non-Clojure person you hire will require significantly more ramp-up time. This can be a real problem for small companies where you lose quite a lot of expertise every time a senior developer leaves.

- These problems compound for every "innovative" technology you add.

[pjmlp]

Learning a language is a piece of cake, learning the ecosystem is another matter.

[discreteevent]

Of course they can learn new languages. But it takes some time to become really proficient in a language. The question is how many languages do you want to support in your company? Because it's not realistic to think that developers will not need to move from project to project. And in fact when things get busy they may need to swap from one project to another and back on the same day. It's not ideal but that's life. The inefficiency of swapping between languages will often outweigh the efficiency of the new language.

Google were notoriously strict for limiting languages at the start and I think it was very frustrating for some of the developers they hired. If I had a boring technology checklist then "Language we already use" would be top of the list.

[bsza]

If it’s a language I’m not familiar with, I won’t consider applying, so that’s where the story ends in my case. I could be an outlier though…?

[Scarbutt]

The majority of companies want you to be productive on day one.

[exhaze]

That's pretty hyperbolic and also seemingly irrelevant. There are enough companies that don't have this expectation and give new engineers the time and space to become familiar with the company before setting any concrete performance goals.

[ithrow]

Hiring wasn't in the articles' checklist though ;)

Valid point anyway

[dchest]

Hiring more developers is overrated.

[pjmlp]

Nope, boring technology is using the platform system language, Java.

Nothing extra to install, everything works out of the box, no need for FFI or incomprehensible stack traces.

[forgetfulness]

Clojure doesn't need FFI, neither does it need anything to run but the JVM, you package your application in a jar and run it the same as always, and you only write Java using your system editor and the JDK in introductory compsci courses.

[pjmlp]

It surely does, calls go both ways, and Closure doesn't understand everything introduced on the JVM since Java 8.

Poor students, at least Blue/J.

By the way, I already used Clojure in projects.

Usually I only critic stuff I actually know.

[chakkepolja]

> you only write Java using your system editor and the JDK in introductory compsci courses.

Even universities in India use IntelliJ or Eclipse these days.

[darksaints]

I'd agree that clojure fits the boring tag, and that's a good thing. Unfortunately it's also dying. While many old libraries and tools are stable and functional, nothing new is really being created with it. The same couldn't be said for boring technologies like Java or Python.

[gregors]

Being acquired by a bank isn't exactly a bad thing for the language from a longevity perspective.

https://www.cognitect.com/blog/2020/07/23/Cognitect-Joins-Nu...

[twobitshifter]

What about clojurescript?

[bachmeier]

My rule of thumb when someone says "Language X is dying" is to move on. I don't even use Clojure, and I can immediately come up with https://github.com/logseq/logseq and https://github.com/athensresearch/athens as funded companies making popular new products with Clojure.