<story><title>Ask HN: Who regrets choosing Elixir?</title><text>I’ve seen a few Elixir success stories posted here recently. Virtually all comments are from raving fans that have nothing but the best to say about Elixir.&lt;p&gt;As someone with primarily a Ruby &amp;#x2F; Rails background, I’m choosing a language for a new API project and considering Elixir. I’m interested in hearing some counterpoints to Elixir, especially in how a smaller ecosystem Of 3rd party libraries slowed down development.</text></story><parent_chain><item><author>carapace</author><text>This, twice.&lt;p&gt;Back in the day people would balk at hiring Python programmers saying, &amp;quot;there are so many more Java programmers&amp;quot;, and I used to say, &amp;quot;Why would you hire a Java programmer who was unwilling or unable to learn Python?&amp;quot;&lt;p&gt;Same logic applies here: Why would you hire a Python programmer who was unwilling or unable to learn Erlang?  (Especially if you&amp;#x27;re going to &lt;i&gt;pay&lt;/i&gt; them to do it!)&lt;p&gt;If you can&amp;#x27;t switch languages you&amp;#x27;re a kind of &lt;i&gt;technician&lt;/i&gt; not a programmer.&lt;p&gt;FWIW, having done it professionally for ~15 years I&amp;#x27;ll never write another large project in Python again.  Erlang&amp;#x27;s runtime is so much better than Python&amp;#x27;s it&amp;#x27;s just ridiculous.  I feel stupid for not realizing this sooner.</text></item><item><author>craigsmansion</author><text>&amp;gt; there was no one left who could support an Erlang system.&lt;p&gt;If you have $200k &amp;quot;python engineers&amp;quot; on the payroll who wouldn&amp;#x27;t jump at the opportunity to do some additional Erlang, maybe it&amp;#x27;s time to reconsider your hiring practices and that is the real cautionary tale.</text></item><item><author>as-j</author><text>TL;DNR, use a language your company can support.  It doesn&amp;#x27;t matter how suited to the job a language is, if it&amp;#x27;s single Engineer or small team, what happens when they move on?  How do you support it?  Who&amp;#x27;s on call?&lt;p&gt;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.&lt;p&gt;But, there&amp;#x27;s always a but.  We&amp;#x27;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&amp;#x27;s key infrastructure, but not really a full time project, so we hired a Python+Erland person.&lt;p&gt;But! Now they&amp;#x27;re on call 24&amp;#x2F;7 since the regular on call roster are python people and when the Erlang service goes wrong, it&amp;#x27;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.&lt;p&gt;Another way of looking at it, let&amp;#x27;s say it&amp;#x27;s a critical service and you need at least 3 people to support it&amp;#x2F;be on call.  If each engineer costs $200k&amp;#x2F;year, that&amp;#x27;s $600k&amp;#x2F;year. Does this new language save you that much over using a more generic and widly known language in the org?</text></item></parent_chain><comment><author>icedchai</author><text>If I had a Python job (a language I enjoy) and I was forced to work in a language I don&amp;#x27;t (say, Perl), I&amp;#x27;d start complaining about it and looking for something else to do. I personally wouldn&amp;#x27;t mind working with Erlang, but that isn&amp;#x27;t the point. Many developers &amp;quot;can&amp;quot; do these things but it doesn&amp;#x27;t mean they want to.</text></comment>
<story><title>Ask HN: Who regrets choosing Elixir?</title><text>I’ve seen a few Elixir success stories posted here recently. Virtually all comments are from raving fans that have nothing but the best to say about Elixir.&lt;p&gt;As someone with primarily a Ruby &amp;#x2F; Rails background, I’m choosing a language for a new API project and considering Elixir. I’m interested in hearing some counterpoints to Elixir, especially in how a smaller ecosystem Of 3rd party libraries slowed down development.</text></story><parent_chain><item><author>carapace</author><text>This, twice.&lt;p&gt;Back in the day people would balk at hiring Python programmers saying, &amp;quot;there are so many more Java programmers&amp;quot;, and I used to say, &amp;quot;Why would you hire a Java programmer who was unwilling or unable to learn Python?&amp;quot;&lt;p&gt;Same logic applies here: Why would you hire a Python programmer who was unwilling or unable to learn Erlang?  (Especially if you&amp;#x27;re going to &lt;i&gt;pay&lt;/i&gt; them to do it!)&lt;p&gt;If you can&amp;#x27;t switch languages you&amp;#x27;re a kind of &lt;i&gt;technician&lt;/i&gt; not a programmer.&lt;p&gt;FWIW, having done it professionally for ~15 years I&amp;#x27;ll never write another large project in Python again.  Erlang&amp;#x27;s runtime is so much better than Python&amp;#x27;s it&amp;#x27;s just ridiculous.  I feel stupid for not realizing this sooner.</text></item><item><author>craigsmansion</author><text>&amp;gt; there was no one left who could support an Erlang system.&lt;p&gt;If you have $200k &amp;quot;python engineers&amp;quot; on the payroll who wouldn&amp;#x27;t jump at the opportunity to do some additional Erlang, maybe it&amp;#x27;s time to reconsider your hiring practices and that is the real cautionary tale.</text></item><item><author>as-j</author><text>TL;DNR, use a language your company can support.  It doesn&amp;#x27;t matter how suited to the job a language is, if it&amp;#x27;s single Engineer or small team, what happens when they move on?  How do you support it?  Who&amp;#x27;s on call?&lt;p&gt;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.&lt;p&gt;But, there&amp;#x27;s always a but.  We&amp;#x27;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&amp;#x27;s key infrastructure, but not really a full time project, so we hired a Python+Erland person.&lt;p&gt;But! Now they&amp;#x27;re on call 24&amp;#x2F;7 since the regular on call roster are python people and when the Erlang service goes wrong, it&amp;#x27;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.&lt;p&gt;Another way of looking at it, let&amp;#x27;s say it&amp;#x27;s a critical service and you need at least 3 people to support it&amp;#x2F;be on call.  If each engineer costs $200k&amp;#x2F;year, that&amp;#x27;s $600k&amp;#x2F;year. Does this new language save you that much over using a more generic and widly known language in the org?</text></item></parent_chain><comment><author>craigsmansion</author><text>Regrettably, also back in the day and probably around the same time, companies who wanted to hire &amp;quot;outside of the box&amp;quot; asked for Python. Not because they were python shops, but because they figured that people who had an interest in a new but not-quite-commercially viable language must have some sort of intrinsic interest in programming, and would likely make for better programmers.</text></comment>