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

387 points by sdiw 5 years ago | 287 comments

I'll be starting to work on a new project from next month and I've been reading all but good news about Elixir. I have talked to people in real life, most of the devs had positive things to say about it. Does anyone have any arguments against selecting Elixir? Question coming from RoR developer.

midrus 5 years ago |

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.

pmarino90 5 years ago | |

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

I am using VSCode too and the experience is not as good as with Typescript/Javascript but is not that terrible either. I would compare it with Rust's experience, so far.

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

Of course you need _other_ libraries to achieve some of those things. You do not have a queue built it but there are some very good tools like Oban https://github.com/sorentwo/oban that are basically doing what Sidekiq does, just relying on the main database you are already using. There are also very good libraries for caching that rely on ETS and that simply replaces what you could do with Redis.

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

This is partially true. The ability of BEAM to cluster and execute processes inside the cluster, internal communication between actors and so on are not _just_ achievable with k8s, not without a good added complexity.

benwilson-512 5 years ago | |

> Specially now we are using all the hotwire stuff.

Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view?

I do agree that some of the "you don't need redis" and similar are overblown (particularly claims about tasks replacing background jobs), but I think there is truth to these claims in the following sense: Particularly in Rails, Redis gets used not just as a tool, but also to manage shortcomings in the language / runtime. Eg: Hotwire. Ruby doesn't have a good way to concurrently manage stateful connections, so it has to fallback to Redis. Ruby doesn't have a good way to manage inter-process or inter-node communication, so once again Redis steps in to fill that gap.

There's nothing wrong with using Redis, it's a fantastic tool. Using it as a state holder for an event loop through ends up feeling extremely convoluted after you've written a few GenServers (Phoenix channels / liveview).

midrus 5 years ago | | |

Liveview (as well as stimulus-reflex) promote minimal JavaScript by trying to push most interactions to the server, and let the server decide what should change in the frontend. So for example, to show a modal, you send an event that signals the user wants to show a modal, so the backend sends back the html for the modal. You click to close the modal, this sends an event to the backend, the backend sends you the diff or the instructions to remove the modal from the dom.

In the hotwire world, the encouraged approach would be to already have the html in the dom, and use a stimulus controller to show or hide it [1]. And you only issue backend calls when you really need to reach to the backend anyway (like submitting a form, or refreshing some actual content). You don't call the backend just to signal a button was clicked so that the backend removes html if you can already do that in the frontend. Hotwire is not about avoiding JavaScript, hotwire is avoid organizing it well and reducing the amount you need.

Of course you can do things wrong on both approaches, but it is what one approach promotes vs the other.

As an example of why this is a problem, see this [2] example. I'm in Europe on a fiber connection, and clicking in one of the calendar days, and closing the modal feels just so terrible....

[1] https://tighten.co/blog/stimulus-101-building-a-modal/ [2] http://expo.stimulusreflex.com/demos/calendar/2021-05-01

ecmascript 5 years ago | | |

The trick is to use liveview for data that needs to come from the server anyway. I'd guess that the OP did use it for everything, like popups etc and did not do the same with hotwire.

nickjj 5 years ago | | |

> Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view?

There's an open GitHub issue on LV which mentions when using live_redirect you're paying a very large penalty in page load speeds due to extra latency being introduced by LV: https://github.com/phoenixframework/phoenix_live_view/issues...

Before this issue existed my non-scientific impression was the same. There was something that felt off when using sites that primarily used LV for navigation and loading content. It always felt like I was clicking, waiting a noticeable amount of time and then the content would appear -- even with a decent ping time (< 100ms).

I never experienced that type of delay when using Turbolinks and now Hotwire Turbo with comparable ping times to a server.

joelbluminator 5 years ago | | |

Those advantages are really overblown and not worth the hit in missing libraries or missing hires.

josevalim 5 years ago | |

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

For what is worth, that's one of the reasons why Elixir exists in the first place. I find the Erlang VM a fantastic platform and there is no reason to restrict it to high availability/distributed scenarios. Elixir developers should be productive and write performant and maintainable applications, even if at the end of the day they are just pushing to Heroku. Especially if you are coming from another dynamic language, such as JS/Ruby/Python.

As I like to say, in the "worst" case scenario, you can use Elixir as you would any other language, and that's completely fine!

If you want/need to go deeper, the abstractions are there to do so, and that's the difference compared to K8s: it is happening one layer inside. The high-level principles of redundancy and availability exist at the library level, so you can look at your connection pool, message queue, http clients, and find the same ideas there. Another area where K8s directly complements Erlang is in helping establish clusters. Overall, they are rather working together rather than stepping on each other toes. I wrote more about this here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...

whalesalad 5 years ago | |

I am bummed out to see that this is the top comment. I don't doubt your experiences but I hope that other people do not latch on to this and use it as a strong argument against using Elixir. All of these complaints are skin deep and kinda petty, to be honest.

> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains.

This is a bizarre criticism of Elxir the language. There are a lot of developers out there who prefer a more lightweight editor and do not want the bells, whistles and crutches of a heavy duty environment. I would never complain about a language just because an IDE does not exist for it.

Tooling in Elixir is really some of the best I have ever used as far as the consistency had with mix, hex, hexdocs, etc...

> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier.

You can still use all the same battle tested tools with Elixir... but it is true that there are lots of situations where those things are genuinely not needed thanks to some of the things that come out of the box on BEAM.

ncallaway 5 years ago | | |

