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

My company is moving away from it. We built a few services but after a few years some of the original people that introduced it left the company and it became very difficult to hire for. 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 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.

I'm at a relatively early stage VC-backed startup and from day 1 it's been written in Elixir. It was a fantastic choice, for many reasons, with some being:

- Elixir is good for just getting stuff done. I came from a previous startup that used Go and Elm.

- The community isn't as small as people make it out to be, or, it's quality over quantity. ;)

- There's a lot of good modules out there, and if you need to write your own, it's easy and there's well-defined patterns. E.g. I recently improved our internal Zendesk client and it was a breeze.

- https://dashbit.co/ for paid support/advice is amazing.

- The console for experimentation, debugging, inspection, etc. is fantastic.

- The let it crash, and other Elixir/Erlang philosophies, have been very helpful.

- There's a solid amount of batteries-included, but not in an overbearing/restrictive way.

- It's such a pleasant day-to-day dev experience.

I didn't know Elixir before joining this startup. For myself, and workmates who also didn't have prior experience, it's been a breeze to get up to speed in.

It's not argument "against" selecting it (it's a free world, and mileage vary), but a couple of scar-earned advice:

- 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

- Finally, you're coming from RoR, so you're probably fine with not having static types anyway ; may St Isidore help you ;) There is a thing called `dialyxir`. It might help a bit ; It will disappoint a lot.

I’m very satisfied with Elixir. I, a longtime Ruby on Rails developer, learned Elixir on the job at CityBase and have been thrilled with it every day.

The first thing that tripped me up with Elixir is the difference between single quoted and double quoted strings. They’re different data types!

Most of the work I’ve done has been writing JSON or GraphQL apis that react apps consume. We’re about to start using Phoenix LiveView.

I like using Phoenix + Ecto. It’s lightweight and very fast. I learned Ruby through my work with Rails, and I did not have the same experience with Phoenix. And that’s for the better.

Deployment-wise, we moved from Edeliver to Kubernetes and it’s worked great.

I need to figure out the right editor experience for NeoVim, I haven’t gotten an LSP to work just right. Sometimes Dialyzer is a pain in the ass. Also, I’ve had some issues installing erlang via ASDF lately and sometimes I’ve had to use homebrew symlinks to skip that problem.

I recommend that OP give Elixir a shot and see what you think. There’s also very nice community on the Elixir language slack server.

I'm about six years in with Elixir, five years in production at Appcues. I have no regrets at all -- Elixir and the BEAM have been fantastic. It is convenient to write very scalable and stable systems that operate in soft real-time, which is what I do for a living, so I have warm feelings.

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.

We chose elixir in 2016 for our product and never regretted it.

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.

I love Elixir. But…

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.

As an SRE who has had to baby sit production elixir apps I'd highly recommend first having a talk to your operations guys. I've never had a more challenging system to debug and keep running.

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

Very satisfied with Elixir! I think it just fits my way of thinking. I love the terse, but explicit code, the VM, OTP, pattern matching, working with immutable data, integrated tooling, documentation support. The community is great, too.

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).

We adopted it 4 years ago and love it.

As for training people, I taught my non-technical co-founder Elixir for some backend scripts he needed to write. He found it much simpler to pick up then Javascript or Ruby and his code was idiomatic rather quickly.

As for the IDE support in VSCode, I've found ElixirLS[1] great. I do have to restart it sometimes (delete the .elixir_ls folder), but that's a small cost to pay for a pretty great experience.

After spending years in RoR in multiple code bases, I find Elixir code bases to be easier to debug and libraries easier to grok. Without the mutable state of OOP, I don't find myself asking, "Where is this state coming from and when/how was it set?" Of course, macros can be hard to follow, but I still find an Elixir library more straight forward than a Ruby one.

We've also experience the great performance and reliability shared by others on this

We haven't had difficulty finding the right libraries even though the ecosystem isn't as mature as Ruby or Javascript.

[1] https://marketplace.visualstudio.com/items?itemName=JakeBeck...

It’s honestly been one of the smartest choices we’ve made. We’ve been running it for four or five years now. It powers high throughput systems and those systems are classified as critical (if they go down, most of the product goes down.) Not a single regret.

New hires new to Elixir have spun up on it very quickly, in my opinion what a team needs is one or two people experienced in Elixir to give some initial guidance but you don’t need a staff of experienced Elixir engineers to do great work. I have not found it a hard language to teach.

Personally I’ve found the library ecosystem very strong, and writing our own libraries has not been hard. It’s important to note that interop with Erlang is quite good, so you have access to decades of library development from the Erlang ecosystem in addition to libraries written in Elixir.

The basic elements you’re given out of the box for handling fault tolerance and concurrency are graceful and intuitive. The performance has also deeply impressed us.

On a personal level, it’s also the most enjoyable language I’ve worked in and I’ve had very good experiences with the community. I find the tooling very good, including the VSCode extension (I have contributed a few features) but the default dialyzer setting definitely does hog the CPU on first build. I disabled it since we don’t get much out of it.

I’ve built and run software in production in a lot of different languages over the last 15 years. Nothing has compared to Elixir, not even close.

