6 ms·

Can someone post/comment a more critical analysis of elixir if they can? It's really hard to figure out how useful it is because people always build up hype wh

Can someone post/comment a more critical analysis of elixir if they can? It's really hard to figure out how useful it is because people always build up hype when it's not always worth it. All I ever see is how wonderful and magical elixir is and how it's literally life changing. I want to believe but I've seen technologies with lots of hype that didn't live up to it. Plus elixir is different enough that I have a really hard time jumping into it to try it out. ---- I'll also add that recently I had to build a backend for a long term project I've been working on. I seriously looked at elixir/phoenix, but from my research it didn't seem like the pros outweighed the cons. Like there are some technologies that are so useful they're worth the lack of a robust ecosystem or the steep learning curve that may be necessary. And I am not sure Elixir meets that criteria. There's already existing technologies like python/ruby for fast development, java/groovy for stability and groovy for modern features, and finally golang which is really good for concurrency and building web related microservices. Golang in particular is nice because it solves issues like python's slowness and it's slimmer than java in many ways. And these solutions are already pretty good. It's not like it's all that hard to write a backend. Like the productivity gains from js to typescript are huge because js can be bad enough that there's a lot of room for improvement. Whereas how much faster and MORE productive can someone really be in elixir? And I am not even going to get into functional programming which is a whole other beast. It requires significantly different style of thinking, making a lot of my experience less valuable, I don't think it solves solutions for an oop system that's well designed, and often times the implementation can be bad if the right tools aren't there. From my limited experience, FP provides some really powerful features, but at the builtin cost of being more rigid when I don't need it to be.

liveoneggs 7y ago
can elixir compete with the seven other programming languages you named?
- pdimitar 7y ago
  It can and it has, for several years now.
di4na 7y ago
critical idk. But i can answer your points against. What if you did not have to choose ? It gives you all of that. There is no "steep learning curve". I had a sysadmin that never did anything functional pushing code to prod in less than a week. This is not a single case. This is the widely reported result across companies switching to elixir. Regarding rigidity: quite the contrary. In my experience elixir and its take on FP are faaaaar less rigid than an oop one. I am not going to bad talk any of the languages you offered. I will simply say that i disagree with basically every single one of the characteristics you offer for them. Regarding how much productive... Well the most extreme example is whatsapp doing it all with 8 backend engineers. All of whatsapp. Recently RocketMortgage had equivalent results. In the case of rocketmortgage, it was wihtout any prior experience in the ecosystem. This was for Erlang, but all the companies using elixir report equivalent results. PagerDuty and Bleacher Report are probably the most visible one. So in the end... do what work for you ? I do think you are missing the point a bit with your argument, which is what i will fight. But if other languages work for you, great for you :)
- preommr 7y ago
  > I will simply say that i disagree with basically every single one of the characteristics you offer for them. I am confused by this response. You disagree with remarks like go being faster than python?
  - di4na 7y ago
    no i disagree with go being good at concurrency and being good for web stuff for the go example. It is one of the worse experience i know. It is like trying to use C to do it.
- ramchip 7y ago
  > doing it all with 8 backend engineers Wait, what? Whatsapp had 25 backend engineers in 2016, and they use almost exclusively Erlang, not Elixir. They’ve said many times that the Erlang platform has allowed them to do a lot with a small team, but let’s not turn their story into an urban legend... Source: https://www.youtube.com/watch?v=87lW4Llsj7E https://www.youtube.com/watch?v=87lW4Llsj7E (2:20)
