> But are language enthusiasts really better hires in general? I've known many of them who loved the theory and toying with a language but were not any better at producing actual value than the average joe.

I think they may be safer hires, anyway. They will be able to program themselves out of a wet cardboard box, which is more than you can say about the average Joe who may just be good at bluffing the interview.

Provided you dangle enough money and have a good interview process you can easily cull those people who can't code themselves out of a wet paper bag.

The thing that would worry me about niche languages is the amount of wheel reinvention you'd have to do. Not sure the cost/benefit calculation starts to look so great any more when you realize that your enthused elm developers will have to build a whole lot of stuff that you can just import in other languages.

Most niche languages have an FFI escape hatch for when you really need a library and don't want to re-invent a wheel. Elm, Purescript, Bucklescript, and ghcjs can all interoperate with javascript; Scala and Clojure work with most (all?) native java libraries; F# has access to most (all?) .NET libraries. Haskell, Idris, ATS, Erlang, and SBCL Common Lisp all allow you to access native system libraries.

FFIs can have warts, but in the general case library support isn't the obstacle people make it out to be.

I don't agree. I find that the impedance mismatch of an FFI is an incredibly fertile breeding ground for nasty and obscure bugs and deployment problems.

> Provided you dangle enough money and have a good interview process you can easily cull those people who can't code themselves out of a wet paper bag

Interviewing costs money—good tech interviewing particularly so. The less of the people you have applying to start with, the more money you save on culling then by way of tech interviews.

Not sure how Elm interacts with Javascript libraries, but JVM languages can generally use any existing Java libraries. So a language built on a popular run time (JVM, .Net VM, guess there's exactly two), can still have excellent library support.

...or Node.js nowadays, so three, I guess.

Elm nicely abstracts over JS interoperability with a mechanism called ports: https://guide.elm-lang.org/interop/javascript.html

True, I'd much rather someone who spends their time learning Elm than Cracking The Code Interview.

Aren't you just as likely to get people who excel at hyping and hello-worlding new languages but can't actually make applications? Or people who just read the python paradox (with python scribbled out and Elm written over it) who think they can look like a great developer who understands the value of Elm but really don't?

You'll get those, yes. I know because I was one of them... But I think you unerestimate how bad the average interviewee can be.

Someone who hello worlds new languages may not know the syntax or idioms to write fizzbuzz in any specific language, but they will be able to characterise the rough shape of the problem, and not just sit in silence...

> bluffing the interview

"bluffer overflow vulnerability". :)

I have noticed a lot of language / framework collectors where every new project is in a new framework or language on their CV. While it will expose you to a lot of different ideas I doubt you will code very well in any of them if you are swapping every year. I have seen plenty of Python written like its Java and its just less elegant code. And Django code that doesn't follow best practices seems to be the norm. If you take the time to master a few things you can produce some quite elegant solutions. If you only know the basics, you reinvent the wheel in a crappy way usually.

The best ideas are those that you can share between languages. When you get hung up on idioms, or when you recreate idioms that don't matter in another language, that's where the problems are. Exposure to a lot of languages allow a person to figure out that union of computation that benefits all languages.

Like I say when I see python written in a Java style its verbose, and doesn't take advantage of much of the expressive syntax that Python provides over Java. You have given up the speed benefit of Java and have kept code that is nearly as verbose.

And don't get me started on the way people misuse Django.

Python written like Java would be a huge improvement over what most people produce.

I don't think so. I've seen Java written like Java.

In my experience they're quite correlated (but not 100%). It seems to be a strong signal for passion about development, which I'd say is important for hiring someone who really cares about doing their job well (which I also find is an important and rare attribute in a good dev).

That's what a good manager is for, they're there to turn a powerful engine into a productive one.

I think this depends on what you mean by “actual value”. A working product powered by a tangled yarn of hastily-assembled spaghetticode has a highly dubious long-term value, and what’s worse, your “average-Joe” coders might not even realize/see the value of what that “one overly-careful coder” brings to the table

They're a great way to seed your recruiting pipeline. Enough of them ought to be good hires to make this useful. After that, you just have to trust your hiring process, just like you would for any other source of candidates.