YMMV, I’m not here to refute the experiences of others, I’m just here to say for us it’s been an incredible experience. Absolute joy to use.

4 years of writing elixir professionally and I have yet to enjoy a language as productive as elixir.

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.

If you invest time learning Erlang everything around Elixir will make sense and it will be a pleasant experience not only to "write" but to test, debug and maintain as well. I would go through this slightly dated but gentle introduction before learning Elixir: https://learnyousomeerlang.com/content

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.

Outstanding work from the Elixir team. Very good community in the forum.

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.

I'm currently learning Elixir and I'm loving it. I'm in that got 30% of my app written in it place.

I may or may not regret using it in the big picture (libraries, esoteric ness, performance, a 5th language/platform in our soup of tech we use to solve our problem, etc, and who knows) eventually; it's too early for me to tell.

But I wont regret learning Elixir. There's a certain zen in the "ah so you're a programmer, eh? But can you do it without any references/pointers or for loops, huh?" This from a guy who spent 20 solid years as an "objects all the way down" smalltalker, and does a lot of multi paradigm hybrid Python/Kotlin/Swift these days with a bunch of C as well.

What I really noticed last week when I did a day of Python after a week of Elixir is how much time I spend in other languages writing branch logic code. Code where you decide what direction your code should go next. Should it do this or that now. Or if it should optionally do that. I'm writing an order of magnitude less of that code (it moves to a more orthogonal place in multi function matching) in Elixir. It's stretching me and I'm learning new ways of seeing things that ultimately make me a better programmer; the slack channel has been really nice.

I tried Haskell to try and get the taste for pure functional a year ago; it did not go anywhere near as well as this.

1.5 years in and Phoenix Liveview is perfect for internal webapps. Have personally seen development take half as much time with half as much people compared to traditional stacks. You don't need super rich interactions nor offline mode for internal apps, plus they might be harder to prio against customer-facing feature work. Elixir and LiveView are really powerful tools to have in your toolbelt. Even if you can't use Elixir, look at Hotwire or Livewire for a similar programming model. You won't get zero-setup fault tolerant components (nested LiveViews can crash and not take the entire page with it, and retry side effects automatically), but you'll still cut out the JS side of the development.

And we haven't even spoken about an app-aware repl that lets you manipulate/inspect your running app (even in prod). There are so many game-changing layers in this stack. It's hard to beat once you've explored it.

Very happy customer here.

I've had an niche event ticketing Elixir/Phoenix app in production for 4 years and have had next to zero problems. It gets very bursty traffic (100s of simultaneous users when an event opens for ticket purchases with load quickly tapering off in a negative exponential distribution) and the load average barely changes with insanely fast responses on a $10 VM.

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.

I've been programming in elixir for 5 years now.

Currently on my 3rd year as CTO of a startup. I chose elixir for the greenfield project because we wanted realtime sync for all devices and the smaller projects I worked on before in elixir went off without a hitch. I also found its concurrenly handling and performance far superior to node and I was producting far less bugs due to its functional nature.

3 years in and I'm very satisfied. There are a few epics we took on that would have been much more expensive to do in go or node. For example, we made a partnership with a credit card device terminal. Their interface required one persistent webocket connection per restaurant. IN another language, I would have had to coordinate with my devops guy to have a dynamic system to allocate a process for each of our accounts and route that to our devices. The intended use case were on premise POSes so our cloud based solution wasn't somethign they had planned on supporting.

Anyways, I was able to configure horde and a dynamic registry to boot up a process for each active account and automatically resserect on crash. Since pubsub is built in, It was easy to pass along data from it to all the devices over the channels interface. Best part is it was all doable within the code base running without any changes to out deployment.

Overall, I've been happy with elixir. the only bg downside is its gotten a bit boring. Things just work which leaves me spending time on rust in my free time when I want a challenge.

I'm very bullish on Elixir as a language, but I temper that with the reality that I don't think it will become a mainstream language (in the next few years, at least).

I picked up Elixir probably 4-5 years ago when a co-worker kept recommending it and wanted to explore it more. We finally got the approval to do a microservice in it that was well-suited for it. Over time it became one of the two "blessed languages" alongside Ruby, and was probably adopted by 40% of teams. Our monolith was still Ruby, so a lot of teams had to use Ruby.

I found that people could pick up the language fairly quickly, but it would take a few stumbles on OTP before things started to click there. People generally seemed to like learning it, though. Maybe they were just being polite.

For me, Elixir has been the most fun I've had programming since I started. It allows me to more consciously design my systems because I don't really feel limited by it—this is why I'm bullish on the language. I enjoyed programming in Ruby, but felt limited to doing things a certain way.

There's also still a ton of opportunity in the community (which is excellent as it is, imo). For example, I wrote a book with Pragmatic that I don't think I would've been able to write in the Ruby world. If you're the type of person who likes exploring, figuring things out, and documenting afterwards, then you could make a nice name for yourself in the community.

Hiring is still a bit rough. If you're trying to scale to 50+ engineers then you're going to need someone skilled in training to bring the team up. Throwing them into the deep end won't work. I think smaller teams should generally not have as big of a problem? I'm curious to see how my former employer will maintain Elixir—grow or shrink adoption—over the next 2 years.