gamache 7y ago
Here are a few legitimate complaints about Elixir (and in some cases, its host VM, the BEAM): * No mutation support means that for some CPU-heavy tasks, it's not as performant as languages that allow mutation. Some optimized algorithms that rely on mutation can't be expressed directly in Elixir or Erlang, and instead need to be linked in through a foreign function interface. * It's not on the JVM so we don't get to piggyback on the thousands of dev-years of VM optimization and ecosystem around it. * It isn't invented at, supported at, and marketed by a FAANG-type company. Money moves mountains and Ericsson doesn't spend as much on Erlang/BEAM as, say, Google spends on Go. * Comparison across types is not a runtime exception, so you need to guard against crap like `nil > 1 == true` yourself. * Erlang standard library, which is idiomatic to use from Elixir in the same way of using Java classes from Clojure, is a bit of a junk drawer of tools. There's good stuff, but you may have to dig for it. * Elixir still hasn't nailed the balance between creating small, independent pieces of code ("applications" in Erlang-speak) and wrangling them so they can be used as dependencies from monorepos, multi-repos, etc. Umbrella projects were an attempt, I don't like them. * There is an impedance mismatch between Erlang/Elixir's configuration system and 12 Factor® ENV-style configs. (Full disclosure, I wrote a library for this: https://github.com/appcues/config_smuggler https://github.com/appcues/config_smuggler) * The built-in Elixir code formatter removes trailing commas from multiline lists. I mean, come on!
- verttii 7y ago
  CPU-heavy tasks may not be constrained as much on mutation as on the host VM architecture. The threading system purposefully prevents a thread from hogging all resources. And since you have to run every computation in a thread (process), there really is some overhead. As I'm sure you know, the BEAM is built for concurrency, not for parallelizing computations. Take Haskell for example, which is also immutable but doesn't require you to spin up processes to do computations. It handles CPU intensive tasks significantly better, but is a worse choice for highly concurrent low latency soft real-time apps because of the scheduler and garbage collector mechanisms. Edit: Btw thanks for bringing up that comparison across types issue. Never realized that. What's your solution to it? I'd write guards on functions that filter input based on types, then have a final fallback with no pattern matching that throws an error explicitly.
neves 7y ago
Is Groovy really a contender? It is a decent language, but it's development sucks. Maybe I'm missing something. I use it for Jenkins pipelines and it does not even has an editor with code completion. I must run it through an interpreter to find simple syntax errors, like a missing parenthesis. Looks like I'm developing in the 80's.
- preommr 7y ago
  I am 99% sure intellij idea has syntax validation and autocomplete for groovy.
  - haspok 7y ago
    It does, but it highlights many things as issues which compile just fine.
- haspok 7y ago
  The Groovy compiler feels like a half-baked product, just as the language. It cannot decide if it wants to be a statically typed language or a dynamic one. It happens all too often that I have to manually cast stuff because the compiler cannot deduct the type of an expression. Seriously, it feels like writing Java pre-1.5 (before Generics). At the same time, your code might just compile, and you'd get a runtime error because you forgot to rename an attribute that you referenced, and due to some dynamic wizardry Groovy tries to retrieve it anyway. It is the very opposite of the Erlang universe, where the more time I spent the more impressed I got. So really no comparison between the two, forget Groovy if you have more than a toy project. Java on the other hand... will soon have it's fibers thanks to Project Loom...
  - zmmmmm 7y ago
    > your code might just compile, and you'd get a runtime error because you forgot to rename an attribute The eclipse plugin has a pretty good approach in that it underlines things that cannot be deterministically type checked (that is: it can't prove they are wrong, but it can't prove they are right). It does a fair bit of type inference, so once you get used to that it's reasonably low amount of pain that comes from this type of problem.
conradfr 7y ago
I can give you my point of view as a seasoned PHP / Symfony dev with a light Elixir experience. Pros : - Elixir is fun. It's hard to describe why, but it is. Piping is additive, so are genservers and supervisors (which lead to anti-patterns but still). - Phoenix is well thought out, documentation is good. Plugs are so simple. - Websocket support is great, obviously (and LiveView is a gift). - Ecosystem is not that big, but mostly quality and the automatic hex docs is a great feature. - Concurrency is obviously good and, most of all, only there when you need it (looking at you, Node). - Speed. - Coming from PHP, having the ability to easily run tasks outside the current request is so freeing and eliminates the need of many third party components. - Testing is good. - Mix is great. Cons: - I don't care about static vs dynamic types but I do miss the type hinting of PHP 7. Typespecs are helpful but not the same (and Dializer reports are not fun). - As a follow up it's hard to beat the IDE support of popular languages. (the Elixir plugin for Jetbrains' IDEs is good though). - Not anybody will like functional programming I guess (it did kick my butt at first) - Phoenix doesn't provide that much. If I compare to Symfony (and I guess RoR, Django etc) it's really noticeable. Authorization/Authentication, Cache, Mails etc. Also I'm not a fan of the templating (again, compared to Symfony's Twig). - Also Phoenix speed of development seems slower (I guess the team is small and also currently a lot of work goes on LiveView) - What I would give to have the cross-build capability of languages like Go, or the simple deployment story of PHP etc. - Obviously a smaller ecosystem and less support online (StackOverflow is not useful, better luck on the Elixir forum) - Speed (for some things). - I do miss the return keyword. - I do miss constants (modules attributes are not a replacement). - None of your colleagues want to use it (some people just hate VMs).
haspok 7y ago
One piece of advice: go for Erlang, not Elixir. The syntax is much nicer, and you get a really mature environment. Also, 90% of Elixir is Erlang anyway. I don't know too much about Elixir, but for implementing web services just use the tech you know the best - these days you should be able to scale almost indefinitely regardless of the stack you choose. But if you have a problem that resembles a telephone exchange (eg. no UI, lots of concurrent IO intensive - but not CPU intensive - tasks that have soft-realtime requirements) give Erlang a chance. Even if you end up using some other technology it will really influence your professional development in a good way.
- dnautics 7y ago
  Elixir is much better in the respect that it makes it easy to do the right thing. Code organization, documentation, https, unit testing, even deployment, live reload when web developing, all work out of the box in elixir/phoenix in ways that aren't as convenient or pretty in erlang. Elixir in many ways adds cheddar to the broccoli to get the kids to eat it.