> This is a bizarre criticism of Elxir the language. There are a lot of developers out there who prefer a more lightweight editor and do not want the bells, whistles and crutches of a heavy duty environment.

Right, but...there are also developers out there who do want those things.

It feels very dismissive to dismiss a complaint like that as "petty" just because there's a set of people who don't have the same needs. I feel like it's a very useful piece of information about the language that doesn't feel at all petty to me.

If you don't want the IDE-like tooling, then you can read the comment and think: "ah, they want more tooling than I do, so this critique doesn't apply to my use-case". If you do want that style tooling, then you might read the comment and think: "Ah, that's good to know. That applies to me, and I'll definitely take it into consideration".

Someone having priorities that are different from you doesn't seem "petty" to me. It just seems...like different priorities.

pavel_lishin 5 years ago | | |

Don't focus on tooling, focus on their complaints about not having enough senior engineers familiar with the language.

We're in a similar boat. I don't know the full history of how we came to use Elixir, but I would wager that early on in the company, someone really loved it and evangelized it. But now, we don't have that many senior people who know it well. I can count the ones I talk to regularly on one hand, and once I run out of fingers, I'm probably sixth place runner up, which makes me very uncomfortable.

That's why I wouldn't suggest Elixir. Unless you're incredibly sure you won't have significant churn for the lifetime of your business, or have money to burn specifically hiring Elixir folks, I wouldn't recommend it.

cy_hauser 5 years ago | | |

> I would never complain about a language just because an IDE does not exist for it.

I think their complaint is valid, especially in light of their finding it difficult to find experienced coders who are in their salary range.

New coders can lean heavily on a good IDE to help: code completion, breakpoints, step wise debugging, one click links to the docs, easy code navigation, and more. Senior coders can and should use the editor of choice, but a great IDE makes a world of difference for a junior or even intermediate coder.

lbhdc 5 years ago | |

I worked on an elixir project at a ruby shop for about a year. We had complex distributed system, and were replacing core ruby services with elixir. Ultimately the project was a failure, and was re-re-written in Ruby, and the Elixir devs were let go.

We faced similar issues to you, bad tooling, weak libraries, and very few knowledgeable devs.

Finding people to hack on elixir was extremely difficult, and likely the driving force that killed the project. Having an inexperienced team who had no experience with many of the language features elixir offered created a very difficult to work in code base.

This killed productivity, so management threw resources at it. Code quality dropped further when we were no longer just a group of noobs interesting in hacking on elixir, and became a group of noobs begrudgingly hacking on elixir.

I feel pretty scared from the experience, and wouldn't be interested in using elixir professionally again. Which is a shame, it can be a nice language to write, and some of its tooling like hex is quite nice.

joelbluminator 5 years ago | | |

I think new languages wont be able to break in the top 10 without a mega corp pushing them. The market is too saturated and there is a language for everything under the sun. Elixir is just facing too much competition for web stuff and doesnt enjoy Google pushing it.

abledon 5 years ago | | |

thank you for sharing, I am removing elixir from my resume after reading all these comments haha

minhajuddin 5 years ago | |

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

Can you give some examples here. This may have been true in the past, but isn't true anymore. I can give an example where ruby is lacking: Performant HTTP libraries, Elixir and Erlang are so good in this space, look at `finch`, `httpoison` etc,. there is first class support for HTTP2 and connection pooling / persistent connections which is very hard to find in ruby.

Which plugin are you referring to? Is it using dialyzer? Using dialyzer gives you so much static analysis for free as opposed to the default ruby vscode plugin. I have never heard of complaints about tooling. On the other hand, I know lots of developers who love the tooling, mix is great, iex gives you documentation with just `h String`. Plus with language server support, you have really good IDE support in vscode and vim. Look at the number of stars on the `ElixirLS` plugin here: https://marketplace.visualstudio.com/search?term=elixir&targ...

Yes, you'll lose data in your cache. Caches are supposed to be ephemeral, not everyone needs their caches to be persisted. However, if your use case requires persistence, you have a lot more options than just sticking it in redis. Plus, `oban` is a high quality background processor with persistence, without the need for adding redis to your stack.

For applications where performance matters, Elixir and Erlang give you lots of tools to build a truly performant app, However, if you don't need those tools, you might be better off building it in something more familiar.

pavel_lishin 5 years ago | | |

> Using dialyzer gives you so much static analysis for free as opposed to the default ruby vscode plugin. I have never heard of complaints about tooling.

ctrl-f for "dialyzer" in this thread, and you will :)

hgershman 5 years ago | | |

I love Elixir, but even I have to say that the tooling story in IDEs is awful. Using VSCode, ElixirLS is the best extension I've found so far, but even the experience with it makes me want to ditch Elixir entirely more often than not (and no, the number of stars on VSCode marketplace means nothing).

The extension will often just lock up, either giving you no autosuggestions/errors, or refusing to remove errors that you've already resolved, and the only way to fix it reliably is to delete the .elixir_ls/ folder and/or completely close and restart VSCode, both of which require rebuilding the entire dialyzer which is a constant battery killer on laptops. This is such a frequent issue that some days I find myself having to quit/reopen VSCode at least once an hour, and despite spending absurd amounts of time trying to find a long term fix, I've never found one.

Not to mention the issue that has been open for 8+ months where ElixirLS is built using an older version of Elixir, and if you are using a recent version of Elixir for your project (anything newer than 1.9), some of the core functionality of ElixirLS just breaks (autocomplete and hover tips). That issue alone makes me want to ditch ElixirLS (and likely Elixir) entirely.

joelbluminator 5 years ago | | |