I've been using Elixir/Erlang for more than 6 years and absolutely love it. The community is a lovely place to be, tooling is great. Concurrency is awesome. Erlang is battle tested. If you are building applications that have anything to do with networks, you'll be able to build some seriously performant apps without having to reach for other tools and I love the community's focus on performance.

Unfortunately I can't comment on production Elixir use (yet), but as a proffessional Ruby engineer of 6 years and an Elixir hobbiest of 3, I think that Elixir's biggest drawback is its deceptively high learning curve.

The learning curve is "deceptive" because the Elixir syntax is very easy to pick up for someone familiar with Ruby and, once you get over the functional "gotchas", you can feel productive very quickly. Especially-so given how much you get out-of-the box with a standard "mix new" project.

The learning curve is "high" because in order to actually write Elixir in a way that scales well in prod, you'll need to get comfortable with Open Telecom Platform principles like GenServer and Supervisors, which will likely feel very foreign at first.

For any Rubyist working in Elixir, if you encounter a situation where your Ruby brain wants to start browsing Hex for a library, you should probably answer these two questions first:

1. Can we do this easily with GenServers? 2. Is there an Erlang standard library module that already does this?

Conversely, if you jump in expecting to rely on Hex the same way you rely on Rubygems, you're in for a bad time.

Ultimately, I think you really need someone (ideally two someones) who is comfortable with the Actor Model and OTP in order to use Elixir successfully at a business.

But if you can build that solid OTP foundation for your project, there's a decent chance you're in for a good time.

The real-word business cases provide some encouraging examples of that: https://elixir-lang.org/cases.html

