9 ms·

I know it's been said by many, but I will repeat once again. Elixir is a very cool and powerful language for building web apps. Having built my first product

I know it's been said by many, but I will repeat once again. Elixir is a very cool and powerful language for building web apps. Having built my first product (https://retrochat.xyz https://retrochat.xyz) in Elixir, I can wholeheartedly recommend it to anyone who is not happy with their current backend language(Ruby, Python, Js, etc). Docs, functional programming, OTP, ecosystem(Phoenix, Ecto, Mix) are really top notch. In my opinion, you will be able to reach much higher productivity (especially long term) in Elixir than in Ruby, which is known for it's high level of productivity. Sounds like a fairy tale, right? Well, that fairy tale can become a reality with Elixir. The only thing that is a bit of pain is a good release support, but that has been changing for better.

1_player 7y ago
Releases with Elixir >= 1.9 are now quite good. Run mix release.init, write some configuration, then just mix release and you get a tarball ready to deploy. We use a multistage Dockerfile to build the release and run it on a barebone alpine image, and it's never given me a single issue since I set this system up almost 2 years ago when Distillery was still the release library of choice. And it's never crashed once, but that's the magic of OTP :-)
- akoutmos 7y ago
  That's the approach that I take as well most of the time. Makes it pretty seamless to then take that container and run it in your cloud provider of choice. I put together a blog post outlining the use of Docker + Mix Releases for a Phoenix app https://akoutmos.com/post/multipart-docker-and-elixir-1.9-releases/ https://akoutmos.com/post/multipart-docker-and-elixir-1.9-re... to help people get started.
config_yml 7y ago
I'd be interested in hearing more about this. I'm keen on learning Elixir, but have fallen back to Rails at least 2 times when starting something fresh, because I'm very comfortable with Rails ops. It's simple enough for my case and rails console is just a blessing to dig around when something weird is going on.
- pdimitar 7y ago
  It's mostly two things: 1. The stuff that never goes down (gets automatically restarted with last-known good state) and the amazing runtime in general. Not to mention it's much faster than Ruby or Python or PHP... In some cases it's faster than Javascript although JS and Erlang/Elixir are, on average, tied on performance. 2. A switch in philosophy and the way you troubleshoot your app: from magic/implicit to explicit. Many people cannot cope with this one because the force of habit is extremely hard to overcome. I for one enjoy knowing what exactly is going on in my app and exactly where but many others disagree. Again, it's a philosophical thing; you either are into it or you are not. There is also the objectively technological aspect: zero magic and implicitness mean much easier bug fighting. You no longer have to dig around in callbacks and installed on-start handlers. Make no mistake: it's harder to start with an FP language. Nobody is disputing that. The benefits to be sown after the initial culture and brain shocks however are a lot.
  - cpursley 7y ago
    > it's harder to start with an FP language. Nobody is disputing that. I'll dispute it. For me, the functional paradigm clicked much easier than OOP and it's zillion abstrations and patterns. I'd argue that the best thing about functional programming is it's actually easier to reason about.
    - pdimitar 7y ago
      Eventually, yes. But if you were immersed in OOP/imperative languages for 14-15 years as I was (before learning Elixir) then it is really hard to muscle through the exercises and learn to think the FP way. After that happened however, FP became much easier and much more pleasant to work with.
      - keithnoizu 7y ago
        agreed. I'd been going steadily more fp in my style for years while working in c/c++, php, C#, scala,coffeescript etc. before finally going all in with elixir for the last few years. It makes many, but of course not all, things more straight forward compared to imperative programming.
phtrivier 7y ago
<sarcasm> That, and `no matching clause for foo/3` being 2019's version of the runtime "undefined is not a function" that breaks your app in production. But then again, who does not write unit tests to get 100% coverage against 110% of possible user inputs, in case you made a typo somewhere. Right ? Right ? </sarcasm>
- 1_player 7y ago
  Not very helpful. Interestingly, coming to Elixir from another dynamically typed language (Python), I tend to do much fewer runtime/typing errors than ever before. I might be more experienced, or the tooling and compiler are good enough to catch the most common bugs. I get a few "no matching clause" with my data ingestion tool on my Sentry log because external APIs are flaky and a cosmic ray flipped a bit so that I'm reading incorrect data. A GenServer somewhere crashes, restarts and the data comes back clean, without any user disruption at all.
  - keithnoizu 7y ago
    The only part I miss about erlang is it being a little harder to shoot your self in the foot with types.
  - phtrivier 7y ago
    As you might have guess, absolutely not my experience at all. But as explained otherwise, I'm in situation where "bad" data just keep coming in (and "bad" just mean "data that exercises a path were a runtime error will happen because of a typo that the compiler did not catch.) So "let it crash" means "let it crash again", and I don't see the obvious solution... But again, I'm completely ready to hear that it's just my setup, or how we failed to build the app. Just wanted to confirm that it's completely possible to shoot yourself in the foot, which I'm surprised hardly anyone mention when talking about elixir. Anyone interested should give it a try.
    - Supermancho 7y ago
      There are OTP strategies that are a "do not recover from crash", or more to your case "do not recover more than N times per Z timeslice". http://erlang.org/doc/design_principles/sup_princ.html#maximum-restart-intensity http://erlang.org/doc/design_principles/sup_princ.html#maxim...