The Ruby community is 4x bigger than Elixir and I am being generous to Elixir, and even Ruby is considered smallish.

jswny 5 years ago | |

It astounds me how much I hear about the “VSCode extension uses all my CPU” thing.

Yes, the extension uses a ton of CPU for 15 minutes the first time you set it up. It’s building a giant database for type information to give you type checking and hints.

It does this ONE TIME when you first set it up. It explains this. It’s really not a big deal. I’ve found the extension to be great, I’m not really sure what you are referring to there.

hgershman 5 years ago | | |

It isn't just "ONE TIME" for me. The extension freezes up often and completely stops giving autosuggestions or warnings, and the only way to fix it is to delete the .elixir_ls file and rebuild the database. When I say "often", I mean there are some days where I have to do that at least once an hour, and 5-15 minutes of high CPU usage every hour is just way too much to be acceptable.

I love Elixir and the ElixirLS extension is the best I've found so far, but that's not saying much. The extension has enough issues with it to make it very frustrating to work with, and even enough to make the entire Elixir experience not worth it in many cases.

pera 5 years ago | |

I strongly disagree with your generalisation regarding the tooling: Mix and Hex are without any doubt some of the most pleasant tools I have ever used. (I personally don't care about IDEs so can't comment on the lsp implementation or idea plugins)

fastball 5 years ago | | |

> complains about tooling in IDEs

>> I strongly disagree (doesn't use IDEs)

poisonta 5 years ago | |

In addition to that, I struggled to find a well maintained library similarly to Devise. Also, many people won’t agree to me, but Ecto is also a kind of pain. I think Phoenix would have been in a better position if there were libraries like ActiveRecord and Devise.

subbu 5 years ago | | |

I struggled with Ecto. It seemed too complex. I missed find_by_sql and the scopes of ActiveRecord. But once I went past the initial learning curve Ecto is a seriously well designed library. I have not written a single sql query by hand. Now I feel find_by_sql is an anti-pattern as I was mixing sql with ORM.

Once your database becomes sufficiently complex you start writing a lot more sql.

ActiveRecord's way of chaining scopes to combine multiple scopes is brittle. You can't customize the conditions. Ecto solves this by giving you composability. You can build on top of your earlier commands. If you combine this with pattern matching in the functions or Enum.reduce you have an extremely powerful and a flexible query engine.

Ecto also relies on the strengths of underlying database engine rather than treating it as a black box. If you are dealing with 100s of tables Rails way of polymorphic design doesn't give you referential integrity. I like Ecto's recommendations: https://hexdocs.pm/ecto/polymorphic-associations-with-many-t...

hnedeotes 5 years ago | | |

Probably there's no one in the Elixir community with enough know how to build a Devise-alike lib, it's what it is.

cultofmetatron 5 years ago | | |

I've been able to drop in pow with ease and have everything I would have gotten from devise.

That said, the community is moving towards phx_gen_auth which jose himself wrote and will come out of the box with 1.6

jerf 5 years ago | |

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

I used Erlang for 5-6 years in a production environment in a deployment that wasn't the world's biggest, but did seriously need clustering because we needed more than one machine to handle the load, not just redundancy. This comment leads to my core observation about the entire ecosystem for anyone considering using anything in the Erlang ecosystem.

Erlang started in the late 1990s. Joe Armstrong was brilliant, and I would imagine was also surrounded by some other very smart people whose names I do not know. Despite what I'm about to say, let nothing I say be construed as disrespect for either the language or the people making it.

Let me set some context here. C++ ruled the day, and still looked to inevitably replace all C. Python, Perl, and the entire dynamic scripting language category had just been invented. Java was in the news, but not on your computer yet. Haskell... pre-monadic IO... had just been standardized somewhere in here. Threading was possible but was every bit the nightmare it has been presented as, and you had to be careful spawning more than single-digit threads because of the resource consumption. Open source was just beginning to be A Thing... that is, it had existed in its embryonic form for decades, of course, but it was just beginning to cohere into the Linux world we know now. Machines were still measured in the hundreds of megahertz and the single-digit megabytes of RAM.

Erlang was a far more radical departure from anything else in this era than it is today. There was a lot of academic work on this stuff, and there was a lot of very specialized high-end work on multiprocessing, but it wasn't being done by "mere mortals" and it wasn't very simple. Erlang's designers looked out into the world, and what they saw was a huge jungle, where what maps we had had huge regions that just said "Here There Be Dragons". And they started in, hacking and slashing and slicing their way through, guided by a few intuitions and a whole lot of engineering firepower.

And they largely succeeded in creating a settlement in the wilderness. They grew and managed to pave over the hack & slash paths into roads, built a community, built a pretty incredible VM, built an ecosystem around them. Let this accomplishment not be underestimated; this is a land that had eaten many others in that era.

However, sitting here in 2021, this is no longer a wilderness. Much of the area has been razed, highways driven through it, McDonald's by every exit, and millions of people living here in various bustling metropolises.

And I think what we've found is that where Erlang plopped itself down is OK... but not more than that.

As a consequence of its isolation, Erlang bundles a lot of things into itself that just didn't exist back in the day. It bundles in messaging passing and a network-aware message bus, almost literally decades before anyone else even thought of a "message bus" as a distinct product segment. (i.e., they existed, you could find academic discussion and some early passes at it, but it wasn't really a distinct category yet.) It has a threading environment. It has these "supervision trees" idea which are cool. It has immutability at a time where Haskell was even crazier than it is now. It has a mechanisms for bundling and distributing applications. It has this entire alternate-reality ecosystem in it. But...