I have been using it for my (modestly sized) first serious public project (https://github.com/domovikapp/domovik-server/), and I have been quite satisfied with it.

For the pluses:

- the development experience is stellar (live code reload, REPL interacting directly with the running server, excellent debugger, dependencies management & build system are good and can be extended in the language itself);

  - the integrated documentation generator is of high quality;

  - the performances are satisfactory (you'll get more out of a $10/m VPS with Elixir/Phoenix than with RoR);

  - deployment is surprisingly easy with the releases system;

  - the language itself is quite pleasing;

  - the standard library is very well designed and architectured, and everything just fall in place together;

  - Ecto shows brilliantly how to combine high-level, ORM-like operations and low-level, close-to-the-SQL ones;

  - Phoenix itself is a very well though out framework.

For the cons:

  - the ecosystem is still quite young and has some sharp edges and/or missing docs; 

  - the OTP is magic for heavily parallel workloads, but it is also quite foreign and there will be some work to grasp its inner workings;

  - there are some quirks in the language coming from the Erlang runtime; 

  - I would love to have a static type system, although I see how it would conflict with the tenets of the OTP.

So all in all I might not recommend it for a very high stakes project; but otherwise, just go for it, it's great.

We’ve skipped so many additional things like Redis, Memcached, Sidekiq and tons of libraries because it’s so easy to write a module to replace stuff.

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.

If you are a RoR dev, Elixir will feel like a breeze. As someone who does Haskell in their day job, I miss static, powerful type-systems.

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

In 2016, we started to use Elixir as our default backend stack (from Ruby on Rails) for new projects and never looked back! We have since shipped a dozen projects using Phoenix, Ecto, Plug and Absinthe.

A couple of guys at my company did their first startup using Elixir years ago, but they weren’t devs so they had to contract a company to do it. They regret it now because no one at our company can work on it, and they have to rely on the contractors who charge a lot. Sure someone could learn it, but we’ve got more important things to do. As much as everyone on HN loves it, you’re going to have to work hard to get others involved. It really isn’t worth it unless you want to own it for the rest of its life.

We started to use Elixir around mid 2016, we were mostly using rails/sidekiq stack at that point and started to face scaling issues with sidekiq. Moved small parts to Elixir first and then later started to use it for most of the new services. We had to create new libraries for some specific use cases. Apart from that, it was mostly smooth experience. We rarely had to tune or adjust the code for performance. Today we have a big monorepo with 20+ apps. My long term concerns are more about whether the tooling will work if we try to scale it to 100+ apps with a single monorepo.

We majorly depend on Plug, hackney, Exq, brod and Ecto.

I have been writing Elixir full time for over 4 years now and I could not be happier with the language and surrounding community! With an incredibly small team (just myself and one colleague working on the backend), we are able to develop and operate very high throughput applications that reliably handle over 100k requests/s (2 main web facing apps, plus a handful of supporting services). We generate millions of dollars of revenue for our customers each week, and sleep very well at night.

I still love it a few years in. Every project I've used it on has worked really nicely with low resource usage and close to zero maintenance. Switching from RoR to Phoenix/Elixir takes some learning, mostly due to the switch to functional programming, but it's worth it imo. Everything becomes so easy to reason about, test, debug, etc. You'll learn a lot from it and become a better developer in general even when going back to ruby/python afterward.

Highly relevant thread from less than a year ago: https://news.ycombinator.com/item?id=23283675

I've been writing Elixir full time since March this year and I've loved it.

Here's a few of the highlights for me:

1. It makes me want to write more tests.

In other languages, I always defaulted to opening up a terminal to quickly hammer out something before implementing it and usually came back to the tests as an after thought. Sure with an IDE integration you can highlight and execute just the test you're looking at, but in many cases I found it clunky.

With Elixir, the entire test suite executes so fast that it's easier and faster to just work with the tests than hammer through things in the console.

For the situation where the console works better, you can copy the iex lines above your method as a code comment and that will run as a test when you run your test suite (so tests as documentation essentially).

Lastly on the test front, the assert_value library is incredibly helpful for hammering out first versions of unit tests.

2. After taking the Coding Gnome course from Dave Thomas, I love the approach to code structure.

Dave emphasizes thinking of the functionality of your application independently from the interfaces which access it. For example, the HTTP layer, a REST API, a Websocket layer, the command line, and an IEX terminal are all different interfaces.

Thinking of my code that way and developing around an internal API rather than doing something like REST first testing, etc has made things a lot cleaner for me. I'm also a big fan of the defdelegate approach for that internal API layer.

The libraries I've needed so far have been really solid, but I generally don't pull in libraries unless I really need them anyway. If I'm connecting to an API, I'd rather write the connections directly in most cases as I need them rather than pull in an API library directly for it. Gives me more control and better understanding of things and I like that. YMMV.

3. Tooling wise, VSCode has been great for me.

I've considered reaching for IntelliJ with the Elixir plugin, but as it stands right now I'm very happy with VSCode. It's been a great experience and all that I need on a day to day basis.

There's a lot more to say than that, but these are my biggest things that I'm liking so far.

Been building backend systems for nearly 20 years in Java/Ruby/Elixir. Elixir is by far the most productive language/ecosystem that I've used. I've built 4 systems in the last 5 years and they've all gone smoothly and performed well in production. Only thing on the wish list is full static typing (there's dialyzer which is useful but very much feels like the bolt-on that it is).

I don't use it professionally, but I built a side-project in Elixir a few years ago and was amazed at how much I was able to get done with such a little amount of code. The service is still running today with basically no maintenance. For me it was a great choice and I would totally build my next project with Elixir on the backend.

I picked Elixir to develop Statuspal 4 years ago as a solo founder, I’m pretty happy with the decision so far, we’ve been in production for close that time and I feel very productive and enjoy it a lot.

That’s not to say we never encounter hiccups, we’ve been bitten by a few libraries getting unmaintained, a few drastic changes in Phoenix in the first years, and a hard time getting a proper deployment setup, but nowadays is much more mature.

Thanks to Elixir we got away with things like not needing to cache (for quite some time) with great performance and with little resources, not worrying about the app becoming slow if 6 people visit at the same time.

Hiring Elixir developers is not as easy as RoR devs but is doable, I had good experience in Elixir specific places like https://elixirjobs.net/ and Upwork to a lesser degree.

Having done python for many years and coming to Elixir the things that I find Elixir does really well are:

- mix and the general tooling (package management, testing, deployment)

- iex - specifically being able to run a shell at the same time as running my app. It makes it easy to test and explore code from the REPL

- documentation (both in iex and hexdocs) - Navigating Elixir documentation is standardized and easy

- Immutability - it took a while to get used to but now I wouldn't have it any other way

Very satisfied with elixir and the ecosystem is growing! There are some performance concerns if you're doing a large amount of list or string manipulations but these are somewhat special cases and I tend to reach out to a Rust NIF to handle them which resolves the problem.

Somebody posted my post which sums up my experience a while ago[0]. In short: No regret, just make sure you are not building something that can be done twice faster with an existing Ruby library or so. But for a long-term team project, I would prefer Elixir codebase.

[0] https://news.ycombinator.com/item?id=26702222

The only thing I don't like about Elixir is the fact that it doesn't come default on most distros so to use it even for scripting I need to pull strings to get it approved. Otherwise Elixir would replace Ruby for me wholesale

The comparisons to Ruby are a bit superficial. Having written and then torn apart highly abstracted code in Elixir, I would always try to keep my code as low abstraction as possible in Elixir which I need not really do in Ruby. Otherwise I find debugging concurrency problems very difficult (and yes, you can still create many concurrency problems in Elixir). If you are doing single-threaded stuff, there is almost no reason to use Elixir. I do like Phoenix better than Rails, but only marginally

There are things about Elixir I love, most of which come from the Erlang language (esp. their processes and gen behaviors). There are those I dislike (tooling is not where I'd like, tracing to underlying Erlang is hard sometimes).

There are projects where I'd choose Erlang or Elixir (typically M&S or HPC efforts where the processes really come into play, or real-time mission critical efforts where every minute of downtime could cost lives).

Most other projects are based on what the shop I'm in uses, or my personal preference for the task. I'm finding I'm choosing Rust more and more, outside of my day job, which is strictly C++ at the moment (but we're investigating Rust).

I am super happy with Erlang/Elixir, having build and run game backends, Kafka replicators, an ML platform (models in Python) and several social apps over the years. My story is a bit different but maybe interesting to contrast: I used to work with Ruby for years when I switched to Erlang 9 years ago. So for me the syntax was unfamiliar and the actor model was completely new. Elixir and Phoenix where not around so I started with processes, messages, gen_server and the like. I started building an Erlang-process load balancer, learning about mailboxes and supervision in the process. Later I switched to Elixir and felt reminded of the Ruby syntax, really liking it plus new things like the pipe operator. For me the biggest learning that needs to happen (apart from general FP) is on structuring applications. One way to think about it is having long-running micro services within the VM along with short-lived processes for small tasks like serving a single http request. I can see that coming from Ruby today and using Phoenix can give you a cozy feeling where you build stuff without thinking too much about OTP, processes and how the VM does things (scheduling, mailboxes, monitoring, GC, supervision, distribution). And I think that's totally fine unless you want to step outside the framework and really make use of all the things that set Erlang/Elixir apart. So maybe one way to get started today is looking at Erlang first, explicitly because it's unfamiliar.

Corroborate the "some libraries now feel unmaintained" view given elsewhere. Also the language itself and best practise seems to change now quite often and there's a bit of a tendency to do things in multiple ways through shorthand macros which can be a bit confusing (bit of the LISP problem going on here). That said the structure of my code is vastly better than when I was doing everything in Python trying to use multiprocessing and/or threads and/or asyncio.

Two years in, Elixir+Phoenix is an extremely productive setup for me.

So here's my experience as a hobbyist.

I really enjoyed using Elixir when it gained some traction around 2017-2018 and found the language to be beautiful. The documentation is also great. Here's a few reasons why I never kept using it for my own projects.

Most of the time Elixir feels like overkill. It's easier to use Node.js or Golang to create simple services or prototypes. The mental overhead of having to go from an imperative language to a functional one is high. Once I had paid that cost and gotten over the learning curve, I found it exhausting to write and didn't really feel like I was getting a lot of value.

Take BEAM processes and supervision trees for instance. Almost all of my projects are containerized, split into different services, and have some kind of redundancy on top. When I was deploying Node.js projects onto VPSs I almost always used Docker, systemd, or pm2. Once I started working with AWS regularly, I was using ECS and Lambda for everything. The ability to easily create discrete services and have redundancy for those services meant that I didn't really get a lot of value from having this single Elixir instance that is responsible for many things.

Take ETS: when I started using Elixir, I already had years of experience using Redis and preferred it to most in-memory data stores. I tried to give ETS a shot but found myself wanting the Redis API over and over. Thankfully, the Redix library was excellent and had great support for almost all Redis features, but it always felt like I was using Elixir incorrectly by not utilizing ETS.

Some other points that have already been iterated in other comments:

* Packages are very hit or miss. Sometimes a package will only have an Erlang counterpart and coding efficiently becomes harder if you don't know or understand Erlang well

* The IDE tooling is also hit or miss :( It sucks when your IDE starts to freeze or doesn't understand how to autofill certain things

* Environment configuration is kind of a pain. In the beginning it was really hard to tell what the initial starting point of my application was and how to feed in configuration values to those different parts of my app. I wish this part of Elixir was easier.

* Phoenix was just too much. It always felt like a massive framework and I would rather have had something closer to Koa (Node.js) or Mux (Golang).

No regrets, Elixir is a great language running in a rock-solid runtime, with such a nice community around it. Recommend that you give it a try.

I run GetToKnow (https://gettoknowapp.com) on Elixir.

It costs me $50/mo total (app + DB) and I can easily support 20k users across 250 organizations (some of whom are paid).

I'm basically ramen profitable overnight and my overhead is incredibly low. It's essentially pure profit.

With Ruby/Rails this would be at least x4 the cost.

I love Elixir, and personally like to use it for hobby projects, but I don't dare to use it in anything I plan to make a big deal out of. Not because it's bad, but because hiring another Elixir developer would be expensive as hell.

It's an amazing language but it's hard to hire for. I wouldn't want to pay someone the kind of money I get paid for it.

We’re very happy with it, essentially using it as a full-stack front-end though, rather than whole app. This is partly due to resourcing issues, partly due to having an aint-broke don’t fix rails service that Elixir replaced part of (our CMS, specifically). I think the rails service will stay, the benefit of porting is just too low as we’re a small team.

Functional programming is OK up to a certain degree of complexity... Good if you have a lot of junior developers on your team because it prevents certain kinds of mistakes which juniors tend to make. But many FP projects end up becoming a giant pile of spaghetti code eventually.

I think this is because FP doesn't put emphasis on separation of concerns like OOP does. FP advocates separating state from logic as being more important than separating concerns across components.

With OOP, if some piece of state concerns the same business domain as some piece of logic, then they should be co-located. On the other hand, FP will happily violate this principle in favour of keeping state and logic separate.

Having built highly complex, modular systems with OOP, I don't see how it would have been possible to implement these systems in such a modular way using FP... Co-locating related state and logic is absolutely essential to achieve modularity.

I have yet to see any complex FP system which was not spaghetti code.

Inherited a couple projects. Was interested at first, but now dislike it. At this point I think I'm just done with languages that don't have static typing. I hate having to remember or figure out things that my tools should just be able to tell me. Unproductive waste of time & effort.

We're not using it with Phoenix, but I'm also very, very done with RoR—after many years using it and getting sick of how dependably any long-lived RoR project I encountered turned into an onboarding-hell mess of "WTF does this do even? Which gem is this from? Is it from a gem?"—to which Elixir + Phoenix is often compared, so I don't think that would improve my experience.

Nice question, I'm just starting with Elixir for a side project. Has anyone else find it to have a steep learning curve? Coming from Java/Scala and Python, I find it harder to wrap around then Scala was years ago. Shortcuts with mix like mix phx actually make it a bit more complicated for me because I'm used to understanding what is exactly happening under the hood.

I’m about 18 months in, and I’m still loving Elixir.

I like the pipe syntax a lot. I dislike the fake type system, it some how the worst of both worlds. I regret having an elixir project.

I've been using Elixir for 4+ years, and I'm very happy with it. I'm a one-man band, so the talent pool isn't an issue.

My biggest joy is that once you get the application working, it stays working. I have ~20 production nodes, and they all just happily run. This was not my experience with Ruby and Rails.

It's not fun to try to interpret Erlang crash dumps, though.

We're using in a project (through Nerves framework) and slowly walking away from it. Hiring is the biggest hurdle; our product is simple enough that we can just have a bunch of .NET backend developers rewrite everything in Elixir. Hiring a .NET person is simple and cheap; hiring an Elixir dev is impossible where I live.

I work for an Elixir shop right now, and am very fresh (started a few months ago) and this is my first Elixir job.

My first impressions are that Elixir is different, but not necessarily better. Having come from Go, which is a very manual process, Elixir comes with a lot baked in.

With any niche language (which I consider Elixir to be) the benefits don't really kick in until the last 20% of adoption. The first 80% can be done by any language, with very little deviation from the other.

That last 20% is ETS, OTP, and other Elixir/Erlang-esque features, and I don't think 90% of the companies that adopt a language really gets into that level. Kubernetes, Caching, Horizontal Scaling is now so much easier and cheaper to bring in than an expert or the investment into the language that niche languages don't provide all that much value at this point.

I've used it for a few small production APIs, as well as internal TV dashboard things - and it works great!

There are a few business services that I would eventually like to move to it, but I don't have the time or resources currently. (As much as I like it, it's quite a shift mentally)

I initially wrote the backend for my current startup in Elixir, using Phoenix. As many Elixir developers, I'm coming from the Ruby and Rails world. I really enjoyed the language and there are definitely things in Phoenix that are a vast improvement compared to what's available in Rails (changesets are awesome for instance).

However, after some weeks of development, I decided to move the project to Rails. We were still pre-launch so it didn't impact any users and only took a couple of days. The two main reasons for the move were:

1. *Ecosystem.* The Ruby and Rails ecosystem is just so much bigger and more mature. I cannot criticize Elixir for that, I'm just stating the fact. Ruby is many years advance and that shows in the breadth and maturity of libraries and deployment options. 2. *Re-learning basic things.* I found myself needing to learn how to do things in Elixir that I fully mastered in Ruby. I had to reinvent my own wheel in a way. And when you're trying to move fast to get your product out there, this is a waste of time.

In the end, I realized that for my purposes, Elixir/Phoenix is just not 10x better than Ruby/Rails. I can tell that learned from some of the mistakes of Ruby/Rails and many things are better. But they're not drastically better for the project that I'm building, which in the end is a GraphQL backend for a more-or-less CRUD mobile application.

Since the migration to Ruby, I'm much more productive and get things done much faster. I also spend a lot less time learning how to do X or Y. I felt relief when I didn't have to follow the Elixir ecosystem anymore and was able to unsubscribe from Elixir Newsletter and from the Elixir podcasts.

I know that my move does not help my criticism that the Elixir ecosystem is too small. But I value the success of my startup more than the need to help advance the Elixir world.

Maybe we will suffer long-term because of this choice, although examples like Shopify, Stripe or GitHub show that you can maintain massive codebases just fine in Ruby. But at this point of our startup, time to launch and velocity pretty much beats any other criteria.

We tried it and moved away from it. A few reasons - one is IDE support, which has been mentioned in this thread. The other was release configuration. At the time we were working on it, it was more difficult than it should have been to use env variables at runtime (rather than build time).

I'm used to the Spring Boot approach - start with having different Spring profiles for different environments, and then let your secrets come in via env vars, but doing this via Distillery at the time required some hackery - they wanted you to build a QA build and a prod build, which didn't make much sense. Maybe it's better now, but that turned me off a lot to using it.

Here's my relevant post about choosing Elixir: https://lucjan.medium.com/choose-exciting-technology-e735bba...

TL;DR: very satisfied

3 years in and Elixir still rocks!

Very satisfied. Love writing it, and have seen it take root at other companies because devs exposed to it have loved it and taken it with them when they left.

Not exactly on topic, but does anyone have experience with the Akka ecosystem as an option to Elixir/Erlang? I'm considering it for a new project.

My 2c. I was learning Elixir / Phoenix for a startup but found it was missing way too many libraries & lacked the breadth & depth of the Stack Overflow knowledge base as compared to the Ruby on Rails ecosystem.

It was a cool experiment. Most devs would have learnt other Object Oriented Programming languages but learning Elixir would mean switching to a different paradigm.

I use Elixir and don't regret it, but I'm still mostly in Erlang.

I regret "Elixir" the language itself. I feel they should have added a few more features to Erlang, like module parameters, and not bothered with Elixir.

It makes "Erlang" look superficially like Ruby and gets people who are ill-prepared to understand the Erlang mindset into the Erlang community.

I'm a Rails developer and have often wanted to try out Elixir but haven't found a compelling reason (or perhaps, project) to do so yet. Maybe I'll take the plunge and write my next app in it... Maybe get stuck in and try it on your next project too? I'd be interested to hear what you think as we're in similar positions I think.

If this is a personal project, go ahead and try it. See what you think.

If this is a project for a company, then look at the intersection of what they have in-house expertise in running and maintaining and what you know well, and use that. Probably going to be Ruby on Rails if that's your usual thing.

I’ve been working with Elixir for a variety of use-cases for years and I just love it. The only problem we had is the obvious: You don’t have all the libraries you will find in JS or Python. But usually is easy to dig into the oss libraries and create a PR, and the community is amazing!

I don't like the operators' logic in elixir. There should be one for assigning variables, one for pattern matching and there is no rebinding of variables.

Something like:

  //for assignment

  x = 1 

  //for pattern matching 
  x == 1

Automatically translated.

The more I use and learn languages the more I prefer Elixir's (to be honest, Erlang's) programming model. I'm not a types person (yet) so that is not as important to me as the building blocks and how it allows you to organise programs.

I think the first question you should ask yourself is, do you expect the same level of "pick a lib, drop a lib" as you would in RoR, or Nodejs? I haven't had any problem with libs, basically because I'm ok with writing http requests if I need to, or do an auth flow myself - it's not like those things are complex - but the first times it might take you more time than just picking something off that works immediately. On the other hand, the core of what I usually need, is pretty sturdy and extendable - Phoenix/Websockets/Ecto(Postgresql, you might have a different exp with other dbs)/Oban and the standard lib/erlang for all sorts of things that in many languages require external libs (or aren't really doable without taking a sabbatical).

