> We built a few services

So you never really committed to it in the first place. Also, this complicates the deployment problem.

> after a few years some of the original people that introduced it left the company

Probably left for a company that actually committed to Elixir. :P

> and it became very difficult to hire for

In a world where everyone is remote and where 10 Elixir people apply to every job, this product must have been pretty unappealing

> New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elixir.

"We didn't want to pay employees their worth and instead bitched about what we couldn't get without hiring those employees"

(Why couldn't you hire an assortment? One experienced guy and a couple noobs?)

> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented

Alright, fine. Sometimes you have to "roll your own" in this space, still.

> Tooling is just terrible. The VSCode plugin is crap

You should not use the word "tooling" here because VSCode is not an IDE, Elixir should not require an IDE, and moreover, Elixir should not be judged because "there is no good IDE for Elixir". "Tooling" should refer to the support libs and tools that ship with the language, all of which are excellent.

> At that point you're just reinventing your crappy undocumented and untested version of delayed_job.

Spotted the guy who never heard of Oban https://github.com/sorentwo/oban Benefit of the doubt: Perhaps it didn't exist yet.

> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS

This is entirely missing the point. If a bug or runtime error crashes your Ruby interpreter, you better have another one ready to go from a pool (because Rails stacks can take a while to load), and then you better not exhaust that pool! If such an error crashes Elixir, it just restarts the process, which only takes a millisecond because forking an immutable language's state is trivial compared to a mutable language's state.

> Liveview

I actually haven't played with it much yet so can't comment

> In the end, we are back to Rails and much happier

"We can underpay cheap devs again"

You also repurchased entire classes of bugs that are impossible in Elixir such as: mutation bugs, monkeypatch bugs, and concurrency bugs (just forget running your test suites in parallel). Also, these are literally the hardest types of bugs to fix (nondeterministic behavior), and will likely cost you more in the long run than any differential salary you balked at (I have spent entire months debugging something in the Ruby space, you'll remember my comment once this bites you in the *** one day).