> Very very few companies build and maintain SDKs for Elixir.

This is true with any tech until it gets traction. React/Next is backed by a big company, but Vue/Nuxt still managed to grab its piece of the pie.

In order to get traction Erlang / Elixir needs enthusiasts who are ok with risking and introducing it to their company or product, at least partially.

No offense, but instead of condemning the Elixir ecosystem, why not embrace it in your company or product, as many have done (including me)? I think most devs should be OK with taking a tolerable risk if they see opportunity to increase productivity by N times

We did and it was a lot of work. We had to maintain 5-6 libraries ourselves instead of using one maintained by the services themselves. We had to fork libraries because they became abandoned.

Elixir has been around for 12 years now and still hasn't gained any meaningful traction.

The risk of using Elixir vastly out ways the benefits today if you are trying to build a product.

There is a reason why almost every product today is built using JS and Python because it easy to find developers, it's easy to find everything you need, almost every service supports it and there are tons of resources for it.

We switched for Elixir to JS and we only have to maintain the app itself. We have hundreds of OSS helping maintain the libraries we use most of them working for companies that the libraries are for. That's the massive advantage of using popular languages that everyone uses.

Elixir is a fun language but that's about it.

Million+ concurrent users per server - Discord are certainly having fun.

All while having so few employees. I don't blindly copy discord, but I pay attention to most things they do engineering wise. IIRC they have like 2 people working on the mobile app. It's insane, and I think a great story for those that want to start small and stay small.

NPM is anything but fun, I’ve seen tertiary dependencies cause complete application failures due to bad patch version releases.

Packages depending on packages not maintained or containing security issues.

I don’t know how many times Next has released broken updates without any mention of it in their change log and then you find a GH issue where it’s essentially “works on vercel hosting”…

Easy to find developers is often touted as a plus, but the process for making sure you get the right ones are scarce, and JS code bases almost always ends up as complete spaghetti as a result. As someone doing JavaScript for a very long time my statement is that it’s one of the hardest ecosystems to get right and it requires exceptional developers to do so, unfortunately it’s also where many start their journey and without exposure to other technologies becoming great at it is very hard.

The fact that I can do `mix hex.outdated` and get a code diff on dependency changes makes me smile every time, compared to the insanity that is updating npm packages in any sizeable project with hundreds of updates weekly.

I don't fully agree with your statement. We had used Scala around the time the devs were playing around with dotty. I loved many features of the language (compile times were painful, but the language itself was fun). But we had to stay back because a specific db dependency did not resolve well with later versions of Scala (2.13 it broke).

Similar thing recently, there was an obscure Scala version mismatch error when trying to use it with spark. (Not that significant of a problem).

It is definitely a headache trying to cope with the conditions till we get better especially with smaller teams who can't afford to fork and maintain something. A

Honestly I don’t see it as such an issue.

If I had to use OpenAI API I would pick my favorite HTTP client and just use the Rest API and write a small wrapper around it for my needs.

For API clients it's hardly any work to write your own. Sure large communities have more off the shelf options but those options are also more likely to go out of vogue.

NIFs and small services can often fill the gap if really needed.