Completely agree with this statement. Ecosystems evolve over time and additional libraries gaining momentum are part of that evolution.
2 Likes
this (and @dimitarvp’s earlier response) are exactly the attitude i find so frustrating. i don’t need to be educated on the reasons phoenix, ecto, mix, elixir, whatever are actually some kind of ideal state and the elixir community, actually, is the greatest. what i need is a community that is more open minded and less hostile to ideas that stray from the orthodox
a great example is the debate over the way elixir misuses mix.config in a way that makes integrating with environments where you need dynamic reconfiguration or injection of configuration via things like etcd/vault an unreasonably difficult goal. people with experience tried to warn the community away from things like using compile time macros to read config, generating code based on config and only reading config from static configuration files but were ignored because using mix or woefully insufficient ":system tuples" was “more elixiry”. distillery only recently got config providers and they still only cover a narrow slice of actual real world needs
17 Likes
I’m sympathetic to those concerns, but it seems you are arguing both sides simultaneously. Open mindedness to unorthodox (to the BEAM community) ideas instead of listening to experience is why we have misuse of mix.config
The other comment I have about the discussion in general is we need to be aware of the age and size of the Elixir community. Having some safe mainstream packages for common application needs helps prevent newcomers from analysis paralysis of what to choose. Over time I do expect we’ll see more alternative approaches and frameworks, and that is great. But we need to temper our expectations of that with the age and size of the community.
15 Likes
i would argue that 'use mix.config’ is the orthodox view in the elixir community. you see the same with views like ‘you shouldn’t need k8s if you are using distributed elixir’ and ‘running elixir in docker is an antipattern’ which are orthodox within the community but present huge barriers to adoption amongst those who face mandates to use k8s or docker to fit in with organizational goals or process
3 Likes
Interesting. We’re seeing vastly different things I’m personally not interested in containerization, and I’m bemused at all the people using Elixir with Docker and Kubernetes, but hey, if it works for them, I’m not trying to squelch their voices.
2 Likes
There’s also something to be said of fewer (more dominant) libraries or tools: a unified community.
Not sure if anyone remembers but the Ruby community almost split into two web frameworks - Rails and Merb, but the Rails team very astutely managed to ‘merge’ Merb into Rails (all they did really was make Rails more modular iirc).
At the time I was just coming into Ruby and I found the prospect of the split very worrying - I didn’t want two not-quite-so-large competing frameworks, I wanted a single big framework that the majority of the community was behind because I felt that would be better all round. So there are definitely plus points to this, even if from the perspective of adoption/user-preferences etc. If we look at Rails, we can certainly surmise that this gamble paid off because it went on to become the defacto web framework.
At the end of the day it is swings and roundabouts, and ultimately people who are making these tools/languages get to decide. If that isn’t you, then, as mentioned earlier, you need to polish up your skills of persuasion 
or, the other option is to become that person, to go out there and do it and get others onboard. We have plenty of that too - whether it’s PragDave’s way of building Elixir apps or the Raxx framework.
I guess my point is nothing is impossible - you really can make a difference 
The tricky part is getting enough of the equation right to get others onboard. JMHO 
7 Likes
Yea, see this way to much. And it isn’t just an issue because of organization goals or process that require them. I often see them conflated, like k8s and erlang are solving similar problems (they aren’t). Not to mention the hyping of distributed Erlang and release upgrades.
At least these issues should improve with time as more production usage exists. Same issue existed in Erlang like 10 years ago. Lots of presentations and blog posts, not just from random people but like Github, about using Erlang, then internally the attempts fail and are replaced, but the posts and presentations live on and more people go down the wrong path, rinse and repeat.
7 Likes
But saying that theres nothing to be gained by exploring other ideas is exactly the kind of mentality that I personally find very frustrating.
I’m not exactly sure where this comes from. I dont find much evidence of this personally. I think the Elixir community is generally a bunch of really practical people. If a particular tool doesnt fit your needs, I dont think you will find anyone telling you not to explore alternatives. In fact - if it performs a task better than any current tooling - you will most likely find further adoption.
2 Likes
Cool to see someone else from Croatia 
Have we met IRL?
I agree that it’s difficult to find Elixir job here, and it’s always hard to introduce a new language to the company with an established tech stack. I guess that’s a problem everywhere, but we’re a pretty small community, which makes it especially hard. That’s why a few years ago I started working remotely for foreign clients. It was clear to me that I want to professionally focus on Erlang/Elixir, and that I just can’t do it with local companies.
Things seem to be improving slowly. I know of two local companies which work with Elixir. My understanding is that they’re expanding (or might expand in the near future), so if you’re interested in doing Elixir work professionally, send me a DM and I can connect you with them. Also, a regular Elixir meetup might take off soon-ish in Zagreb, so stay tuned for more news about that
7 Likes
I know that this reply that I am writing can be seen as another example of frustrating, but regarding configurations, we have had many discussions here in this forum about ways to improve configuration as well as official proposals. We have written library guidelines to reduce the abuse. We have deprecated system tuples in the major libraries (ecto, phoenix, etc). We are discussing alternatives with OTP and so on.
And even if what distillery provides is not enough, it is progress. I believe this is not a trivial problem to solve, otherwise we would already have seen a satisfactory solution. And as far as I know it is not a problem solved in Erlang either (not that it matters, but just to add that it is not trivial).
So seeing the config debate being used as an example is actually a bit frustrating to me 
because a good amount of work has been put into this and we are trying to push folks to the correct direction (unless you mean that folks have been stubborn despite all of the work described above and then I’d also agree: it is definitely frustrating - but also understandable as we pushed folks towards those wrong solutions for a good chunk of time).
Which is funny because in my experience k8s makes it easier to setup distributed Elixir as it automates the node discovery/connections.
23 Likes
From the point of view of a beginner, I think that few libraries but very mature is better than many unstable libraries. Since the community is still very young, scattering does not seem like a good idea. Everything will come with time and it is better to focus on what does not exist yet. I think for example that we would have much to gain from having complete library corresponding to each one that is common in other frameworks. I’m thinking for example about authentication, administration system, why not translation of documentations into other languages and maybe more internationalization. I think all this will come by the community growing.
Personnaly I’m having fun doing elixir and I would like to contibute when I will feel more confident with it. ^^
14 Likes
As someone who has deployed 4 apps through edeliver over 2 years, I have no idea what you are talking about, and I consider that a good thing. I had to update elixir and the deploy file slightly, but it was a lot smoother than expected!
Updating rails usually turns out to be a major issue, Phoenix was a breez, taking less than 5 hours to figure it out.
Would I choose Phoenix over rails again? Depends on the Developer, but I feel a lot more confortable and productive in Phoenix now.
1 Like
This is a great point!
As a community, I feel we could definitely improve in being less critical of the alternative libraries. It’s clear that a new lib is not as mature as the established ones, but it still might be interesting because of the ideas brought to the table. We should focus on those ideas.
To aid in this process, I think that the authors of new libraries entering the charted space should clearly explain the new ideas and approaches they’re trying to introduce. To me, that’s even more important than having full-blown docs and getting-started guides. My advice to lib authors is to include a rationale doc in their project, and link to it at the top of the main readme, and the official announcement. As an example, see the second sentence, of my Parent readme.
12 Likes
In keeping with “attempting at empathizing with the other point of view”.
The way I see it, part of that mentality is fuelled by what has happened to the npm ecosystem.
Small modules: it’s not quite that simple:
I offer an additional explanation: that we in the JavaScript world have a higher tolerance for nonsense and dreck.
Some people simply don’t want the Elixir ecosystem to go down that road. It’s one thing to put whitebox (but not necessarily generalized) solutions on GitHub/GitLab that everyone can learn from (i.e. exploring other ideas). It’s another to potentially flood Hex with packages for the sake of someone wanting to have a package on Hex.
I actually see the problem in the reverse. Once you accept the prevalence of k8s (and/or Docker) it seems to undercut the perceived runtime value proposition that the BEAM can bring, for example in terms of fault tolerance.
How do your sell the BEAM to an established k8s/Docker shop? Seems to me they treat everything inside a deployment unit as an implementation detail where they just rather stick to established, “good enough”, mainstream technologies.
12 Likes
I have moved away from Elixir partly. My company has elixir as main software for the administration tools we develop. I do join in coding from time to time but its getting more rare as I move away from web services .
I am and always will be a c and c++ guy at my core because unlearning 22 years of bad habits is hard. that said elixir is really fun to work with.
1 Like
hey @gausby – could you please open another thread that might be named (proposal):
“Why have you moved away from X and landed on the BEAM?” 
3 Likes
If you read closely you’ll see that I asked a question and didn’t make a statement – I never said that there is nothing to be gained by exploring other ideas. I am still genuinely interested in the answer of my question which was “what is to be gained exactly?”.
1 Like
I will again ask where do you see hostility?
We can’t have a dialog if you guys immediately feel frustrated and make sweeping generalizations. That’s not how a constructive discussion happens.
I asked a few questions in my earlier post and I didn’t get a single answer yet. I only get categorized as hostile. I find that quite puzzling.
As far as I am concerned, assuming intentions without a real dialog is the problem between these two supposed camps of people. Not any perceived hostility – which I am yet to see anywhere on this forum.
8 Likes
I was excited to see your Gleam project on Github. How is that progressing? Are you using it in production at all?
1 Like
It’s going well. I’ve made a topic to talk about it so we don’t derail this one
1 Like