... in 2021, none of these are best-of-breed anymore. Many of them are deeply quirky. Immutability is cool, but we only needed to not be able to pass mutable references on the message bus, not be fully immutable within an Erlang process. I believe Elixir fixes this one. A modern message bus going between processes gives you this whether you like it or not because it also can't carry mutable references between OS processes and systems. Having a message bus integrate into the language is a big mistake, because it makes it hard to hook up anything but Erlang nodes to Erlang. (I say "hard" and not "impossible" because I know it can be done, but it's hard.) A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one. Process restarting is a necessity for production-grade systems, but we've settled to a large degree on OS-level handling for restarts, and within a system, there are easier ways to accomplish the goal than bring in the entire Erlang supervision setup. Mnesia, a clustered DB was a neat idea, but in 2021 is so poorly featured and unreliable it doesn't even qualify as one anymore; nobody in their right mind would bring up an Erlang cluster just to back some other language's code to Mnesia as a database. Pattern matching is cool, but not cool enough to justify all the other issues that come with it, and proper use of other language functionality is often good enough anyhow. (I don't tend to miss it; I tend to properly use some form of polymorphism instead. Trivial pattern matching is replaced by this, and to be honest, non-trivial pattern matching is probably a code smell if not an antipattern; if you're reaching three levels down into a data structure, you know too much about that data structure!) Modern Erlang performance is meh; it used to have the clear advantage when dealing with lots of sockets but now there's a lot of things that can comforably exceed it. Its type system is an annoyance even by dynamically-typed standards, if you like static types than just stay away. (They will cite Dialyzer, but it isn't anything remotely resembling a replacement.) And if I reviewed the docs I could find a few more of these, plus I find there's a lot of cases where Erlang has solutions to problems only Erlang has in the first place, e.g., "gen_server" is neat, but the entire gen_server set up, with its initialization phase and its three proscribed ways to call it and the need for an explicit "gen_server" module type are largely the creation of Erlang in the first place... in other languages you generally get the functionality packed up differently but it's all there without having to exactly match what Erlang does.

So, in 2021, the problem is that going into the Erlang ecosystem tends to lock you into a whole package of things that vary from "not best of breed but mostly OK" to "significantly inferior to the modern alternatives". All it really has is very nice integration of its not-best-of-breed stuff, but even that kinda becomes a trap after a while, like when you realize you need a real database after all, then maybe you have to integrate with another message bus so you can integrate with non-Erlang code, and, you know, a couple more cycles around that loop and you'll really regret having chosen Erlang.

One thing that I think it has going for it, and why it's probably still got a cult following today, is that if you're a relatively new developer, or not experienced in network programming, it is a heck of a trip when you get into it, because the tutorial will introduce you to half-a-dozen ideas you've never seen before. Cross-server message buses? Amazing! A network database with an easy API? Amazing! Spawn a million processes on a commodity box? Amazing! I think this explains a lot of the appreciation it gets today. But no longer are any of those things unique. It's just that the normal developer lifecycle will tend to encounter those, one at a time, over the course of years, instead of having them all thrown at you in one amazing, mind-blowing language introduction.

But in 2021, you can do not just "better" than Erlang for all of them, you can do much better. Except that whatever you put together will be something you had to put together, and it won't be quite as nicely integrated. But it will allow for multiple languages, it'll allow you to better integrate with the direction modern ops is going, it'll scale better both internal to your language and in terms of performance, and you'll be better able to hire for it.

The Erlang ecosystem was brilliant and far ahead of its time. I honor it as an incredible pioneer and recommend, even after everything I said, that anybody thinking of writing some incredible new language spend some time in the Erlang ecosystem to see some of what is possible with that sort of integration. But I can't in good conscience recommend it, in either its Erlang flavor or its Elixir flavor (or its Lisp flavor or anything else) to a modern developer. Everything Erlang does is much better done now by other things, minus the language/ecosystem lockin. This is not because Erlang lost, it is because it to a large degree won. It blazed a trail, and we all now agree, it was a trail very worth blazing. But the next waves of settlers & builders ultimately have created something better.

klelatti 5 years ago | | |

> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better.

Really appreciate the effort that you've put into this post but it's 99% saying you can do better but without examples of stacks that would be better. For those who don't have your knowledge could you provide some examples?

jolux 5 years ago | | |

I'm confused by the extent to which you believe the things that Erlang/OTP and the BEAM do have been entirely replicated by other ecosystems. I think you're quite right that distributed systems engineering and threaded programming as a whole has moved in the direction of Erlang on a lot of fronts, but I don't really see the parallels (no pun intended) at the language level. Most popular languages still depend on cooperatively scheduled threading models (even async/await depends on the dev inserting yield points), while the BEAM's does not.

Ndymium 5 years ago | | |

> Immutability is cool, but we only needed to not be able to pass mutable references on the message bus, not be fully immutable within an Erlang process. I believe Elixir fixes this one.

In fact Elixir does nothing for this. It is true that in Erlang, you cannot rebind a variable and must use a different variable name for every assignment. In Elixir you can rebind the same variable, but the data is just as immutable as in Erlang, and the rebind is only visible in the current scope, which trips up new programmers not used to it.

svrtknst 5 years ago | | |

Erlang started in the late 80s and saw production use roughly 95

hnedeotes 5 years ago | | |

I think that it would be helpful if you provided examples about those things, good and bad. As it is it's mostly "erlang's" bad - perhaps if you offer the counterparts to what would be a better pick we could have a discussion - and then perhaps see how far the tree of dependencies goes on each side? And also what you would loose by picking up those solutions?

Just taking on some random stuff:

> Trivial pattern matching is replaced by this, and to be honest, non-trivial pattern matching is probably a code smell if not an antipattern; if you're reaching three levels down into a data structure

If the data structure is being accessed in a module to deal with it specifically then that is part of the knowledge of the module. And you can't escape that with or without pattern matching, since you'll have to codify those things in code anyway, be it long chains of ifs, switches, or whatever, you'll always have to write the code with the same level of knowledge about the data structure to express the same conditions?

> Modern Erlang performance is meh;

This I'm not sure. I've seen libs written in elixir beat libs written in C++ and they had to start a VM to be run. Obviously there will be plenty of stuff that a low level language can do more efficiently and faster I don't think anyone disagrees with that - but I think sometimes people sell erlang and elixir's speed short.

> but the entire gen_server set up, with its initialization phase and its three proscribed ways to call it and the need for an explicit "gen_server" module type are largely the creation of Erlang in the first place

I haven't seen any language with the concept of an independent program, that has a synchronous interface (mailbox), but can be modelled entirely asynchronously, and can't block whatever running loop. (and I read your other reply and thread). There's also a reason why some things have a particular way of being set up inside the beam, and that's mostly related to the guarantees it provides and with the fact that processes are transparent across nodes. If you take out the impossible to block scheduling and network transparency you'll be of course able to spin up something similar to a GenServer without the same "ritual" - but it no longer has anything to do with the former perhaps except its API?

> A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one.

Given that you can have any socket, tcp or not, and easily handle it, this doesn't seem to be a fair point. On kafka or any other message bus the implementation language will be that of the sources and sinks communicating with kafka? Or you just write kafka and the other programs wake up as insects in a bed?

> Mnesia, a clustered DB was a neat idea, but in 2021 is so poorly featured and unreliable it doesn't even qualify as one anymore; nobody in their right mind would bring up an Erlang cluster just to back some other language's code to Mnesia as a database

I haven't used mnesia at scale and indeed heard people complaining about it, more than once so there's probably some issues there - having said that, in terms of similar db's (KV based and not SQL,etc) even db's like MongoDB and such need expensive and usually paid managing solutions right? And can still loose data unless you really cover your redundancy?

> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better.

Could you tell us succinctly how? As a, usually, solo developer I would be really interested in knowing, and I'm not asking sarcastically.

I also don't understand how it's difficult to integrate Erlang with other things, it basically has a standard lib very accommodating of sockets and inter process communication through STDIN/OUT, with effective monitoring on top.

midrus 5 years ago | | |

Can't upvote this enough

carlosf 5 years ago | |

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

Yeah, last time I tried to get a hang in Erlang I felt it was trying to solve stuff that is already being solved by my infrastructure in a language agnostic way.

svrtknst 5 years ago | | |

I'd say it's rather the other way around. Your infrastructure now solves what Erlang did 25 years ago.

Not to argue your point, though.

srivathsaharish 5 years ago | | |

they are not the same kind of concurrency model though

bennyp101 5 years ago | |

"There is no IDE from jetbrains" Is that now a thing that is important? I've only just started using an IDE from them - and I don't see how it's miles better than say vscode?

This whole thing sounds very much "ruby good, elixir bad"

syspec 5 years ago | |

That's my main blocker, proper JetBrains IDE support just makes everything so much easier. I need a debugger.

I tried the plug-in, and kudos to the author but it did not work for me. In the end they're only one person so of course they could not test every single configuration

I wonder why JetBrains has not put their weight behind it.

29athrowaway 5 years ago | |

Rails is very productive but it has problems of its own. Many companies move away from Rails once they reach certain growth milestones.

Erlang (and by extension Elixir) is a concurrent language. You use it when you have non-trivial concurrency challenges. When tackling the right problems, the language shines.

Implementing a simple CRUD application with Elixir is overkill, because you can make your servers stateless and delegate most of the concurrency problems to the database.

midrus 5 years ago | | |

In my personal experience (the last bunch of companies I've been at) that milestone you mention is more like what is the current fashion and what the new hires want to work on because of the latest blog post they've read.

At my previous job we had *ALL* of them. Each service or project you opened you could guess the date it was started because of how it was built. Rails -> Node -> Elixir -> Go -> Next.js and the frontend backbone -> ember -> react (redux -> mobx -> rxjs -> [some other random state lib] -> just context! -> recoil) -> typescript and probably by now they're already using whatever the new trend is by this morning. It is insane.

None of the companies needed any of the performance provided by this tools, in fact, they all struggle with developer productivity more than any other metric, and every time they switch to the new shiny toy, productivity takes another huge cut. But hey, people get paid anyway at the end of the month, so let's keep playing.

joelbluminator 5 years ago | | |

I really don't see any reason to move from Rails other than a new CTO trying to shake things up with a tech he's more familiar with. If Shopify/Github/Gitlab/ can build it on Rails so can you. If the monolith is too big you can break it down with engines or to separate apps. Now I like Rails but I would say the same about PHP/Node or most popular stacks. Rewrites to another language are almost always unnecessary.

digianarchist 5 years ago | |

Just on the hiring point. There are three companies to my knowledge using Elixir in Toronto. I applied at two and the responses were 1. Not enough professional experience using the language. 2. Very low salary expectations on their end. Pretty bad for Toronto but especially poor for hiring in what is essentially a niche language.

joelbluminator 5 years ago | |

Rails is awesome nothing comes close to being as fun and productive. Tried php and django, not bad but not Rails.

midrus 5 years ago | | |

Can't agree more with this. I've used both, Rails since a few years ago and Django for about 8 years or so, and while I still like Django I think rails is far, far superior in every aspect. The only thing I like more from django is the migrations system (not even the ORM, just the migrations) and maybe the admin as a tool to browse the database. Other than that, Rails all day.

nickthemagicman 5 years ago | | |

Have you tried Laravel?

Asking because I'm just curious about the comparison between the two

srivathsaharish 5 years ago | |

ah, well, another ruby or python enthusiast trying to avoid other models of concurrency at all costs

pmarreck 5 years ago | |

oh boy. where to begin

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

joelbluminator 5 years ago | | |

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

That's really inaccurate, not everyone is remote and looks like post COVID most companies will be hybrid office/remote. So hiring is still a problem, and getting hired is a problem for people who don't want to be 100% remote.

> "We can underpay cheap devs again"

I don't think Rails devs are particularly cheap though I'm not sure if that's what you meant.

> mutation bugs, monkeypatch bugs, and concurrency bugs (just forget running your test suites in parallel)

Rails comes with parallel testing since Rails 6. As for concurrency - I know that Gitlab moved to Puma (a threaded webserver) and tons of huge companies use Sidekiq which is threaded as well. I'm not saying there are never any problems but it seems to work well for many many companies.

louissm_it 4 years ago | | |

I’m sitting in Africa and I can whisper “Elixir job” out my bathroom window and have 10 people interested in it. Maybe it used to be difficult.

dudul 5 years ago | |

Can you name a few of the libraries you didn't find?

airhead969 5 years ago | |

Erlang and Elixir ecosystem has a bunch of unmaintained throw-away projects.

I wrote a bunch of Erlang and Elixir tooling before I realized the most useful projects were thrown over the wall FOSS codebases.

If it's stupid and it works, it's not stupid. Fashionable is for runway models.

dorian-graph 5 years ago |

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.

klohto 5 years ago | |

I see that you're hiring. Are the positions remote as well or strictly London?

dorian-graph 5 years ago | | |

Admittedly it's more or less London-based at the moment, unfortunately! Which timezone are you in?

phtrivier 5 years ago |

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.

samgranieri 5 years ago |

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.

gamache 5 years ago |

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.

atonse 5 years ago |

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.

aczerepinski 5 years ago |

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.

dpeck 5 years ago | |

Looking for increased pay based on programming language used is going to lead to disappointment more often than not. The best thing that anyone can do to increase their compensation is be aligned with a business, or part of a business where they’re a profit center vs a cost center. The language itself is more about a persons preference and the things that you value as far as day to day working experience.

devoutsalsa 5 years ago | | |

I thought of this as working at a tech company on a core tech product for a technical manager in a tech role. But working as a developer for a profit center is more concise.

devmor 5 years ago | |

Interesting, I've had the opposite experience. I get paid a ridiculous amount for Elixir work because finding experienced Elixir devs is so difficult. Most of the job offers I get for it I avoid because I think "there's no way this company is going to last longer than a year paying that much for developers".

andruby 5 years ago | | |

I'd love to know what the going rate is for experienced Elixir developers. I'm interested because I'm toying with a side-project and can still choose the stack after the prototype, and I'm also a developer that knows both Rails and Elixir.

shdh 5 years ago | | |

Care to share get actual salary and location?

grumpy-de-sre 5 years ago |

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

devoutsalsa 5 years ago | |

Yeah, I concur. If you’re a ops infrastructure let’s people deploy whatever ever they want in a container, and you can make the devs debug the elixir specific code, then you should be ok. If t try us devs force having to understand Erlang releases, GenServer timeouts, and Ecto based macro errors onto the ops group, everyone is gonna have a bad time.

SZJX 4 years ago | |

Haha I'm not sure if we know each other since I know the issue you describe in this link. Regardless, I think this is a somewhat weird example since the it should not be DevOps' duty to look at and try to understand an error that stems from Ecto. And our company did face this issue, but this was largely related to the DB optimization and the Postgres instance instead of anything language-specific. If you have bad DB schemas and optimizations you're gonna face the same issue no matter in Java or Go. Saying that you've "never had a more challenging system to debug and keep running" sounds really dramatic as our Elixir apps have been running fine 99% of the time and barely even triggered any on-call incidents.

1_player 4 years ago | |

> I've never had a more challenging system to debug and keep running.

Heh, the core system I put in place at work 3 years ago and is updated daily has never gone down once. Isn't that the point of the BEAM and supervision trees?

It's different, requires to learn a new skillset, but I wouldn't call it "challenging to keep running."

stefanchrobot 5 years ago |

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

cdaringe 5 years ago | |

"Installation - Caramel Manual" https://caramel.run/manual/getting-started/installation.html

methyl 5 years ago | |

Hey Stefan, nice to see you here :)

scottmessinger 5 years ago |

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

delta1 5 years ago | |

Another vote for ElixirLS, I haven’t had much issue with it.

mercer 4 years ago | | |

for me it works okay-ish.

I still have to occasionally grab my laptop to keep its fans from taking it airborne, it still crashes occasionally, requiring nuking .elixir_ls (and holding onto the laptop again), and while it hasn't happened recently, I've had situations where I'd get weird errors for code that should be fine, also requiring me to delete .elixir_ls to get rid of the warnings.

That said, I don't really mind, but then I perhaps don't care as much about IDE-ish features. I've also been doing more and more work inside LiveBooks, and those don't even have vim keybinding!

mattbaker 5 years ago |

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.

toolz 5 years ago |

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.

bandris 5 years ago |

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.

optimuspaul 5 years ago | |

this. I had piloted a project in Elixir a few years ago. It wasn't until I really learned Erlang that it became a pleasant experience. In the end it was replaced by another team in another language.

joelbluminator 5 years ago | |

> If you invest time learning Erlang everything around Elixir will make sense

But this seems like a big issue to me. It probably makes the learning curve high if u basically need to learn 2 languages.

bluevlah 5 years ago |

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.

justsomeuser 5 years ago | |

I would also prefer having a typed language over the fail fast in production approach.

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

travisgriggs 5 years ago |

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.

mrjoelkemp 5 years ago |

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.

dugmartin 5 years ago |

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.

pmontra 5 years ago | |

I write very few fragments and many more raw queries. No ORM is worth the trouble of going too deep into the rabbit hole of learning for the nth time how to write SQL in X.

dugmartin 5 years ago | | |

It is tempting to just drop down to raw queries but then when I read about things like composable Ecto queries (https://medium.com/flatiron-labs/how-to-compose-queries-in-e...) it makes me want to stay at the higher abstraction level.

The final example in that post:

    EctoCars.Car 
    |> EctoCars.Car.with_color("blue") 
    |> EctoCars.Car.with_transmission("automatic") 
    |> EctoCars.Car.with_engine_horse_power(200) 
    |> EctoCars.Repo.all()

generates very clean SQL:

    SELECT c0."id", c0."color", c0."vin_number", c0."specification_id"
    FROM "cars" AS c0
    LEFT OUTER JOIN "specifications" AS s1 ON c0."specification_id" = s1."id"
    LEFT OUTER JOIN "transmissions" AS t2 ON s1."transmission_id" = t2."id"
    LEFT OUTER JOIN "engines" AS e3 ON s1."engine_id" = e3."id" 
    WHERE (c0."color" = $1) AND (t2."type" = $2) AND (e3."horse_power" > $3)

cultofmetatron 5 years ago |

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.

sb8244 5 years ago |

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.

joelbluminator 5 years ago | |

Shrink probably, sorry its not growing and it never became popular...

sb8244 5 years ago | | |

Sorry, have you worked with the former employer I'm mentioning? I'm talking about a specific use case that has specific needs and challenges. Blanket comments like yours aren't really helpful or necessary.

minhajuddin 5 years ago |

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.

H12 5 years ago |

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

shakow 5 years ago |

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.

eric4smith 5 years ago |

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.

drunner 5 years ago | |

How do you deal with deployments and not losing things you could otherwise persist in Redis or Memcached? Of is your application stateless in that way?

eric4smith 4 years ago | | |

It’s stateless in that way. We’ve redesigned things in such a way that there is more idempotency in the code that does not depends on an external holder of state that is not the primary database.

It’s hard to explain, but the end result is that we don’t reach for Redis as much as we used to.

Vosporos 5 years ago |

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

thealig 5 years ago | |

Interesting to see someone work in Haskell professionally. Jobs in Haskell don't seem be plenty atleast in my area. Could I know what do you work on, and what was the process of obtaining a job there?

fergie 5 years ago | |

Do day jobs in Haskell actually exist? Are you working in academia?

gamache 5 years ago | | |

There are a bunch but they call the Haskell "Scala" for some reason.

jokethrowaway 5 years ago | | |

There are some in finance

the_gastropod 5 years ago | | |

Lots of these newfangled blockchain businesses use Haskell. I'd wager probably most non-academic Haskell programmers work on blockchain stuff.

remi 5 years ago |

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.

shepardrtc 5 years ago |

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.

pjerem 5 years ago | |

Why did non devs choose the language of a product ? Sounds like a strange decision. Or it was the contractor's choice with its dev team waiting for years the opportunity to try Elixir.

shepardrtc 5 years ago | | |

I think they read about it on HN

dudul 5 years ago | |

> They regret it now because no one at our company can work on it

> Sure someone could learn it, but we’ve got more important things to do

If they can't give you 2 or 3 days to learn a language then they don't regret it that much I guess.

svrtknst 5 years ago | | |

I'd say your unlikely to pick up the entirety of OTP in a few days, but agree that it should'nt be too daunting to train in it.

ananthakumaran 5 years ago |

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.

sneako 5 years ago |

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.

udfalkso 5 years ago |

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.

thijsvandien 5 years ago |

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

brightball 5 years ago |

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.

ollysb 5 years ago |

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

sjm 5 years ago |

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.

christhekeele 5 years ago | |

I think of this "applications don't need much maintenance" observation when reading some of the "libraries don't get updated often" complaints here. A lot of the libraries in the ecosystem are already super stable and that's a great thing!

messutied 5 years ago |

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.

aej 5 years ago |

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

neillyons 4 years ago | |

and the standard way of doing config is great.

Grimm1 5 years ago |

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.

strzibny 5 years ago |

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

jb3689 5 years ago |

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

Communitivity 5 years ago |

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

odo101 4 years ago |

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.

gideon13 5 years ago |

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.

spectator02 5 years ago |

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

dimgl 5 years ago |

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

svrtknst 5 years ago | |

> I would rather have had something closer to Koa

I'd just use Plug then. Not every tool suits every job

dimgl 5 years ago | | |

This is what I used when I used Elixir. But I can't say I prefer it to the other tools that are available in other languages. Pattern matching was cool, I guess.

cavalcanti 5 years ago |

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.

acconrad 5 years ago |

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.

devmor 5 years ago |

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.

te_chris 5 years ago |

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.

applepple 5 years ago |

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.

dota_fanatic 5 years ago | |

Obvious troll is obvious but... I assure you there are many high complexity systems in production today using FP that are not spaghetti code. Just like there are OOP codebases which are spaghetti, abstractions are used or abused. I’ve seen both very bad and very good Ruby projects. OOP wasn’t the direct reason why they were one or the other.

moshmosh 5 years ago |

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.

salex89 5 years ago |

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.

oldprogrammer2 5 years ago | |

My biggest hurdle was being too impatient to learn how to code with immutable data. I banged my head on the desk for two days to get through what I felt was a trivial problem (something with updating files in S3), which I eventually rewrote in python in less than an hour.

Immutability (and the resulting maintainability and predictability) is really appealing to me, though. When I try it again, I think I'll focus on educating myself around the language upfront and not just learning as I go.

Everything else about the language, Phoenix, and the tooling was really nice.

For the same reasons as others have said, I would not pick Elixir for a business, though.

BeFlatXIII 5 years ago | |

To answer your question, yes. My background is also primarily in Python (after brief flirtations with other languages during and shortly after college). When trying to learn Elixir (or Scheme, for that matter), my primary hurdle has been thinking in terms of idiomatic Elixir. The struggles aren’t with understanding the syntax (even for Scheme) but rather with understanding the typical patterns used such that I can start a project from scratch without heavy reliance on tutorial materials.

In other phrasing, I’ve quickly mastered the “draw three thin ovals” portion but am now stuck at “draw the rest of the phoenix”. Speaking of Phoenix, I also agree about “mix phx.gen” to be more magical than what I’m used to.

bluevlah 5 years ago | |

Getting hang of functional programming takes time. Writing code elixir way requires unlearning what you have learning from imperative languages.

Jamustico 5 years ago | | |

I've used ocaml in the past and I not new to functional programming, but the whole Phoenix framework is somewhat confusing.

cerved 5 years ago | | |

> Scala

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

mikl 5 years ago |

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

wnevets 5 years ago |

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.

jpbutler 5 years ago |

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.

kosma 5 years ago |

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.

mikeymikemike 5 years ago |

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.

bennyp101 5 years ago |

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)

yoran 5 years ago |

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.

KZeillmann 5 years ago |

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.

josevalim 5 years ago | |

> Maybe it's better now, but that turned me off a lot to using it.

Sorry to hear KZeillmann! For those wondering, releases - which is one of the ways you package your Elixir project for production - are part of Elixir itself since v1.9 (~2 years ago) and reading secrets from env vars is supported out of the box. Just put the relevant code in the config/runtime.exs file.

methyl 5 years ago |

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

TL;DR: very satisfied

chewyshine 5 years ago |

3 years in and Elixir still rocks!

eqmvii 5 years ago |

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.

haolez 5 years ago |

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.

christopher8827 5 years ago |

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.

fortran77 5 years ago |

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.

strzibny 5 years ago | |

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

I don't think it turned out to be true. For myself and many others, we wouldn't get into Beam without Elixir. As a Rubyist I don't understand what mindset I am missing?

antihero 5 years ago | | |

I think perhaps you don't have the required superiority complex :)

antihero 5 years ago | |

What a silly gatekeepingmindset. Of course developers coming into a new paradigm are not going to immediately get it. That is the whole point of people being able to learn new things. If a Ruby dev starts learning Elixir and it's a steep curve for them, and they manage to do it, good on them!

rikkipitt 5 years ago |

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.

bluevlah 5 years ago | |

You will enjoy OTP and Beam, But you will miss Ruby plug-ins.

madhadron 5 years ago |

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.

matreyes 5 years ago |

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!

claudiojulio 5 years ago |

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.

Ndymium 5 years ago | |

Then what would you use for testing equality?

And what would you use if you were pattern matching _and_ assigning in the same statement? I.e.

    {:ok, value} = function()

claudiojulio 5 years ago | | |

Could be like that:

// equality with is already

  1 == 1.0 //true
  1 === 1.0 //false

// assigning

  x = 1

// pattern matching

  x ^ 1

// pattern matching and assigning

  x =^ 1 or x ^= 1

And they should remove the rebinding that is useless. But I find it very difficult for that to happen at that time.

Automatically translated.

hnedeotes 5 years ago |

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.

ollran 5 years ago |

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.

amattn 5 years ago |

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.

rusticpenn 5 years ago |

I use Erlang, Is Elixir a better alternative now?

bluevlah 5 years ago | |

Answer is always no. Erlang is not better than Elixir. Elixir is not better than Erlang.

gamache 5 years ago | | |

Elixir is more powerful than Erlang, due to supporting hygienic macros. Whether this is better or worse is a matter of opinion. :)

dnautics 5 years ago | | |

- documentation

- testing

- Tasks (they are way better than proc_lib)

CJPoll 5 years ago |

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.

michaljanocko 5 years ago | |

Can I ask what HTTP library did you end up with? Thanks.

hit8run 5 years ago |

Happy to have stayed away from it ever since.

BMorearty 5 years ago |

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

BMorearty 5 years ago | |

Clarification on my last sentence: it’s not that managers code in languages like Java. It’s that managers have different priorities, such as hiring. In my experience those priorities lead to different technology decisions.

whereis 5 years ago |

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?

joelbluminator 5 years ago |

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.