Also I don't know if I live in a parallel world, but in many other languages, even ones with pretty heavy investing, many libraries that aren't just translating http responses into whatever language representation of that, are subpar, or not extendable, or you need to almost learn a new language to use them, they're solving things that shouldn't be a library. There's plenty of good libraries out there, including in nodejs, but comparing for instance its ecosystem is kinda pointless, when perhaps 90% of the libs in there don't really warrant existing, or are to cover basic shortcomings or don't solve really anything, or are specific to being run in a browser.

The second is, are you curious enough about the underlying mechanics and learning the programming model? This is sort of essential, because in most languages/VMs everything is sort of a single program, where all things sprawl from a form of "main()", and in Erlang you organise (or should) your application as many different "main()"s, it's almost like an OS. It's still obviously started from a single point, but once started it's like having multiple applications running in a concerted fashion. There's a curve to learning how to leverage that - and to be honest, not all problems require that - although again, the more I see other languages and use them the more I miss the structured form of programs it allows.

The third is, it's a functional language - if you're not used to it in any way some ways of solving problems might not be apparent immediately - they're not more difficult or complex, they're just different - for me solving problems with OOP is also not straightforward - it doesn't mean it's worse, I just don't practice it as much as I do functional programming. There's also obviously problems that are much better expressible with mutable data, but you have enough scape hatches for those cases that really need it - on the upside there's also plenty of problems that are better expressed in functional languages.

