I am really happy with how my talk from Scala Days turned out! Outlines a strategy for answering the boss’s question of “how will I hire for Elm?” in a persuasive way.
I think this ended up being a more compelling way to present the Elm case studies I gathered a while back.
It was interesting to hear about the different hiring approaches. I know my current employer, Jump, takes the mixed approach. We use almost entirely Elixir and we’ve hired both because someone is well versed in Elixir and those without any prior Elixir experience (such as myself, I don’t count doing Hello World as actual experience). I’m not entirely sure what the challenges have been with hiring, but I haven’t heard about a lack of applicants.
Thanks for the talk! I thought I’d share my experience if it’s helpful.
In my company, we exist as a little “software shop” inside a larger mechanical engineering organization, so we have the advantage of more self-directed software choices unless we need to interoperate with legacy systems, but that’s mostly a backend thing. We’re used to hiring developers not used to writing in the languages they have to work with. (VB6, Fortran - we’re trying to get rid of both!)
We first started using Elm as a trial for a new in-house web-based tool. My gauge for whether Elm was a viable language for our project was whether our intern could pick it up, and it was successful. We’ve used it for another “new” project as well.
Our interns are usually students at our local university and are in the same computer science program I attended, where functional languages aren’t taught as a “main” language, but where our programming languages course has a pretty heavy focus on them, including a little Haskell.
We’ve had a slightly harder time onboarding a different intern and other full-time developers coming from a C# background. They often get stuff done, but “thinking functionally” is the challenge - in particular the immutability often leads to a lot of extraneous copies where other idioms do well, but those have been coachable. I think the biggest challenge we face is data modeling; some problems just “go away” if you represent your state right. In C# it’s too easy to just add another field where an ADT would do better.
Another difficulty is despite the compiler being very nice, lots of people don’t interact with it directly and look for “red squiggles” in VS Code, which are more difficult to parse when you’re used to a one-line error. The state of the tooling for VS Code isn’t as good as we’re used to; for instance, a fresh pull of https://github.com/elm/elm-lang.org/ compiles fine but VS Code displays lots of errors.
I think the biggest hurdle was having to skirt around how long it’s been since an official compiler release. I’m happy with the language and the stability of it (though I have at least one suggestion 
), but the “is it maintained?” question did come up. Still, we’ve felt productive and seen the benefit using Elm as developers and will continue.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.