[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.