- The learning curve is real. but 2-6 months for us, not years. It's not particularly hard, just longer than a small language like go.

- Having Ruby and/or functional programming experience shortens that learning curve.

- Developer experience/satisfaction is very high. This helps retention

- Some devs will just never "get/grok" Elixir. They may have 20 years of java experience or a new dev better suited to a FE role. This doesn't mean they are bad, just not a great fit.

- The devs that do get it? They are quite productive. Feature velocity is high.

I disagree that Elixir/Phoenix isn't a fit for CRUD apps. I'm seeing high feature velocity across small and large scale products.

In particular, feature velocity per engineer is quite high. A smaller team in Elixir/Phoenix/LiveView can outpace a similar full stack team.

Elixirists really are senior developers and Elixir is usually their fourth or fifth language. If it's taking your hires years to get up to speed, then I would look at your hiring practices before blaming the community.

As for libraries, I challenge anyone to name an unmet dependency in Elixir that is 1) trivial to implement and 2) not for some niche application.

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.

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.

> 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?

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.

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.

For quite some time the ex_aws[0] package was no longer maintained because the only person who maintained it stopped using AWS. There were many months in between before a new maintainer was found. Unlike Python, Ruby, PHP, Node, Go, etc. there's no official AWS SDK for Elixir.

The ecto pagination[1] package has a "low maintenance" warning, basically the author is no longer maintaining it except for fixing issues even though there's a number of interesting features that could be added that other web frameworks have available.

The arc file upload[2] package was no longer maintained or touched for a really long time until someone took it over but now that new package is also racking up open issues and looks like it kind of stagnated in development. This isn't based on looking at last commit times too. I mean there's issues open to address important topics that haven't gotten reviewed for a long time.

There's also no official Stripe SDK for Elixir and all of the community created ones feel kind of abandoned or no where near feature parity with Python, Ruby, Node, PHP, Golang or any of the other official packages offered by Stripe. This is the last thing I want to have to implement myself since it's so critically important. The same can be said for PayPal and Braintree integration. There's official SDKs for Python, Node, etc. but not Elixir. I've asked Stripe a couple of times about an Elixir client and they all say the demand is not near enough to consider creating one officially.

These are only a few examples of tools I've found in questionable state when working with Elixir compared to Python and Ruby. All of which are very important in a ton of applications.

Then there's also less generic but still really useful things like notification abstractions to send emails, texts or broadcast notifications to connected clients. Rails, Laravel and Django all have excellent solutions to this where you can get up and running in no time but with Phoenix you'll have to write all of this on your own. It's a huge undertaking.

Long story short, I started with Phoenix and Elixir almost 2 years ago and today 2 years later I feel like if you plan to write any type of business'y app with Phoenix you're going to have to end up writing a ton of libraries yourself instead of focusing on your business problem. That might not be a problem if you have a huge team and your business idea is already proven and 5+ years old but for anyone who wants to build something and see if it works, it's hard to say you'll be able to build something faster than Rails, Laravel, Django or Flask if you already know one of those frameworks.

Now you might say some of those packages are trivial to write but they're really not. That seems to be a common pattern I've seen with the Elixir community where someone will say just do it yourself because it's easy and then you're left hanging. Sure maybe it's easy if you're Jose or someone with 5+ years of prior Elixir experience and have written 100k+ lines of Elixir code but a regular developer who just wants to build web apps (not libraries) is going run into tons of roadblocks. I know I did.

[0]: https://github.com/ex-aws/ex_aws

[1]: https://github.com/drewolson/scrivener_ecto

[2]: https://github.com/stavro/arc

I found Elixir extremely easy to learn (despite having no Ruby experience, nor any significant experience in any functional languages). I went through the (excellent) official tutorial in a couple days, skimmed parts of Saša Juric's book, and felt reasonably confident diving in to actually writing code. Within a couple weeks I felt like I "got" OTP and idiomatic Elixir.

I do agree that, at least for somebody who uses Intellij IDEs exclusively, the lack of good first-party support sucks. I do most of my debugging via unit tests and "printf" because the Intellij Elixir plugin's interpreted mode is just too slow for the debugger to be useful to me.

That’s interesting. I’ve been doing Elixir for a while and found it almost overwhelmingly simple. As in, I’d do something in a very simple way which would usually take me a lot longer and have to think whether it was actually right because I’m not used to that.

I recently learned Go and I think it was only slightly more difficult to learn than elixir. I could see having trouble if you have never done functional before, but that’s kind of a separate issue. The language itself is tiny.

OTP is one thing that can take a bit of getting used to. But again, I think that’s only for people who are only used to traditional threading methods of concurrency, which is again a separate issue. OTP and the actor model themselves are dead simple in terms of how to use them.

> The editor plugins are terrible, slow, and blow away your CPU doing god knows what kind of indexing

Without even looking I already know what this is. You are using ElixirLS and you are hitting the Dialyzer PLT generation which is needed for type assistance. Elixir LS gives you a pop-up (at least in VSCode) telling you that it's building the PLT and it might take a while. You can disable this if you really want. Most importantly it ONLY RUNS ONE TIME. So, if you've already generated the PLT for a project, it will NEVER run again until you upgrade Elixir or something major. Other than that, I rarely ever see Elixir LS taking up any noticeable CPU.

> Compilation is slow and takes a lot of time Yes it does. However, you can just cache the _build/ directory in CI. Then it will act like it does locally, only recompiling what has changed and doing it very quickly. Usually, dependencies will not need to be recompiled if they haven't changed.

Also, testing in Elixir is crazy fast and everything runs nicely async by default, even database tests with Ecto.

Could you provide a little bit more context around where it's coming from so I know how to interpret it?

Are you someone who recently joined this company and is now having to learn Elixir? If so, are you finding it difficult? Has it been taking you months or years to learn it and still feel like you don't know it well enough? How long have you spent trying to learn?

Or are you someone who knows Elixir very well and has worked at the company for a long time doing Elixir work and you're observing the struggle to find new junior hires that are willing to learn it and finding it hard to teach it to them? It be nice if you could tell us the number of years of experience you have with Beam and Elixir as well.

Thanks

* It was very hard for our startup to find any Go developers.

* The Go language server would very often cause massive CPU spikes.

* At the time I was using it, the community support in Go was really, really bad.

I'm sure things have changed a bit, but there are always growing pains when choosing a niche technology.

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

Salaries are actually pretty good. Not facebook salaries, but good enough and certainly above average. The company can already get very proefficient, experienced developers in Ruby and JavaScript.

> moving to a better company?

I certainly could. But how does this solve the business problem I'm talking about?

The reason I'm not moving to another place and instead helping transition back to normality is because I actually like the company, and my coworkers, and I like to focus on building our product and solve the real problems the company was created for.

Elixir can be a great tech (the best) for certain kind of problems. In our case (and any other "CRUD" like web application like 80% of the internet) is an expensive, distracting toy.

Otherwise I agree with a good part of your post. For CRUD work I feel way more productive with PHP/Symfony than with Elixir/Phoenix, especially for outputting HTML. Part of it is the DX with the templating and type hinting but also the unbeatable amount of libraries and manpower behind the language and framework.

Otherwise the plugin for Jetbrain's IDEs works OK for me (but again it can't beat the Symfony plugin with PHPStorm features).