10 years-ish of Elixir

Drawbacks I see are:

1. no static typing. With typescript having taken off, and now even python and ruby becoming more and more feasible to use in production with static typing, switching to a new dynamic language is a hard sell for me.

2. limited ability to take full advantage of some of its unique features in many cases. The runtime and the included OTP library/paradigm has some really cool features with its approach to processes and concurrency with the actor model, and features like hot code reload. But IMO the industry and popular best practices have evolved in a different direction that make these things less compelling. Code deploys are a solved problem in any of the major vm/container runtimes, with blue/green deploys, canary builds, feature flags, etc. all quite easy to use, so hot code reloading isn't that compelling as a language feature anymore. There are tons of ways to orchestrate multiple instances of a services from Heroku to Kubernetes, and APIs built on Protobuf and GRPC, GraphQL, or json REST APIs, are now pretty standard for communicating between different services, or using message queues, kafka, cloud pub/sub, etc. Also the paradigm most developers are familiar with is stateless app servers that store any state in database or cache layers, which has a lot of benefits.

Erlang and OTP seem to kind of mix all of these paradigms together, and if you use all of its built-in ways of doing things you are really striking out on your own from the common "best practices" that more developers these days will be familiar with. A lot of common tooling and cloud hosting providers don't support Erlang OTP style programming natively. It can certainly be used successfully, I believe Whatsapp as one famous example was originally all written in Erlang, but I personally don't see a whole lot of justification for most apps to do this. Of course you don't have to use any of these features, but then why use a language if you're not going to lean into its unique strengths?

Meanwhile te company I work for is moving away from it. We cannot find enough people with enough knowledge to be already productive in it. Not many want to learn it because it is considered pretty niche, and the ones willing to learn will need many months or years to be productive and build with some level of quality, and once they learn they move away to bigger companies which pay more. We end up paying to people to learn to then "graduate" and we end up with a platform built by people that were learning.

Some people here say the tooling is great. Compared to what? The editor plugins are terrible, slow, and blow away your CPU doing god knows what kind of indexing. Compilation is slow and takes a lot of time (in CI for example). Libraries for things you give for granted in other platforms (java, javascript, python, ruby) are non existent, implemented in erlang, unmantained, poorly documented, not popular enough, or a combination of these.

People are using it for creating traditional CRUD apps, and it is totally overkill. Something you would do in a day with django or ruby on rails takes a lot of time. Ok, you have tons of concurrency and scaling and.....but... unless you are facebook or google or amazon you won't need this anyway.

Probably all of these things will be solved in the future, but at this moment, using Elixir for real production code in product focused companies is just a terrible mistake in my opinion. Certainly the ideas, the technology, and the BEAM are awesome...and it is technically superior to everything I've seen out there. But from a business perspective, it makes no sense to use it unless you're building the next whatsapp or similar.

> once they learn they move away to bigger companies which pay more

Maybe consider paying your people more or moving to a better company?

Thanks, I'm not GP but have the same questions.

What about access control? That's often directly tied into business logic, but it's so elegant and convenient to do it in the controllers or even the router using the pipelines. In fact a ton of the examples (I think even the Chris McCord Phoenix book) does exactly this, presumably for that reason.

However I did that with an app and haven't been very happy with it because while the bulk can easily be done in the router/controllers, there are things that are totally inappropriate to do there and so it ends up in the context. Then your logic is distributed and messy, which is awful. But putting all access control in the context also bloats and complicates a ton of otherwise very clean, elegant API functions. I try to keep the Repo query building code clean and separate but that often leads to inefficiencies (such as filtering fields in the caller instead of in the generated SQL, which is vastly preferred for obvious reasons).

Anyway, interested in thoughts on that.

Ruby really isn't becoming static though. Most code used by Rubyists (e.g Rails apps) is likely to remain dynamic.