Ironically, Europe has a higher concentration of Elixirists given Erlang was invented there. My hiring attitude is that paying for senior developers is cheaper in the long run given their ability to make better decisions.
> I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers.
Emphatically no. Having more servers costs more than just hosting, there's maintenance, orchestration, and communications complexity.
While other package ecosystems certainly have _more_ packages, the question is: how many of those will you actually use?
> While other package ecosystems certainly have _more_ packages, the question is: how many of those will you actually use?
Exactly. Saying NPM has millions of packages is completely misleading. There will be 20, 30, 40 packages that all do the same thing.
Elixir is also a very stable language with no current plans for a 2.0 release. This means that while a lot of Hex packages may not have been updated in a while, they are still rock solid. I agree that this is a very hard thing to get used to since the first thing I always do is looked at the last commit date and then the number of stars. While this is still useful, it doesn't hold the same weight it does in other ecosystems. Personally, I think this is how it should be.
I won't say that the Elixir ecosystem is perfect, though. There has been trouble with maintainers leaving projects, but to knowledge someone always steps up.
> Exactly. Saying NPM has millions of packages is completely misleading. There will be 20, 30, 40 packages that all do the same thing.
And the one with the obvious name hasn't been updated in 18 months. Maybe it's complete. Maybe the developer has moved on. Then there are a couple half hearted forks. All of these dependencies bring in 1 to 100 dependencies each and you have to spend a days on the treadmill every month or two to keep things updated.
I loved Node development despite the packaging mess but I really appreciate how the Elixir community tends to coalesce around key libraries/frameworks/methodologies and focus on making them the best possible.
Is that a Node specific problem though? I have elixir packages up on Hex that I haven't maintained or looked at in years. In fact, I'm pretty sure they are buggy but since no one is using them I'm not worried about it.
There are packages on Hex that haven't been updated in a long time but still work perfectly (Canada, for example: https://github.com/jarednorman/canada). Elixir itself doesn't change much... in fact there's no plans for a 2.0 on the horizon, so the fact that packages don't change often isn't a big deal if they still do what they say they do and aren't hurting for more features.
Ooo, I'd also mention that there often isn't a need for a lib. For example, as outlined in The Little Ecto Cookbook, it's trivial to build a small fixtures framework—the API is two one-liner functions! Sure, it's missing a few things, but I've been using it on my own project and have not missed anything provided by dedicated fixtures lib.
> I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers.
Emphatically no. Having more servers costs more than just hosting, there's maintenance, orchestration, and communications complexity.
While other package ecosystems certainly have _more_ packages, the question is: how many of those will you actually use?