davidw 7y ago
This post is worth reading: https://ferd.ca/ten-years-of-erlang.html https://ferd.ca/ten-years-of-erlang.html
phtrivier 7y ago
I'm in the weird position of being too angry about Elixir to make a "meaningful" criticism of it any more. I'd love to contribute, but I don't know how to phrase anything other than a useless rant. And I would love for the contribution to boil down to anything else than: > life without a static type checker is hard when you're writing a server. That needs to stay, like, on. Which is, arguably, not necessarily a jab at Elixir itself. Sorry.
- dnautics 7y ago
  curious, why are you angry? Since I've adopted Elixir where I work, I'd like to know so that I can avoid those mistakes.
  - deleted 7y ago
    [deleted]
- 1_player 7y ago
  If you can somehow add typing to Elixir, I'm sure the community will accept it happily. Though it needs to be compatible with the Erlang ecosystem. But if you're angry at a programming language, you probably need a holiday :-)
  - phtrivier 7y ago
    Okay, so is "after using elixir for too long, I really need a holiday" a more contrasted version than the hype ;) ?
mmartinson 7y ago
I can take a stab at this. For context, my background is in Ruby, NodeJS, a bit of Golang and Java. I've been doing work with Elixir full time for the last 3 years. I could probably write a novel about the things I like about Elixir, but here's what I'd caution about for someone looking at adopting it over another alternative. - Elixir is not statically typed and probably won't be. If static types are a tool you value, Elixir's success typing and runtime assertions might feel inadequate. - Pattern matching requires discipline to not create heinous coupling. Pattern matching is wonderfully convenient for control flow and helps a ton with readability and avoiding deep nesting in complex situations. It's so convenient, though, that it invites reaching through abstractions into data structures in ways that make code brittle. The language doesn't really provide any guards against this, so it requires care and policing to keep things manageable. - Because OTP is so powerful, it's tempting to avoid industry standard tooling and "just do it in Elixir." This is great for moving fast, but has the risk of pushing problems down to the line to the point that bigger system rework might be necessary. Background processing is a good example here. In Elixir/OTP it's easy to do everything in memory, but once you start needing failover guarantees, or need split out worker processes from a web server for independent resource utilization, you may end up getting rid of the initial implementation and doing the work to move over to a setup similar to what you might using for Ruby or Node anyway. Learning to be productive in Elixir isn't really a huge investment, even for someone with a strict OO background. It's pretty light conceptually compared to other FP languages, can be written in an imperative-ish style if needed, and has clear, simple patterns for code organization. For every place you would consider mutating, you tend to find primitives that make working with immutable data structures quite convenient.
hota_mazi 7y ago
You'll notice that people who praise Elixir compare it to minority web technologies (Ruby, Python) or ones that are documented for various issues (Javascript). Absent from these comparisons are the elephants in the web world: the JVM and .net. The JVM in particular is superior in my experience to Elixir in all respects: statically typed languages, battle tested servers and libraries, abundant documentation and discussions, top of the line performance, excellent tooling allowing rapid refactoring and evolutivity, etc...
toberoni 7y ago
I've been playing around with Elixir and rewrote a small Rails app in Phoenix to get used to it. In the end, the benefits are not big enough to make the switch Pros: - Less magic. It's a lot easier to figure out what's going on under the hood. - Phoenix is an improved Rails. Ecto is more flexible, the generators make more sense and everything is better organized. - FP leads to cleaner code. The difference to a neatly organized Rails (with POROs & service objects) is not big though. - Tooling/Mix is excellent. - Elixirforum is a great place full of helpful people. Cons: - Small ecosystem and lower productivity. I often had to spend 1-2 days to write a feature where with Rails I'd download a gem and it's done. - Elixir gets hyped up due to BEAM, OTP, stability, fault tolerance... - however, apart from some very niche cases most of its features can be replicated with background queues, Kubernetes, etc. - Speed & hosting costs. Elixir is a bit faster than Ruby and the footprint is smaller. But a powerful VPS + CDN is so cheap nowadays that it doesn't matter much at my scale. - It's an absolute niche language. There aren't many tutorials, SO answers or solutions for small problems - you often have to figure it out on your own. Overall I'd say that Elixir is fun to work with and ist well thought-through. At the end of the day I only care about shipping products though. Writing my admin backend in clean FP code is nice, but I rather download a gem like Administrate and be done with it - so I have more time to focus on my core features. From a business perspective I don't see many cases for Elixir: A small shop is more productive with Rails/JS/Python due to the vast ecosystems - and a bigger company will have trouble finding enough devs.

