Ask HN: Who regrets choosing Elixir?
TL;DNR, use a language your company can support.  It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on?  How do you support it?  Who's on call?<p>Not Elixir, but a cautionary tale from our Erlang project.  ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handle all the symmetric sessions, etc.  It was a good tool for the job and in theory could scale well.<p>But, there's always a but.  We're a Python shop on the backend and C on embedded devices.  Engineers move on, there some lean times, and after a few years there was no one left who could support an Erlang system.  So we hired for the position, and it's key infrastructure, but not really a full time project, so we hired a Python+Erland person.<p>But! Now they're on call 24/7 since the regular on call roster are python people and when the Erlang service goes wrong, it's call the one engineer.  So, do you hire 2 or 3 people to support the service?  No, you design it out. At the time is was 2018, and IoT services were a plenty, so we could use an existing service and python.<p>Another way of looking at it, let's say it's a critical service and you need at least 3 people to support it/be on call.  If each engineer costs $200k/year, that's $600k/year. Does this new language save you that much over using a more generic and widly known language in the org?