5 ms·

I see Elixir on here quite often, what is the appeal and why are many companies switching to Elixir? Last I checked a while ago Brex famously used to be on Eli

I see Elixir on here quite often, what is the appeal and why are many companies switching to Elixir? Last I checked a while ago Brex famously used to be on Elixir but now are on Kotlin. https://medium.com/brexeng/building-backend-services-with-kotlin-7c8410795e4b https://medium.com/brexeng/building-backend-services-with-ko...

RamblingCTO 3y ago
Really interesting read! I was always curious about Elixir but we've been using kotlin in the backend for years now an I'm really happy (except the JVM and spring bullshit stuff). The language tho is on another level. Lot's of compile-time safety and syntatic sugar. We're really productive with that.
out_of_protocol 3y ago
Elixir+Phoenix does web stuff very well, with little maintenance required (i've upgraded 4+ years old project in two ot three days, time mostly spent on upgrading some 3rd party libs that bumped major version). Unlike ruby, it's really easy to understand what's going on (no hidden state, all variables are passed explicitly, imports are stored in one file (in phoenix) you can look at or explicit as well. With added LiveView on top, you could avoid writing a lot of SPA react (vue, svelte etc) code (some limitations apply, but you can do a lot), spending less people, time and resources for the same result. Traditional setup: backend logic + backend api + react SPA + logic for calling backend api LiveVew setup: phoenix backend + LiveView views + a bit of glue code (in elixir) to replace onclick etc stuff
- yurishimo 3y ago
  For those reading who are not able to switch stacks, these same ideas are being applied in other languages very successfully as well. 1. Laravel Livewire for PHP 2. Hotwire for Rails/Ruby 3. Blazor for C#/.NET 4. HTMX* as a general tool for any other web server 5. React Server Components (if you squint hard enough) Phoenix Liveview definitely started the trend by showing a mature implementation of these ideas on the same level as the application developer. I would argue number 5 is a bit of a meme, since you still have to write a ton of JS, but if you're more interested in the architecture ideas for structuring your app, there is an interesting parallel that I think can be drawn. [*] HTMX doesn't really embrace the idea of calling a function from your server by name, but the ergonomics are similar when writing frontend code.
  - stanmancan 3y ago
    Laravel Livewire is… frustrating. I used it for 1-2 years and ended up learning Elixir so I could use LiveView instead. Livewires performance is terrible for anything other than very basic components. The fact that it has to rebuild state on every interaction makes it a pretty poor tool for most use cases.
    - yurishimo 3y ago
      Not sure if you've seen that v3 was released. Caleb spent a lot of effort to solve many of the performance problems. It's still not as lean as Liveview (and nothing probably will be) but it's much much better than it was.
      - stanmancan 3y ago
        I saw it was released but never looked into it as there's no reason to now that I've moved to LiveView. I have other issues with Livewire as well, including how Caleb operates his communities. He has and continues to make a ton of money off Livewire and still provides zero support to the community. Want any actual support? Well that starts at $6,000/year for one support request a month. He doesn't even appear to be a member of his own discord server anymore. Not that it makes a difference; last time I checked had only ever sent 34 messages in there and the last one was in 20202. He has one guy who would randomly show up around once a day and answer some of the questions. I don't expect free support but if your package is so confusing that the community is unable to support each other, you should probably be around trying to help sort that out. Instead, he just keeps doing re-writes which puts the the load on everyone else. Anyways; if you're interested in this type of project I HIGHLY recommend you check out Elixir/Phoenix/LiveView. I haven't enjoyed writing software this much for a long time; not only is the language and framework more enjoyable to work with, but the community is so much better in general.
going_north 3y ago
I can't speak for other companies or devs, but as a relatively junior developer I quite enjoy working in Elixir, and especially with Phoenix and the Ecto ORM. The syntax reads and writes very well. When I now have to write other languages, mainly Typescript, I miss native pattern matching and the pipe operator.
toolz 3y ago
Plenty of languages can get a solid standard library to write most code with, but only elixir gives you a modern, simple standard library with the tools to scale an app as high as apps can be scaled. Whatsapp famously got to 1 billion messages a day with only 11 engineers on the BEAM (the VM that elixir runs on). It has proven itself immensely capable at the highest levels of scale so the only thing for anyone to decide is whether the stdlib and tooling is to their liking (speaking mostly in the context of networked IO bound applications, which is most things on the internet)
- aczerepinski 3y ago
  I love Elixir, but I don't agree that it's the only language with a great standard library. Go has one too.
  - toolz 3y ago
    I probably worded my statement poorly, but my intention wasn't to claim it was the only language with a great stdlib. I would disagree that go has a good stdlib, I think it's quite poor, but I do believe plenty of other languages have great stdlibs.
Thaxll 3y ago
"many" not really.
mattbrewsbytes 3y ago
Elixir is bolted on top of erlang so reading error stacks with erlang is common, needing to grok erlang concepts and docs is also sometimes needed. This makes it odd to work with. I know if I'm using a Java, Ruby, Python or PHP framework (django, laravel, rails, whatever latest java web framework) I can read thru docs or source code and troubleshoot stack traces without having to learn another language. Its unavoidable with Elixir beyond simple apps.
- emerongi 3y ago
  I barely know Erlang and life has been fine. I do know the runtime characteristics of the Beam VM and occasionally I need to read Erlang docs, but compared to other stacks the experience has been significantly more pleasing. People are of course different and I fully acknowledge that things that seem normal to me may seem odd to others, so YMMV.
- giraffe_lady 3y ago
  Erlang is a very simple language though especially compared to elixir. The runtime semantics are fairly unusual but it almost completely shares those with elixir so you'll have to learn them anyway. The BEAM is very complex but again you have to learn that anyway.
- pdimitar 3y ago
  I hear you and it has been an issue years ago but gradually Erlang's maintainers have been making error messages (and return error values) better and more readable and at this point I can't remember when was the last time when an Erlang return value and stack trace have impeded me. So you were correct some years ago but I am not seeing this nowadays. So yeah, valid criticism, at the same time this criticism has been mostly taken to heart and addressed as of today.
- weatherlight 3y ago
  The syntax is a little different but the semantics are exactly the same, so it's trivial I guess? also, the errors you get, when they are in erlang are in valid erlang, i can't say that about Java, Ruby, Python or PHP which give you errors in English. https://hackernoon.com/why-is-erlang-the-only-true-computer-language-4c7d1f195a02 https://hackernoon.com/why-is-erlang-the-only-true-computer-...
remi 3y ago
We (Mirego) made the move from Rails to Elixir years ago for three main reasons: productivity, maintainability and performance → https://shift.mirego.com/en/elixir-functional-programming https://shift.mirego.com/en/elixir-functional-programming
ch4s3 3y ago
My understanding from talking to some former Brex developers was that the switch was entirely because Kotlin is the CTO's favorite language and everything else was just a post-facto justification. So take it with a grain of salt.

RamblingCTO 3y ago

Really interesting read! I was always curious about Elixir but we've been using kotlin in the backend for years now an I'm really happy (except the JVM and spring bullshit stuff). The language tho is on another level. Lot's of compile-time safety and syntatic sugar. We're really productive with that.

out_of_protocol 3y ago

Elixir+Phoenix does web stuff very well, with little maintenance required (i've upgraded 4+ years old project in two ot three days, time mostly spent on upgrading some 3rd party libs that bumped major version). Unlike ruby, it's really easy to understand what's going on (no hidden state, all variables are passed explicitly, imports are stored in one file (in phoenix) you can look at or explicit as well. With added LiveView on top, you could avoid writing a lot of SPA react (vue, svelte etc) code (some limitations apply, but you can do a lot), spending less people, time and resources for the same result. Traditional setup: backend logic + backend api + react SPA + logic for calling backend api LiveVew setup: phoenix backend + LiveView views + a bit of glue code (in elixir) to replace onclick etc stuff

yurishimo 3y ago
For those reading who are not able to switch stacks, these same ideas are being applied in other languages very successfully as well. 1. Laravel Livewire for PHP 2. Hotwire for Rails/Ruby 3. Blazor for C#/.NET 4. HTMX* as a general tool for any other web server 5. React Server Components (if you squint hard enough) Phoenix Liveview definitely started the trend by showing a mature implementation of these ideas on the same level as the application developer. I would argue number 5 is a bit of a meme, since you still have to write a ton of JS, but if you're more interested in the architecture ideas for structuring your app, there is an interesting parallel that I think can be drawn. [*] HTMX doesn't really embrace the idea of calling a function from your server by name, but the ergonomics are similar when writing frontend code.
- stanmancan 3y ago
  Laravel Livewire is… frustrating. I used it for 1-2 years and ended up learning Elixir so I could use LiveView instead. Livewires performance is terrible for anything other than very basic components. The fact that it has to rebuild state on every interaction makes it a pretty poor tool for most use cases.
  - yurishimo 3y ago
    Not sure if you've seen that v3 was released. Caleb spent a lot of effort to solve many of the performance problems. It's still not as lean as Liveview (and nothing probably will be) but it's much much better than it was.
    - stanmancan 3y ago
      I saw it was released but never looked into it as there's no reason to now that I've moved to LiveView. I have other issues with Livewire as well, including how Caleb operates his communities. He has and continues to make a ton of money off Livewire and still provides zero support to the community. Want any actual support? Well that starts at $6,000/year for one support request a month. He doesn't even appear to be a member of his own discord server anymore. Not that it makes a difference; last time I checked had only ever sent 34 messages in there and the last one was in 20202. He has one guy who would randomly show up around once a day and answer some of the questions. I don't expect free support but if your package is so confusing that the community is unable to support each other, you should probably be around trying to help sort that out. Instead, he just keeps doing re-writes which puts the the load on everyone else. Anyways; if you're interested in this type of project I HIGHLY recommend you check out Elixir/Phoenix/LiveView. I haven't enjoyed writing software this much for a long time; not only is the language and framework more enjoyable to work with, but the community is so much better in general.

going_north 3y ago

I can't speak for other companies or devs, but as a relatively junior developer I quite enjoy working in Elixir, and especially with Phoenix and the Ecto ORM. The syntax reads and writes very well. When I now have to write other languages, mainly Typescript, I miss native pattern matching and the pipe operator.

toolz 3y ago

Plenty of languages can get a solid standard library to write most code with, but only elixir gives you a modern, simple standard library with the tools to scale an app as high as apps can be scaled. Whatsapp famously got to 1 billion messages a day with only 11 engineers on the BEAM (the VM that elixir runs on). It has proven itself immensely capable at the highest levels of scale so the only thing for anyone to decide is whether the stdlib and tooling is to their liking (speaking mostly in the context of networked IO bound applications, which is most things on the internet)

aczerepinski 3y ago
I love Elixir, but I don't agree that it's the only language with a great standard library. Go has one too.
- toolz 3y ago
  I probably worded my statement poorly, but my intention wasn't to claim it was the only language with a great stdlib. I would disagree that go has a good stdlib, I think it's quite poor, but I do believe plenty of other languages have great stdlibs.

Thaxll 3y ago

"many" not really.

mattbrewsbytes 3y ago

Elixir is bolted on top of erlang so reading error stacks with erlang is common, needing to grok erlang concepts and docs is also sometimes needed. This makes it odd to work with. I know if I'm using a Java, Ruby, Python or PHP framework (django, laravel, rails, whatever latest java web framework) I can read thru docs or source code and troubleshoot stack traces without having to learn another language. Its unavoidable with Elixir beyond simple apps.

emerongi 3y ago
I barely know Erlang and life has been fine. I do know the runtime characteristics of the Beam VM and occasionally I need to read Erlang docs, but compared to other stacks the experience has been significantly more pleasing. People are of course different and I fully acknowledge that things that seem normal to me may seem odd to others, so YMMV.
giraffe_lady 3y ago
Erlang is a very simple language though especially compared to elixir. The runtime semantics are fairly unusual but it almost completely shares those with elixir so you'll have to learn them anyway. The BEAM is very complex but again you have to learn that anyway.
pdimitar 3y ago
I hear you and it has been an issue years ago but gradually Erlang's maintainers have been making error messages (and return error values) better and more readable and at this point I can't remember when was the last time when an Erlang return value and stack trace have impeded me. So you were correct some years ago but I am not seeing this nowadays. So yeah, valid criticism, at the same time this criticism has been mostly taken to heart and addressed as of today.
weatherlight 3y ago
The syntax is a little different but the semantics are exactly the same, so it's trivial I guess? also, the errors you get, when they are in erlang are in valid erlang, i can't say that about Java, Ruby, Python or PHP which give you errors in English. https://hackernoon.com/why-is-erlang-the-only-true-computer-language-4c7d1f195a02 https://hackernoon.com/why-is-erlang-the-only-true-computer-...

remi 3y ago

We (Mirego) made the move from Rails to Elixir years ago for three main reasons: productivity, maintainability and performance → https://shift.mirego.com/en/elixir-functional-programming https://shift.mirego.com/en/elixir-functional-programming

ch4s3 3y ago

My understanding from talking to some former Brex developers was that the switch was entirely because Kotlin is the CTO's favorite language and everything else was just a post-facto justification. So take it with a grain of salt.