> It felt like each library had its own idioms and syntax rules
This sounds like the way software should be. No? Domain-driven design? Or are you saying that they don't follow industry nomenclature?
> It was hard to have consistent architectural patterns across a team
Is this a symptom of everyone being new the language on the team or the language itself? Elixir is a very simple language compared to Python and Ruby in my experience. There are certainly way more people that have done the latter two. What's comfortable isn't always better.
I'm wondering how aware of the trade-offs you are in using an imperative language as compared to one that's functional. If the nitpick/gripe you're having is around readability and syntax, I'm sure there are enough counters in other languages that you've worked with where the code was just spaghetti and hardly testable
Have you considered that productivity comes more with time? I get the sense that you've worked in a team with very few experienced developers that have either worked with Elixir/Erlang or functional languages. My experience has been that those with extensive experience in OO or imperative languages w/o ever treading into FP have had a much harder time adopting Elixir and it has resulted in slower development early on, but those willing to learn, march much faster after ramp-up.
But if you value correctness, less bugs, and easily testable code, it's hard to beat functional languages in this area, and I'm not even talking about just Elixir
> I've seen an elixir/phoenix backend rewritten completely in python/django and it was a big improvement in developer productivity.
Is this really a better idea? If you're mentioning "consistency enforcement", why not use Golang? Elixir also has a formatter built into its toolchain.
Take my responses with a grain of salt -- because if you're just doing a CRUD app and not buying into what the BEAM gives you from an operational perspective, it's probably not that worthwhile?
> It felt like each library had its own idioms and syntax rules This sounds like the way software should be. No? Domain-driven design? Or are you saying that they don't follow industry nomenclature?
> It was hard to have consistent architectural patterns across a team Is this a symptom of everyone being new the language on the team or the language itself? Elixir is a very simple language compared to Python and Ruby in my experience. There are certainly way more people that have done the latter two. What's comfortable isn't always better.
I'm wondering how aware of the trade-offs you are in using an imperative language as compared to one that's functional. If the nitpick/gripe you're having is around readability and syntax, I'm sure there are enough counters in other languages that you've worked with where the code was just spaghetti and hardly testable
Have you considered that productivity comes more with time? I get the sense that you've worked in a team with very few experienced developers that have either worked with Elixir/Erlang or functional languages. My experience has been that those with extensive experience in OO or imperative languages w/o ever treading into FP have had a much harder time adopting Elixir and it has resulted in slower development early on, but those willing to learn, march much faster after ramp-up.
But if you value correctness, less bugs, and easily testable code, it's hard to beat functional languages in this area, and I'm not even talking about just Elixir
> I've seen an elixir/phoenix backend rewritten completely in python/django and it was a big improvement in developer productivity. Is this really a better idea? If you're mentioning "consistency enforcement", why not use Golang? Elixir also has a formatter built into its toolchain.
Take my responses with a grain of salt -- because if you're just doing a CRUD app and not buying into what the BEAM gives you from an operational perspective, it's probably not that worthwhile?