Lastly, some useful patterns and ways of doing things require some "acclimatisation", like using pattern matching to describe functions, conditions, and execution paths, ditching almost completely (almost) exceptions and throws in favour of tagged returns, building reliable sync/async flows etc. The testing history in my view is excellent, as are the tools it includes, mix, iex, releases, and overall I would say it made me a much better programmer. I also would take some people's shitting directly on the language or libs complaints with a grain of salt - I've seen a fair bit of idiotic uses of stuff in it (like holding a hammer by the head), and in those cases ask yourself if the libraries and programs other's use or suggest instead are good software and evaluate them in the same context - complete external tools run by companies vs basic stdlib functionality.

It is hard to find learning resources when trying to write NIFs for BEAM. The documentation and bindings are fine if you are using C, but when using some rarer programming language it can be quite difficult to get along.

I think it's the greatest thing ever. I wrote like 300 words over two blog posts here: https://amattn.com/p/the_sublime_developer_efficiency_of_eli...

tldr:

- It’s quirky - There’s a learning curve - Taking the time to climb that curve can result in elegant solutions - The endgame is high developer efficiency

Not only that, but I find it fun and enjoyable. The ecosystem isn't the largest, but the other positives more than make up for the deficits for me.

I only started learning elixir around November or so last year and I've launched two SaaS products in the past 6 months.