liveoneggs 7y ago

can elixir compete with the seven other programming languages you named?

pdimitar 7y ago
It can and it has, for several years now.

di4na 7y ago

critical idk. But i can answer your points against. What if you did not have to choose ? It gives you all of that. There is no "steep learning curve". I had a sysadmin that never did anything functional pushing code to prod in less than a week. This is not a single case. This is the widely reported result across companies switching to elixir. Regarding rigidity: quite the contrary. In my experience elixir and its take on FP are faaaaar less rigid than an oop one. I am not going to bad talk any of the languages you offered. I will simply say that i disagree with basically every single one of the characteristics you offer for them. Regarding how much productive... Well the most extreme example is whatsapp doing it all with 8 backend engineers. All of whatsapp. Recently RocketMortgage had equivalent results. In the case of rocketmortgage, it was wihtout any prior experience in the ecosystem. This was for Erlang, but all the companies using elixir report equivalent results. PagerDuty and Bleacher Report are probably the most visible one. So in the end... do what work for you ? I do think you are missing the point a bit with your argument, which is what i will fight. But if other languages work for you, great for you :)

preommr 7y ago
> I will simply say that i disagree with basically every single one of the characteristics you offer for them. I am confused by this response. You disagree with remarks like go being faster than python?
- di4na 7y ago
  no i disagree with go being good at concurrency and being good for web stuff for the go example. It is one of the worse experience i know. It is like trying to use C to do it.
