Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented. Just compare the total amount of libraries in Hex, vs the total amount of libraries in rubygems. Somebody will say "but Elixir libraries are higher quality so we need less, etc,etc" as if there were not good developers in the ruby world and every elixir developer were a rockstar.

Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.

Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job.

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.... you will need more than 1 server anyway, so...

Liveview sounds amazing until you try to use it in the real world. The most minimum latency kills the experience.

In the end, we are back to Rails and much happier. Specially now we are using all the hotwire stuff. Not fancy, and not fashionable though.

- Be careful about libraries. If you know that your system has to interact with X, don't assume that there is a running, idiomatic, maintained libary for X on `hex.pm`. Do a bit of due diligence. We had experience ranging from `meeh` (oauth2, graphql, http) to `pretty bad` (mqtt, swagger.)

But as other say, if you're doing vanilla Phoenix/Plug/Ecto with exactly the right kind of DB, you'll should be ok.

- Give a little though about how you'll be deploying and operating. `releases` and `configuration` haved changed in pretty big ways in the past (https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...), the ecosystem is constantly in flux (`config.exs` vs `Application.get_env` vs ENV_VAR vs..) . Plus, the erlang virtual machine (BEAM) has knobs that are not always easy to play with. And if you hide it behind, say, docker containers, you'll have other troubles. Don't expect an `heroku do-some-magic` experience.

- Unless you're familiar with the Actor Model already, and your application is very simple, expect a learning curve made of:

  1. A period where you're afraid of GenServer and fail to do anything because you don't want to create a supervision tree
  2. A period where you think you've understood GenServers and you create GenServers like crazy
  3. A sobering period where you don't understand anything about your application
  4. A couple of refactorings where you move the pendulum until you reach something that's acceptable

I would also say that the "library" one is basically valid for every language. In general is always a good thing to spend some time analyzing the possibilities before importing an external lib into your application.

Which graphql library do you prefer over absinthe in other ecosystems?

(And it's entirely possible that we simply picked the wrong lib ! Which is, still, kinda my point. Every elixir lib is "young" by virtue of the language being "young", so you can't use "age" as a heuristic for being the "right" lib. Happens for all"young" ecosystem,so not particular to ex.)

Five years ago I spent time learning Elixir on the side thinking I was investing in an upcoming technology that would pay off for me financially. I eventually built some services in Elixir at work and really enjoyed it. They performed well but the language didn’t catch on with the rest of the team.

However, five years later the mainstream languages (Ruby, Go) are still paying more. I still get recruiter messages for Elixir jobs offering less than market value but I haven’t used the language in over a year.

It's only a matter of time until you hit something as confusing as https://elixirforum.com/t/dbconnection-connectionerror-pid-x...

Previously I wrote Scala for a few years, then RoR for a few years before that, following about a decade of Perl. I recommend you try Elixir.

Anyone complaining about a talent pool is focusing too hard on prior Elixir experience. We hire backend engineers and teach them Elixir. This has worked out great so far, especially now that we're a fully remote business and are no longer as constrained by geography.

Apart from application bugs we’ve caused, it just keeps chugging along and working beautifully. It’s never once been the bottleneck in our stack.

Finding people has not been tough at our scale, and they’ve been good quality.

We are just scratching the surface with OTP. And between that and the data processing tools, we know we can handle pretty much any scale.

Deployment is nearly as crude as it was 5 years ago though. We use distillery and edeliver. We are moving to docker containers soon.

We use Exq for background jobs and have processed 75 million in a year without a sweat (most of that in the last two months). We handle 55 million requests per month on t3.mediums. We are looking to switch from Exq to Oban but I’m nervous about whether Oban’s Postgres based architecture will handle it. It’ll probably be totally fine.

Thinking in processes and knowing/using the GenServer abstraction is the core of Elixir programming.

So, one negative is that difficult to use without Erlang knowledge. Also some good libraries are Erlang only for compatibility/historical reasons.

The popular packages are top-notch, but as others have said - there might be issues finding what you need. My personal experience seems to be the opposite though - when going from Elixir to Ruby, it turned out that some of the gems were really, really far from perfect.

In terms of deployment, my take is that the community has finally figured it out. Elixir is a compiled language, so there is a build-time configuration and runtime configuration and I think it's best to keep the two separate, which is now well supported by the new runtime config (Elixir >= 1.11). Mix releases + runtime.exs + Docker works for me perfectly.

If you're coming from RoR, you'll be able to pick up Phoenix really quickly. It draws a pretty clear line between your web layer and your business/app layer though. Writing controllers and views should be similar, but I'd suggest spending some time on Ecto - it's quite different from ActiveRecord (in a good way, IMO).

One thing I'm missing in Elixir is optional static typing akin of TypeScript, but that's not coming anywhere soon. Other than that, no regrets.

I got introduced to Elixir in 2015 and was trying to work with it full-time since then. I was able to get a full-time Elixir job and I'm really happy about that. If you're looking for opportunities, I'd suggest attending ElixirConf or ElixirConf EU - last year I got 5 interesting job opportunities from ElixirConf EU alone (it was a virtual event, so the ticket was cheap).

Everything from ecto, and branching logic by pattern matching function signatures to the easy composition and cohesive community around the amazing tooling (mix/hex) and testing. Plenty more I love for productivity

But because of OTP and it's capacity to scale and distribute computation I thoroughly stay loving how deep the topic is and how there's always more to learn.

That being said, the ecosystem is wonderful. Plug, Phoenix and Ecto are exceptional libraries!!

It’s winter of elixir land. The hype cycle has died. If I have to start a project I will think twice unless it really needs distributed system.

My personal opinion - talent pool, plugins and ecosystem is kind of stagnated. First talent pool is really limited and not readily available. Very few companies use elixir in production. More hobbyists in the community than people who actually use it.

Hex has a lot of plugins which are not updated from long. For many there won’t be a plug-in. You have to write it from scratch.

In Phoenix, they are reinventing magic with LiveView.

Few guys who do elixir consulting gain most from the ecosystem.

As a developer if I have to invest my time learning a new language, I would choose rust or Go.

As a company if I have to start a project, I will check whether I have a requirement of distributed systems.

PS: I have used elixir for past 5 years in production.

Especially if your code does not saturate a single CPU core.

I think the only downside for me is having to squint sideways to figure out how to convert a complex SQL query into Ecto. I've been writing SQL for almost 30 years and I find myself dropping into using Ecto's `fragment` too often. I've been meaning to pickup "Programming Ecto" to educate myself more (https://pragprog.com/titles/wmecto/programming-ecto/).

I've done my share of RoR apps too and the nice thing about Elixir is there is very little magic and what magic there is (mostly via macros and code auto added via a `use` statement) can be seen and changed directly in your code instead of being hidden in some gem somewhere.

Switched from ruby to elixir 4 years ago and the only time we touch ruby is to maintain some old system.

It’s so darned easy to add functionality to an exiting app that you have to be careful of bloat.

And the functional paradigm is like second nature now. It’s hard to go back to a non functional language.

Scala isn't exactly an imperative language. If anything it's the actor model isn't exactly easy to wrap your head around