I use Erlang, Is Elixir a better alternative now?

I've been a senior or staff engineer at several companies companies that have their backend tech stacks either primarily or entirely in Elixir. Two of those companies are now unicorns, Divvy (my current company) and Podium. I've seen elixir work great for small teams (~10-15 engineers total) and scale for that company as it went to 100-200 engineers.

Engineers at both unicorn companies consider Elixir one of the reasons they were able to grow the way they did, both in terms of customer count and engineers. Sure, it was hard to find people who had production experience with the language. Didn't really matter; deploy it with Docker (and eventually Kubernetes) the way you would anything else, and if you need clustering then libcluster can manage most of that for you.

Learning OTP is a nice-to-have, but 98% of the time your devs don't actually need in-depth understanding of it (assuming you're a typical web-based startup). Web servers hitting a database is naturally pretty scalable as long as you design your database decently. Scaling your database is _way_ more important to scaling technical systems than your choice of programming language.

Even if your team doesn't need a deep understanding of OTP, _you_ should have a good understanding of GenServer, GenStatem, Application, and Supervisor so you can evaluate 3rd party libs or develop in-house libs. Most devs who are working in product need to focus more on how to write well-factored code to interact with data services like Postgres, Redis, or Kafka.

Yeah, there's a lot of hype around hot code loading, ETS, Mnesia, and the like. Don't use them unless you absolutely have to. ETS is fine for a local cache once you have a generic garbage-collector as long as you don't care about losing that cache on deploy. You probably care, so just use Redis most of the time.

