6 ms·

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'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.
- aczerepinski 7y ago
  I don't see why a functional language would be any harder to start with. It might even be easier.
  - pdimitar 7y ago
    Sorry, I wasn't clear. I mostly meant when you were an entrenched OOP/imperative languages veteran coming to FP.
- jashmatthews 7y ago
  > 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. By what metric? Phoenix on Elixir doesn't perform any better than Ruby and a similarly lightweight framework like Roda: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db&l=zg21a7-f&f=zik0z3-zik0zj-zik0zj-zik0zj-zhxjwf-zik0zj-zijbpb-zik0zj-zik0zj-e7 https://www.techempower.com/benchmarks/#section=data-r18&hw=... NodeJS is also much faster than Elixir in other circumstances thanks to the V8 JIT. Elixir's and Erlang's strengths over other dynamic languages aren't really performance. It's mostly just that Phoenix performs much better than Rails.
  - di4na 7y ago
    By every real production load we know. Techempower have not been representative of anything. The only reason elixir and phoenix is not higher is because their code is buggy and they discouraged the community to try to fix it.
    - jashmatthews 7y ago
      Can you give us an example of a performance improvement which was rejected which didn't break the rules? There were performance improvements merged just days ago with input from Jose Valim.
      - pdimitar 7y ago
        Q: Do you guys allow DB connection pools be changed? I know for a fact from my production experience that a small enough number for a DB connection pool in a Phoenix project can cripple its performance due to a lot of requests waiting for the pool.
        jashmatthews 7y ago
        I don't work for TE but this is all covered in their documentation, which is great! https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview#general-test-requirements https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Proj... DB pool size is very subjective much dependent on how long a connection is held without making a query. A recent PR for Phoenix significantly improved performance by _decreasing_ the pool size: https://github.com/TechEmpower/FrameworkBenchmarks/pull/5153 https://github.com/TechEmpower/FrameworkBenchmarks/pull/5153
adamzapasnik 7y ago
The hardest thing for me to get was that Elixir/Phoenix is not Ruby/Rails. They are very different, while syntax is very similar, Elixir favours explicitness unlike Ruby. This leads to a few more lines of code than in Rails. But in a complicated cases, Elixir's code becomes shorter and much easier to dig in. Simple case: Adding a new column to a table Phoenix: 1. Migration 2. update schema 3. update changeset Rails: 1. Migration Complex case: Add a new column with validation only on update Phoenix: 1. Migration 2. update schema 3. update changeset Rails: 1. Migration 2. add validation with only on update 3. pray it won't break anything in other parts of app :/ The complex case sounds like a simple one, but in a big codebase adding validations could be troublesome for a fee reasons, but let's not dig into them. In Phoenix you can have multiple changeset definitions with different validations for each of them, which makes it much easier to control when and what data is validated. It's just one of the examples, there are many others... I'd say, if you are content with Rails, it's great then! No reason to change a technology stack, because some random person is saying it's worth it. If you found a good enough solution for your problems, stick to it :)
AlchemistCamp 7y ago
The main thing that was frustrating for me early on, especially when digging around in the iex console, was immutability.

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.
aczerepinski 7y ago
I don't see why a functional language would be any harder to start with. It might even be easier.
- pdimitar 7y ago
  Sorry, I wasn't clear. I mostly meant when you were an entrenched OOP/imperative languages veteran coming to FP.
jashmatthews 7y ago
> 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. By what metric? Phoenix on Elixir doesn't perform any better than Ruby and a similarly lightweight framework like Roda: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db&l=zg21a7-f&f=zik0z3-zik0zj-zik0zj-zik0zj-zhxjwf-zik0zj-zijbpb-zik0zj-zik0zj-e7 https://www.techempower.com/benchmarks/#section=data-r18&hw=... NodeJS is also much faster than Elixir in other circumstances thanks to the V8 JIT. Elixir's and Erlang's strengths over other dynamic languages aren't really performance. It's mostly just that Phoenix performs much better than Rails.
- di4na 7y ago
  By every real production load we know. Techempower have not been representative of anything. The only reason elixir and phoenix is not higher is because their code is buggy and they discouraged the community to try to fix it.
  - jashmatthews 7y ago
    Can you give us an example of a performance improvement which was rejected which didn't break the rules? There were performance improvements merged just days ago with input from Jose Valim.
    - pdimitar 7y ago
      Q: Do you guys allow DB connection pools be changed? I know for a fact from my production experience that a small enough number for a DB connection pool in a Phoenix project can cripple its performance due to a lot of requests waiting for the pool.
      - jashmatthews 7y ago
        I don't work for TE but this is all covered in their documentation, which is great! https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview#general-test-requirements https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Proj... DB pool size is very subjective much dependent on how long a connection is held without making a query. A recent PR for Phoenix significantly improved performance by _decreasing_ the pool size: https://github.com/TechEmpower/FrameworkBenchmarks/pull/5153 https://github.com/TechEmpower/FrameworkBenchmarks/pull/5153

adamzapasnik 7y ago

The hardest thing for me to get was that Elixir/Phoenix is not Ruby/Rails. They are very different, while syntax is very similar, Elixir favours explicitness unlike Ruby. This leads to a few more lines of code than in Rails. But in a complicated cases, Elixir's code becomes shorter and much easier to dig in. Simple case: Adding a new column to a table Phoenix: 1. Migration 2. update schema 3. update changeset Rails: 1. Migration Complex case: Add a new column with validation only on update Phoenix: 1. Migration 2. update schema 3. update changeset Rails: 1. Migration 2. add validation with only on update 3. pray it won't break anything in other parts of app :/ The complex case sounds like a simple one, but in a big codebase adding validations could be troublesome for a fee reasons, but let's not dig into them. In Phoenix you can have multiple changeset definitions with different validations for each of them, which makes it much easier to control when and what data is validated. It's just one of the examples, there are many others... I'd say, if you are content with Rails, it's great then! No reason to change a technology stack, because some random person is saying it's worth it. If you found a good enough solution for your problems, stick to it :)

AlchemistCamp 7y ago

The main thing that was frustrating for me early on, especially when digging around in the iex console, was immutability.