ramchip 7y ago
> doing it all with 8 backend engineers Wait, what? Whatsapp had 25 backend engineers in 2016, and they use almost exclusively Erlang, not Elixir. They’ve said many times that the Erlang platform has allowed them to do a lot with a small team, but let’s not turn their story into an urban legend... Source: https://www.youtube.com/watch?v=87lW4Llsj7E https://www.youtube.com/watch?v=87lW4Llsj7E (2:20)

gamache 7y ago

Here are a few legitimate complaints about Elixir (and in some cases, its host VM, the BEAM): * No mutation support means that for some CPU-heavy tasks, it's not as performant as languages that allow mutation. Some optimized algorithms that rely on mutation can't be expressed directly in Elixir or Erlang, and instead need to be linked in through a foreign function interface. * It's not on the JVM so we don't get to piggyback on the thousands of dev-years of VM optimization and ecosystem around it. * It isn't invented at, supported at, and marketed by a FAANG-type company. Money moves mountains and Ericsson doesn't spend as much on Erlang/BEAM as, say, Google spends on Go. * Comparison across types is not a runtime exception, so you need to guard against crap like `nil > 1 == true` yourself. * Erlang standard library, which is idiomatic to use from Elixir in the same way of using Java classes from Clojure, is a bit of a junk drawer of tools. There's good stuff, but you may have to dig for it. * Elixir still hasn't nailed the balance between creating small, independent pieces of code ("applications" in Erlang-speak) and wrangling them so they can be used as dependencies from monorepos, multi-repos, etc. Umbrella projects were an attempt, I don't like them. * There is an impedance mismatch between Erlang/Elixir's configuration system and 12 Factor® ENV-style configs. (Full disclosure, I wrote a library for this: https://github.com/appcues/config_smuggler https://github.com/appcues/config_smuggler) * The built-in Elixir code formatter removes trailing commas from multiline lists. I mean, come on!

verttii 7y ago
CPU-heavy tasks may not be constrained as much on mutation as on the host VM architecture. The threading system purposefully prevents a thread from hogging all resources. And since you have to run every computation in a thread (process), there really is some overhead. As I'm sure you know, the BEAM is built for concurrency, not for parallelizing computations. Take Haskell for example, which is also immutable but doesn't require you to spin up processes to do computations. It handles CPU intensive tasks significantly better, but is a worse choice for highly concurrent low latency soft real-time apps because of the scheduler and garbage collector mechanisms. Edit: Btw thanks for bringing up that comparison across types issue. Never realized that. What's your solution to it? I'd write guards on functions that filter input based on types, then have a final fallback with no pattern matching that throws an error explicitly.

neves 7y ago

Is Groovy really a contender? It is a decent language, but it's development sucks. Maybe I'm missing something. I use it for Jenkins pipelines and it does not even has an editor with code completion. I must run it through an interpreter to find simple syntax errors, like a missing parenthesis. Looks like I'm developing in the 80's.

preommr 7y ago
I am 99% sure intellij idea has syntax validation and autocomplete for groovy.
- haspok 7y ago
  It does, but it highlights many things as issues which compile just fine.
haspok 7y ago
The Groovy compiler feels like a half-baked product, just as the language. It cannot decide if it wants to be a statically typed language or a dynamic one. It happens all too often that I have to manually cast stuff because the compiler cannot deduct the type of an expression. Seriously, it feels like writing Java pre-1.5 (before Generics). At the same time, your code might just compile, and you'd get a runtime error because you forgot to rename an attribute that you referenced, and due to some dynamic wizardry Groovy tries to retrieve it anyway. It is the very opposite of the Erlang universe, where the more time I spent the more impressed I got. So really no comparison between the two, forget Groovy if you have more than a toy project. Java on the other hand... will soon have it's fibers thanks to Project Loom...
- zmmmmm 7y ago
  > your code might just compile, and you'd get a runtime error because you forgot to rename an attribute The eclipse plugin has a pretty good approach in that it underlines things that cannot be deterministically type checked (that is: it can't prove they are wrong, but it can't prove they are right). It does a fair bit of type inference, so once you get used to that it's reasonably low amount of pain that comes from this type of problem.

conradfr 7y ago

I can give you my point of view as a seasoned PHP / Symfony dev with a light Elixir experience. Pros : - Elixir is fun. It's hard to describe why, but it is. Piping is additive, so are genservers and supervisors (which lead to anti-patterns but still). - Phoenix is well thought out, documentation is good. Plugs are so simple. - Websocket support is great, obviously (and LiveView is a gift). - Ecosystem is not that big, but mostly quality and the automatic hex docs is a great feature. - Concurrency is obviously good and, most of all, only there when you need it (looking at you, Node). - Speed. - Coming from PHP, having the ability to easily run tasks outside the current request is so freeing and eliminates the need of many third party components. - Testing is good. - Mix is great. Cons: - I don't care about static vs dynamic types but I do miss the type hinting of PHP 7. Typespecs are helpful but not the same (and Dializer reports are not fun). - As a follow up it's hard to beat the IDE support of popular languages. (the Elixir plugin for Jetbrains' IDEs is good though). - Not anybody will like functional programming I guess (it did kick my butt at first) - Phoenix doesn't provide that much. If I compare to Symfony (and I guess RoR, Django etc) it's really noticeable. Authorization/Authentication, Cache, Mails etc. Also I'm not a fan of the templating (again, compared to Symfony's Twig). - Also Phoenix speed of development seems slower (I guess the team is small and also currently a lot of work goes on LiveView) - What I would give to have the cross-build capability of languages like Go, or the simple deployment story of PHP etc. - Obviously a smaller ecosystem and less support online (StackOverflow is not useful, better luck on the Elixir forum) - Speed (for some things). - I do miss the return keyword. - I do miss constants (modules attributes are not a replacement). - None of your colleagues want to use it (some people just hate VMs).