The claim that it's impossible to hire Elixir devs is way overblown. Just hire smart people; software engineering principles are applicable across languages even if the languages have different paradigms. You might have to find new ways of implementing those principles, but discussions around good boundaries and extensible code are more important than "when should I use if vs case vs cond vs pattern-match in a function head?". Podium hired a _lot_ of engineers right out of dev bootcamps. They paid for that in code quality for sure, but even the most green engineers were able to get going in Elixir pretty quickly. As long as you have one or two "seed" engineers who are willing and able to teach others, the hiring problem isn't really a problem.

I'll get a lot of flack for this one, but if your company has a monolithic codebase, Umbrella Applications are a great way to enforce internal boundaries if you're on Elixir 1.11 and have warnings-as-errors set up. Keep splitting any sub-apps that start getting large and the warnings-as-errors will prevent circular dependency hell for you.

If you're doing a service-oriented or microservices architecture, Elixir is pretty great. Synchronous communication is pretty easy to set up if you want synchronous communication; Absinthe makes a great API gateway, gRPC support is decent on both the client and server sides (though testing still needs to be improved with the gRPC lib...)

If you're using plain ol' HTTP, there are a plethora of HTTP client libs that scale well (and a number that don't without effort - some painful lessons at Divvy on that one). Phoenix is a great HTTP server framework, and LiveView is great if you don't want your team to have specialized frontend vs backend devs or get an MVP off the ground.

Kafka support is... fine, I guess. As long as you only need basic Consumer/Publisher capabilities, anyways. If you need anything more advanced, you have to go somewhere else to get the stateful processing capabilities that Flink or Kafka Streams or KSQL will give you.

Redis support is good, with varying options for high-level vs low-level implementations.

The hardest part of working in the ecosystem is the ecosystem itself. The built-in tooling is amazing, but Ruby/Java/JS/<insert other top 10 tiobe language here> will always have a larger selection of libraries.

Happy to have stayed away from it ever since.

This question reminds me of a story about Yahoo! Stores, which came out of Yahoo!’s acquisition of Viaweb, cofounded by PG. As he has frequently mentioned, Viaweb was written in Lisp and he felt they got an inherent advantage by using Lisp [0].

Several years after Yahoo! acquired Viaweb I was having lunch with the then-VP in charge of Stores and other business products, who was not from the original Viaweb team. The Yahoo! team was rewriting Stores in C++ (and Perl, apparently from a current Google search, although I only remember him mentioning C++). He kind of rolled his eyes when he said for some reason the original team wrote it in Lisp. He said it was hard to hire Lisp programmers to join the team.

PG was not well-known yet, so even if we could just search the web to find his reasoning for using Lisp (the article was written in 2001), we wouldn’t have thought of searching. But even if we had found it, I don’t think it would have mattered. There’s a different set of advantages and tradeoffs for a small team building a new product, when they are focused on fast development and growth and they come from a similar background, vs. a team in a larger company that has people coming and going and wants the ability to hire from the general developer pool without having to train everyone on a less-common language.

Disclaimers: this is a generalization, of course. You might be able to point to counterexamples. Some larger companies are more willing to hire language specialists and experts.

I’m just relaying what I was told. Please don’t angrily debate me on the benefits of languages like Elixir and Lisp. Your anger would be misplaced. Personally I absolutely love those kinds of languages and would much, much rather use them than something like Java [1]. That’s why I stayed a hacker my whole career and never became a manager.

[0] http://www.paulgraham.com/avg.html

[1] http://www.paulgraham.com/javacover.html

Any comments on BEAM as it pertains to security? Is it ripe for being picked apart for vulnerabilities? Could these be exploited remotely via Elixir/Erlang web applications?

My advice, not that anyone is asking, is only do Elixir if you love it. If you are doing it expecting it to become the next Node thats definitely not happening.