hakunin
a year ago
Here’s my anecdote.
I built 3 production projects in elixir around 2015-2018, and it was a blast to learn and work with. Those were interesting projects that were a great fit for the stack. One was March Madness bracket game which required a huge throughput on day one, and another was a football game audience play calling each play from their phone as the team is playing live at the stadium. This one needed a lot of timing coordination and poor connection handling. I even put out an open source fast/customizable leaderboard on top of ETS.
However, I didn’t feel the need for this stack on most projects, and if I’m totally honest, I never got good at the novel way of building applications in it.
While it was very enjoyable, everything felt a little awkward. Even 3 years in I constantly felt that I’m not doing it right, and I’m fighting the language to do data transformations in a purely functional style. I never got used to writing Ecto queries, and always had to look up their syntax. Plus, there didn’t seem to be a good architecture story, just isolated praise of OTP. And Phoenix further fueled the confusion, making it hard to understand whether I’m supposed to reason about my app like a Rails app (just build controllers, models, and views) with no regard for processes, or I should orchestrate some creative supervision trees, that I can’t even tell how they would be arranged in a typical web app. Going back to Ruby on Rails was kind of back to super productive comfort zone after a bit, and I just continued staying there.
I’m still looking back at Elixir with nostalgia, wondering if I’m going to have a chance to go back to it and really make it an extension of my arms/brain like Ruby had become. And whether I can do all that amazing supervision-based architecting I keep theorizing in my mind. I loved Dave Thomas’s vision (and agreed with his controversial takes) and really wished I could get as good as Sasa Juric at really deeply reasoning in this framework. Maybe one day.
josevalim
a year ago
> I’m still looking back at Elixir with nostalgia, wondering if I’m going to have a chance to go back to it and really make it an extension of my arms/brain like Ruby had become.
You should give it another try. :)
You jumped in quite early, when we were still collectively figuring out what it meant to build Phoenix applications, and many things were in flush back then. You probably went through Ecto 1 -> 2 -> 3 and Phoenix was migrating to contexts.
But I also have to say there was a lot of FOMO in relation to OTP back then: people felt they had to build these amazing supervision designs, otherwise they were not using the language correctly. But the truth is that they are building blocks for frameworks and certain libraries, in the same way threads/mutexes are for other languages. Of course, GenServers are higher-level, more expressive, and bring more properties, but the overall idea is that they are about infrastructure, and not design. Phoenix, Ecto, Broadway, etc should be spawning 99% of the processes that you need for you.
hakunin
a year ago
> You probably went through Ecto 1 -> 2 -> 3 and Phoenix was migrating to contexts.
> But I also have to say there was a lot of FOMO in relation to OTP back then: people felt they had to build these amazing supervision designs, otherwise they were not using the language correctly.
Exactly!
Contexts really threw me off, because I couldn't figure out how/why would I set a boundary up front, if I'm not even sure how the app is going to turn out.
josevalim
a year ago
Understandable! The documentation provides quite more guidance now (and there is nothing wrong with naming your context after your "models").
steve_adams_86
a year ago
I have to say this is a really good summary from my perspective too. Different exposure and projects, but the experience in terms of ergonomics and other developer experience was much the same.
I never felt truly proficient. I recall years ago interviewing for a role and straight up telling the interviewer I wasn’t very good with Elixir. That’s just how it made me feel. In retrospect I was fine, I built some interesting stuff. I probably could have promoted myself for that. But the language kind of left me feeling like I wasn’t getting it.
Even so, great fun to learn and apart from those aspects, I enjoyed building with it a lot.
ipnon
a year ago
I have this same feeling using Elixir, and I think it’s because it’s excellent at showing you exactly where you have undefined behavior in your application, much in the same way you spend most of your time writing Rust by wrangling with the compiler that keeps showing you all the holes in your logic. You can write a seemingly equivalent program in Python, and it runs just fine because it’s interpreted, so it seems like you hit the bullseye first try. But as we’re all aware, there are still countless bugs in your system, they just don’t surface until later when it’s Friday night and your website finally went viral. It’s the downside of the “fail fast, fail often” OTP paradigm: you develop the program by working through your faulty logic step by step as determined by the (many) errors raised by the BEAM. The upside being that unlike Python none of these errors are usually strong enough to be fatal to your application.
steve_adams_86
a year ago
This is a huge part of it, for sure.
I think this is why people often dislike state machines too, for example. They force you to really think through what you're trying to do, and there are no shortcuts.
The irony is that the state machine pattern itself kind of is a shortcut to stable, reliable, safe code. People find them overly complex and full of ceremony, but it's like... Do you really want to try getting the same assurances from your code without this kind of abstraction? I'd rather know my I can't shoot myself in the foot, because I guarantee you that I will.
Elixir also has the added layer of unfamiliarity for a lot of people (myself included) where you might intuitively know how to do something imperatively, but you need to do it within the FP paradigm. I like FP and have adopted a lot of its patterns all over the place, but I still find I'm not a great FP thinker in general. After something like 10 years. My FP-fu is limited to relatively basic operations, and when I go into advanced territory I'm constantly leaning on reference material. That's more so a skill issue than an Elixir issue.
throwawaymaths
a year ago
For the most part you really only need to know Enum.map, Enum.reduce and if you really hate recursion, Enum.reduce_while
And the nice thing is that those are highly imperative/declarative functionals.
Edit: ok, also "returning stuff out of if and case statements". That one kept triggering a python developer I had, had to remind him something like 20 times. Elixir would be way better if it had 'no shadowing variables' rules.
michalbcz
a year ago
> The upside being that unlike Python none of these errors are usually strong enough to be fatal to your application.
That's a great point. Each language has its domain where it excels. The reality is that 90% (or more) of all apps don't deal with the traffic scale of YouTube, the complexity of an operating system, or the mission-critical constraints of software for the F-35. For most businesses, Python is more than sufficient in 2024. At the same time, for learners, it's much easier to pick up. It's a sweet spot.
matt_s
a year ago
There are really neat parts of Elixir. For full stack web dev pretend you are building a lego town. Elixir/Phoenix is more of a set of lego bricks vs. Ruby/Rails is completed foundations of sets you are putting finishing touches on and plugging together. At least that is my experience using it.
There also is the human aspect of Elixir or arguably any language/framework comparison and inertia to change. One could argue all the technical merits of one vs. another but at the end of the day, successful business outcomes are not going to change much _because_ of the technology choice.
It's hard to get a company that has a lot of Ruby/Rails apps and knowledge to commit to training existing developers on something else with the net result being, its just a different language/framework. When you're building data intensive web applications, Rails will scale. The vast majority of cost with data intensive apps is disk storage which it doesn't really matter what web tech stack you're running.