4 ms·
Earlier this year we seriously considered Elixir and Phoenix for a large scale web platform (like in planning the project around this tech stack for a couple of
by throwyo234a62 4y ago
Earlier this year we seriously considered Elixir and Phoenix for a large scale web platform (like in planning the project around this tech stack for a couple of months and even starting the implementation) but eventually decided to go with C#, ASP.NET Core and Microsoft Orleans instead.
There were many aspects considered, but if I remember correctly, the barrier to entry is way too high and new developers need to learn too many things at the same time. With this regard, the lack of a mature business-oriented ecosystem of libraries does not help. My overall impression interacting with the community was that there were either veteran programmers having worked with functional languages for 10+ years and working in teams of veterans (and therefore assuming you already knew plenty of things), or folks using it in toy projects.
Despite trying really hard, we didn't get the confidence that we would be productive and successful in this ecosystem as a company so we went back home to daddy Microsoft. In my view, with the introduction of Phoenix LiveView and such they are trying to market this tech as the easiest and most scalable ecosystem for the web, but their community fails to realize the extent to which people coming from an OOP background (especially Java, C# or even Javascript - which describes most back-end developers nowadays) are at complete lost in this world and have everything to (re)learn.
Another aspect is that even if this platform is very scalable from a technical perspective, functional languages in general are not that great for modeling complex business domains with evolving requirements: since pure functions are the key primitive, you end up needing to update or check plenty of functions whenever you introduce or modify a feature. And when you take into account the fact that Elixir is not strongly typed, you end up having to write plenty of tests to refactor with peace of mind (while a statically language would have provided you 99% of these checks for free).
I would only use it for the infrastructure layer of a system, not to manage actual business rules and business entities. But then, this means that you need to build a separate backend and an API. This is the reason we called it quit and decided to use a stack allowing us to do everything, and boost our productivity by removing the need to build an API. We were really seduced by the messaging capabilities of Elixir, but it just didn't work for us. Not just at a technical level but at a business level.
My takeaway is that if you have a team being already proficient in another backend language, whatever you may gain by building your product with Elixir may very well be lost by building your BUSINESS and your TEAM with Elixir. Even if you are building out a new team, there is a broader market of OOP developers available, and generally speaking, people have a much easier time learning programming through OOP concepts than through the mathematical abstractions backing functional languages like Elixir. Learning OOP with the abstract car and concrete cars tutorials is a breeze. From that point, learning a codebase properly modeled in an objected-oriented manner using DDD principles is a breeze. Learning typescript or even go was a breeze thanks to my C# background. However, learning elixir was quite a time investment, and I am quite senior having built a whole ERP system on my own and built and led multiple teams.
Elixir has true merits but it is definitely not a cure all solution, and too often people overstate how easy to use it is. It may be easy if you are already proficient with Elixir and functional programming but definitely isn't if you are new to this world. I'd treat it as an optimization and think carefully about whether or not one really want to use this stake. Truly outstanding from a technical perspective, but paradoxically not necessarily the best platform to build a business on (which took us a hard time to accept, but at some point we called it quit).
Believe what you see with your eyes, do not buy what people tell you and the hype around it. If you feel relief after modeling your problem space with it go for it, otherwise if you feel it is not working for you whether at a mental level or at an implementation level, follow you guts and move on. Do not waste as much time as we did. Not trying to take anything from the Elixir community but this had to be said to counter balance rosy comments that honestly sometimes seem to have no basis in reality. I doubt most of the people singing most of these praises on Elixir have actually tried to go all in with it and build a business on it.
- gregors 4y agoI fully understand that Elixir might not have been the right choice for you and your team, but ... I doubt most of the people singing most of these praises on Elixir have actually tried to go all in with it and build a business on it. Lots have and some quite successfully * divvy - https://getdivvy.com/blog/why-divvy-uses-elixir/ https://getdivvy.com/blog/why-divvy-uses-elixir/ * discord - https://discord.com/blog/how-discord-scaled-elixir-to-5-000-000-concurrent-users https://discord.com/blog/how-discord-scaled-elixir-to-5-000-... * frame.io - https://medium.com/frame-io-engineering/elixir-open-source-frame-io-849f4b1ebd9a https://medium.com/frame-io-engineering/elixir-open-source-f... Both Divvy and Frame.io were acquired btw - * https://techcrunch.com/2021/08/19/adobe-buying-frame-io-in-1-28b-deal/ https://techcrunch.com/2021/08/19/adobe-buying-frame-io-in-1... * https://techcrunch.com/2021/05/06/why-did-bill-com-pay-2-5b-for-divvy/ https://techcrunch.com/2021/05/06/why-did-bill-com-pay-2-5b-...
- haspok 4y agoNice summary. I think it all boils down to the fact that 99% of projects just don't REALLY need what Erlang has to offer - they don't REALLY need five nines of uptime, hotpatching in production (actually, the requirement is mostly the exact opposite!), or individual communicating nodes. And when the project really does need that, you can get pretty far with microservices today, which - arguably - implemented half of common LISP, khm, I mean Erlang - are supported by all the cloud providers. And anyway, if Stackoverflow can get by with a couple of .net and SQL servers, most anyone can. Maybe not Google, but are you Google? :) Erlang is just an engineering marvel, but in the real world, engineering is always a compromise.
- tmaly 4y agoI think the other business risk here is can you find experienced Erlang developers to hire?