There are many different ways to reply to that question :-)
For me, as a Rubyist since 2004, the hardest part (by far) has been the incredible "comfort vendor lock-in" provided by Ruby. I have been working with Elixir since circa 2016, and only today I feel the same level of fluidity in the 2 languages.
This is not to say Elixir is hard to learn (this is not the case), but Ruby is incredibly sticky in that regard.
On the project launch itself (started circa 2017), as described in the article and afaik, the team was largely free to pick their preferred stack, so there was no external pressure to avoid a "new" stack. I cannot comment on the friction they may have had at the time.
A point of friction was how to "configure an app". Over the years, the way to configure an app in Elixir has evolved (and much improved), culminating with the latest "config/runtime.exs" which allows runtime overrides for both mix projects and releases. I consider the situation stable now, but we had to clean-up the code & the ways to handle that.
Deployment is not perfect at the moment: we are using (for the sake of simplicity) a Docker-based approach, which helps us decide exactly which version of OTP/Elixir we want and deploy it almost anywhere. We will move to releases later (but first we had to clean-up the configuration system).
XML processing is not super easy to achieve. Good libraries (e.g. saxy) have appeared, but you can feel you are not in .Net/Java.
Recruiting is not a problem: most developers so far have been eager to level-up on Elixir, and a good developer won't have much trouble at this point of the Elixir story to get onboard.
Lastly, before that project, in some enterprise contexts, Elixir was a harder sell compared to Java/Node (even if I managed to use it ultimately). You have to prove that the stack is reliable, will be there tomorrow, can compete with alternatives etc. It is better to use it in enterprise contexts where you are free to choose (or start using it for tooling/checks, before promoting it to larger projects).
If you have more specific questions, let me know :-)
For me, as a Rubyist since 2004, the hardest part (by far) has been the incredible "comfort vendor lock-in" provided by Ruby. I have been working with Elixir since circa 2016, and only today I feel the same level of fluidity in the 2 languages.
This is not to say Elixir is hard to learn (this is not the case), but Ruby is incredibly sticky in that regard.
On the project launch itself (started circa 2017), as described in the article and afaik, the team was largely free to pick their preferred stack, so there was no external pressure to avoid a "new" stack. I cannot comment on the friction they may have had at the time.
A point of friction was how to "configure an app". Over the years, the way to configure an app in Elixir has evolved (and much improved), culminating with the latest "config/runtime.exs" which allows runtime overrides for both mix projects and releases. I consider the situation stable now, but we had to clean-up the code & the ways to handle that.
Deployment is not perfect at the moment: we are using (for the sake of simplicity) a Docker-based approach, which helps us decide exactly which version of OTP/Elixir we want and deploy it almost anywhere. We will move to releases later (but first we had to clean-up the configuration system).
XML processing is not super easy to achieve. Good libraries (e.g. saxy) have appeared, but you can feel you are not in .Net/Java.
Recruiting is not a problem: most developers so far have been eager to level-up on Elixir, and a good developer won't have much trouble at this point of the Elixir story to get onboard.
Lastly, before that project, in some enterprise contexts, Elixir was a harder sell compared to Java/Node (even if I managed to use it ultimately). You have to prove that the stack is reliable, will be there tomorrow, can compete with alternatives etc. It is better to use it in enterprise contexts where you are free to choose (or start using it for tooling/checks, before promoting it to larger projects).
If you have more specific questions, let me know :-)