Comment by likortera | Hacker News Reader

Comment by likortera | Hacker News Reader

Parent Full thread

The folks you're talking about are a lot more expensive (in Europe at least) than the equivalent folks for more traditional platforms.

Again, and without centering ourselves in pure technical and our own careers and CVs. How does that help the business?.

Regarding to libraries, there's not much to discuss.

Just look at the number of available packages as right now:

rubygems: 164,235 (source: https://rubygems.org/stats) NPM: millions (source: https://en.wikipedia.org/wiki/Npm_(software)) PyPI: 283,519 (source: https://pypi.org/) HEX:: 12 252

I'm pretty sure I can find more than one package I'll miss.

> My company has built a scalable platform with 3 engineers. I don't even think about maintenance, I just think about delivering new features. So business wins are higher velocity + lower hosting costs + less downtime + senior team. You don't need to be WhatsApp to appreciate those benefits.

Hosting costs are a lot cheaper for us than developer's time. Downtime has never been an issue given "cloud" (docker based) infrastructure. The productivity part is something we're not seeing to be any better than with more traditional technology, and the reason we're moving away.

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.

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.

And of course so many packages are just adding basic functionality to JavaScript that is available in most other languages' standard libraries.

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 would consider NPM's "millions of packages" with a big lump of salt.

Reply on news.ycombinator.com