adambrod 7y ago
The one thing that could really push it into "dream language" territory is a sound type system. The Gleam language recently popped up as an up and coming solution to that... It's ReasonML/Javascript like syntax makes it familiar and has a good interop story.
- therockhead 7y ago
  Yeah, it looks exciting.
mbesto 7y ago
> The only thing that is a bit of pain Or, finding developers.
- pdimitar 7y ago
  Eh, this is a 50/50. I actually completely agree that Elixir developers aren't many. What I observed however is that people who want programmers that know FP and can apply it to real world problems where teams of web devs can be reduced from 20 to 3... get treated like coding monkeys and not given much respect and creative freedom. You can't replace a pile of clueless juniors banging their heads at the latest Node fashion with several experienced craftsmen and treat them exactly the same. It just doesn't work -- people get discouraged and leave. I've had that happen to three acquaintances of mine (and myself, although I don't dare including myself because, you know, our ego gets in the way of properly gauging our own competence). I've been rejected with the generic "poor cultural fit" excuse enough times on interviews to realise that most managers and shareholders simply want soldiers blindly obeying orders and not captains that can successfully make a team pull through a tough challenge on their own terms as long as schedules and business priorities are respected. So, to me, the problem is also in the attitude of the shot-callers -- not only in the scarcity or quality of the Elixir devs.
AlchemistCamp 7y ago
> The only thing that is a bit of pain is a good release support, but that has been changing for better. The pain in Elixir releases I've seen has nearly always been self-inflicted. You can just run "mix phx.server" on the server and have basically an identical deployment experience as if you were running Rails, Django or similar. Releases are an option that brings some power you don't get in other languages (particularly if you're using Distillery, which makes hot upgrades possible). I wrote a guide on Elixir deployment that covers a way to use the new mix releases and deploy to Render in minutes. It also links to guides covering a number of other patterns, including the one I currently use for Alchemist Camp. It might be useful for others feeling some of the pain you did in the past! https://alchemist.camp/articles/elixir-releases-deployment-render https://alchemist.camp/articles/elixir-releases-deployment-r...

1_player 7y ago

Releases with Elixir >= 1.9 are now quite good. Run mix release.init, write some configuration, then just mix release and you get a tarball ready to deploy. We use a multistage Dockerfile to build the release and run it on a barebone alpine image, and it's never given me a single issue since I set this system up almost 2 years ago when Distillery was still the release library of choice. And it's never crashed once, but that's the magic of OTP :-)

akoutmos 7y ago
That's the approach that I take as well most of the time. Makes it pretty seamless to then take that container and run it in your cloud provider of choice. I put together a blog post outlining the use of Docker + Mix Releases for a Phoenix app https://akoutmos.com/post/multipart-docker-and-elixir-1.9-releases/ https://akoutmos.com/post/multipart-docker-and-elixir-1.9-re... to help people get started.

config_yml 7y ago

I'd be interested in hearing more about this. I'm keen on learning Elixir, but have fallen back to Rails at least 2 times when starting something fresh, because I'm very comfortable with Rails ops. It's simple enough for my case and rails console is just a blessing to dig around when something weird is going on.

pdimitar 7y ago
It's mostly two things: 1. The stuff that never goes down (gets automatically restarted with last-known good state) and the amazing runtime in general. Not to mention it's much faster than Ruby or Python or PHP... In some cases it's faster than Javascript although JS and Erlang/Elixir are, on average, tied on performance. 2. A switch in philosophy and the way you troubleshoot your app: from magic/implicit to explicit. Many people cannot cope with this one because the force of habit is extremely hard to overcome. I for one enjoy knowing what exactly is going on in my app and exactly where but many others disagree. Again, it's a philosophical thing; you either are into it or you are not. There is also the objectively technological aspect: zero magic and implicitness mean much easier bug fighting. You no longer have to dig around in callbacks and installed on-start handlers. Make no mistake: it's harder to start with an FP language. Nobody is disputing that. The benefits to be sown after the initial culture and brain shocks however are a lot.
- cpursley 7y ago
  > it's harder to start with an FP language. Nobody is disputing that. I'll dispute it. For me, the functional paradigm clicked much easier than OOP and it's zillion abstrations and patterns. I'd argue that the best thing about functional programming is it's actually easier to reason about.
  - pdimitar 7y ago
    Eventually, yes. But if you were immersed in OOP/imperative languages for 14-15 years as I was (before learning Elixir) then it is really hard to muscle through the exercises and learn to think the FP way. After that happened however, FP became much easier and much more pleasant to work with.
    - keithnoizu 7y ago
      agreed. I'd been going steadily more fp in my style for years while working in c/c++, php, C#, scala,coffeescript etc. before finally going all in with elixir for the last few years. It makes many, but of course not all, things more straight forward compared to imperative programming.

phtrivier 7y ago

<sarcasm> That, and `no matching clause for foo/3` being 2019's version of the runtime "undefined is not a function" that breaks your app in production. But then again, who does not write unit tests to get 100% coverage against 110% of possible user inputs, in case you made a typo somewhere. Right ? Right ? </sarcasm>

1_player 7y ago
Not very helpful. Interestingly, coming to Elixir from another dynamically typed language (Python), I tend to do much fewer runtime/typing errors than ever before. I might be more experienced, or the tooling and compiler are good enough to catch the most common bugs. I get a few "no matching clause" with my data ingestion tool on my Sentry log because external APIs are flaky and a cosmic ray flipped a bit so that I'm reading incorrect data. A GenServer somewhere crashes, restarts and the data comes back clean, without any user disruption at all.
- keithnoizu 7y ago
  The only part I miss about erlang is it being a little harder to shoot your self in the foot with types.
- phtrivier 7y ago
  As you might have guess, absolutely not my experience at all. But as explained otherwise, I'm in situation where "bad" data just keep coming in (and "bad" just mean "data that exercises a path were a runtime error will happen because of a typo that the compiler did not catch.) So "let it crash" means "let it crash again", and I don't see the obvious solution... But again, I'm completely ready to hear that it's just my setup, or how we failed to build the app. Just wanted to confirm that it's completely possible to shoot yourself in the foot, which I'm surprised hardly anyone mention when talking about elixir. Anyone interested should give it a try.
  - Supermancho 7y ago
    There are OTP strategies that are a "do not recover from crash", or more to your case "do not recover more than N times per Z timeslice". http://erlang.org/doc/design_principles/sup_princ.html#maximum-restart-intensity http://erlang.org/doc/design_principles/sup_princ.html#maxim...

adambrod 7y ago

The one thing that could really push it into "dream language" territory is a sound type system. The Gleam language recently popped up as an up and coming solution to that... It's ReasonML/Javascript like syntax makes it familiar and has a good interop story.

therockhead 7y ago
Yeah, it looks exciting.

mbesto 7y ago

> The only thing that is a bit of pain Or, finding developers.

pdimitar 7y ago
Eh, this is a 50/50. I actually completely agree that Elixir developers aren't many. What I observed however is that people who want programmers that know FP and can apply it to real world problems where teams of web devs can be reduced from 20 to 3... get treated like coding monkeys and not given much respect and creative freedom. You can't replace a pile of clueless juniors banging their heads at the latest Node fashion with several experienced craftsmen and treat them exactly the same. It just doesn't work -- people get discouraged and leave. I've had that happen to three acquaintances of mine (and myself, although I don't dare including myself because, you know, our ego gets in the way of properly gauging our own competence). I've been rejected with the generic "poor cultural fit" excuse enough times on interviews to realise that most managers and shareholders simply want soldiers blindly obeying orders and not captains that can successfully make a team pull through a tough challenge on their own terms as long as schedules and business priorities are respected. So, to me, the problem is also in the attitude of the shot-callers -- not only in the scarcity or quality of the Elixir devs.

AlchemistCamp 7y ago

> The only thing that is a bit of pain is a good release support, but that has been changing for better. The pain in Elixir releases I've seen has nearly always been self-inflicted. You can just run "mix phx.server" on the server and have basically an identical deployment experience as if you were running Rails, Django or similar. Releases are an option that brings some power you don't get in other languages (particularly if you're using Distillery, which makes hot upgrades possible). I wrote a guide on Elixir deployment that covers a way to use the new mix releases and deploy to Render in minutes. It also links to guides covering a number of other patterns, including the one I currently use for Alchemist Camp. It might be useful for others feeling some of the pain you did in the past! https://alchemist.camp/articles/elixir-releases-deployment-render https://alchemist.camp/articles/elixir-releases-deployment-r...