[sph]

Servers are 99% of the code I write, so yes I choose Elixir, though for very conservative clients and small projects I use Go.

For everything else, which is not a lot, there's Rust, Scheme, Lisp and many other fun languages to explore. My focus these days is on my business rather than consulting, so I have a lot of freedom.

[zelphirkalt]

How do you manage to convince employers of such language choices? (Do you need to convince?) And what kind of jobs or positions are that? I would love to use my skills like that, instead of building CRUD in Python, not really being able to apply my skillset, but employers are not ready to make the smallest leap it seems.

[cess11]

I've convinced the CEO that Elixir/BEAM/OTP is a good choice for a fairly large, multi-application project. It wasn't very hard, factors like high availability, the same programming language and runtime in the entire system, extremely fast prototyping, battle tested in absurdly demanding settings, sounds very nice to a business strategist able to understand at least some of the implications.

The drawbacks are basically in recruiting and a few other areas and quite manageable.

Edit: There's a book for this particular purpose, convincing the suits, https://pragprog.com/titles/tvmelixir/adopting-elixir/ .

[zelphirkalt]

Recruiting was exactly the one argument that I got to hear. That hiring people would be difficult and people demanding high wages and so on. I could not convince an employer to not weigh that heavily. At least that is the brought forward argument. There might also be an element of "don't know it myself, don't want it in my company".

[toast0]

I worked at WhatsApp, one of the big Erlang users, almost none of our server team knew Erlang before joining, including me. Until we hired someone who actually used it before, I was the most knowledgeable pre-hire, because I remember seeing a post about it when Erlang open sourced it.

Yes, we probably could have done some things better if we had a bit more Erlang experience on our team; at least while I was there, none of our applications were properly packaged as OTP applications, and maybe that could have been useful. But overall, we were smart, experienced server people who were willing to learn Erlang and we were handed a tool that fit our needs very well, so we all got Erlang books and figured it out. If you can recruit smart, experienced server people who are willing to learn a new language, you don't have a recruiting problem. I haven't personally worked with Elixir, but I feel like most of the unfamiliarity is going to come from the underlying BEAM and OTP, so same difference; Elixir just has different syntax and macros are more heavily used, IMHO both syntaxes are going to be unfamiliar to most.

[zelphirkalt]

That is exactly what I think. If you got decent and educated developers, they should be up to speed fairly quickly. But management layers often have no trust at all, even if it would take maybe merely 2 weeks to be able to do basic implementations in a new language and ecosystem. Basically it means, that we cannot possibly spend 2 weeks becoming better engineers, but we can spend infinite time on wrangling with lesser tools.

I would love the chance to learn more Erlang (looked at the beginning of "Learn you some Erlang for great Good") or Elixir (used in last year's AoC) on a job and get to use OTP, watch it run my function calls on multiple machines and all that. I know a lot about functional programming, as I do it in my free time (big Scheme fan).

As it is currently, I cannot apply my skills at the job. For example when I think that some code should not mutate some state, but rather use pure functions and the tests should be simply function calls and checking the output, then I don't get the time to do that, nor the time to show how this would look like and how it would make things simpler. No one aside me on the job seems to be interested in purely functional data structures/persistent data structures either, which sooner or later are necessary, if one wants to make things purely functional. So basically I am the only person with that knowledge and cannot apply it. It is so dull.

[cess11]

That'll be my approach, together with knowing some people that know some people who would probably enjoy finally getting to use the BEAM in prod we're betting that clever candidates that find our business interesting will also have an easy time learning this specific tooling.

It takes a bit of getting used to pattern matching and the overall functional/declarative approach when coming from a more imperative background, but I believe learning the ins and outs of the business niche will generally be harder and take more time.

In some companies handling recruitment issues isn't enough, investors or shareholders might be worried about 'exit' and how to maximise it for themselves, and refuse tooling they perceive as obscure and expect to lower bids to buy them out.