Hacker News Reader

Comment by crdoconnor | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com