haspok 7y ago

One piece of advice: go for Erlang, not Elixir. The syntax is much nicer, and you get a really mature environment. Also, 90% of Elixir is Erlang anyway. I don't know too much about Elixir, but for implementing web services just use the tech you know the best - these days you should be able to scale almost indefinitely regardless of the stack you choose. But if you have a problem that resembles a telephone exchange (eg. no UI, lots of concurrent IO intensive - but not CPU intensive - tasks that have soft-realtime requirements) give Erlang a chance. Even if you end up using some other technology it will really influence your professional development in a good way.

dnautics 7y ago
Elixir is much better in the respect that it makes it easy to do the right thing. Code organization, documentation, https, unit testing, even deployment, live reload when web developing, all work out of the box in elixir/phoenix in ways that aren't as convenient or pretty in erlang. Elixir in many ways adds cheddar to the broccoli to get the kids to eat it.

davidw 7y ago

This post is worth reading: https://ferd.ca/ten-years-of-erlang.html https://ferd.ca/ten-years-of-erlang.html

phtrivier 7y ago

I'm in the weird position of being too angry about Elixir to make a "meaningful" criticism of it any more. I'd love to contribute, but I don't know how to phrase anything other than a useless rant. And I would love for the contribution to boil down to anything else than: > life without a static type checker is hard when you're writing a server. That needs to stay, like, on. Which is, arguably, not necessarily a jab at Elixir itself. Sorry.

dnautics 7y ago
curious, why are you angry? Since I've adopted Elixir where I work, I'd like to know so that I can avoid those mistakes.
- deleted 7y ago
  [deleted]
1_player 7y ago
If you can somehow add typing to Elixir, I'm sure the community will accept it happily. Though it needs to be compatible with the Erlang ecosystem. But if you're angry at a programming language, you probably need a holiday :-)
- phtrivier 7y ago
  Okay, so is "after using elixir for too long, I really need a holiday" a more contrasted version than the hype ;) ?

mmartinson 7y ago

I can take a stab at this. For context, my background is in Ruby, NodeJS, a bit of Golang and Java. I've been doing work with Elixir full time for the last 3 years. I could probably write a novel about the things I like about Elixir, but here's what I'd caution about for someone looking at adopting it over another alternative. - Elixir is not statically typed and probably won't be. If static types are a tool you value, Elixir's success typing and runtime assertions might feel inadequate. - Pattern matching requires discipline to not create heinous coupling. Pattern matching is wonderfully convenient for control flow and helps a ton with readability and avoiding deep nesting in complex situations. It's so convenient, though, that it invites reaching through abstractions into data structures in ways that make code brittle. The language doesn't really provide any guards against this, so it requires care and policing to keep things manageable. - Because OTP is so powerful, it's tempting to avoid industry standard tooling and "just do it in Elixir." This is great for moving fast, but has the risk of pushing problems down to the line to the point that bigger system rework might be necessary. Background processing is a good example here. In Elixir/OTP it's easy to do everything in memory, but once you start needing failover guarantees, or need split out worker processes from a web server for independent resource utilization, you may end up getting rid of the initial implementation and doing the work to move over to a setup similar to what you might using for Ruby or Node anyway. Learning to be productive in Elixir isn't really a huge investment, even for someone with a strict OO background. It's pretty light conceptually compared to other FP languages, can be written in an imperative-ish style if needed, and has clear, simple patterns for code organization. For every place you would consider mutating, you tend to find primitives that make working with immutable data structures quite convenient.

hota_mazi 7y ago

You'll notice that people who praise Elixir compare it to minority web technologies (Ruby, Python) or ones that are documented for various issues (Javascript). Absent from these comparisons are the elephants in the web world: the JVM and .net. The JVM in particular is superior in my experience to Elixir in all respects: statically typed languages, battle tested servers and libraries, abundant documentation and discussions, top of the line performance, excellent tooling allowing rapid refactoring and evolutivity, etc...

toberoni 7y ago

I've been playing around with Elixir and rewrote a small Rails app in Phoenix to get used to it. In the end, the benefits are not big enough to make the switch Pros: - Less magic. It's a lot easier to figure out what's going on under the hood. - Phoenix is an improved Rails. Ecto is more flexible, the generators make more sense and everything is better organized. - FP leads to cleaner code. The difference to a neatly organized Rails (with POROs & service objects) is not big though. - Tooling/Mix is excellent. - Elixirforum is a great place full of helpful people. Cons: - Small ecosystem and lower productivity. I often had to spend 1-2 days to write a feature where with Rails I'd download a gem and it's done. - Elixir gets hyped up due to BEAM, OTP, stability, fault tolerance... - however, apart from some very niche cases most of its features can be replicated with background queues, Kubernetes, etc. - Speed & hosting costs. Elixir is a bit faster than Ruby and the footprint is smaller. But a powerful VPS + CDN is so cheap nowadays that it doesn't matter much at my scale. - It's an absolute niche language. There aren't many tutorials, SO answers or solutions for small problems - you often have to figure it out on your own. Overall I'd say that Elixir is fun to work with and ist well thought-through. At the end of the day I only care about shipping products though. Writing my admin backend in clean FP code is nice, but I rather download a gem like Administrate and be done with it - so I have more time to focus on my core features. From a business perspective I don't see many cases for Elixir: A small shop is more productive with Rails/JS/Python due to the vast ecosystems - and a bigger company will have trouble finding enough devs.