I have a medium sized Rails web app (200K LOC, 500M db records) that will be undergoing a rewrite, and instead of writing it in Rails again, I want to use Elixir/Phoenix.
I feel confident that it’s the correct technical choice, and it’s ultimately my decision so I don’t have to convince any one else, but it will be nice to have them on board. I can easily show the technical merit, but I’ve found it harder to show that it will have staying power… (so people are concerned about future updates, packages going unmaintained, etc).
Does the fact that it dropped off of the Stack Overflow develop survey in 2020 actually mean that its interest is actually slowing? Are there metrics that would show that it’s likely to still have at least at much interest that it does now in the near, or far, future?
I’d appreciate any thoughts the community has on this. Thanks.
Mate, Elixir just turned 10 years old.
The underlying tech is older than me and I’m already 30+ and they’re still moving forward.
NX which could open A LOT of possibilities for Elixir is fresh out of the gate. Someone posted a bug less than 24h ago and José already patched it.
I don’t have any tangible metric to answer your question but I think you should not worry about this.
If anything, IMHO, Elixir will only be stronger in the future.
I’ve been there and had limited success (I left the company before completing the full conversion). I am sure you won’t be doing a full rewrite, but instead migrate chunks out in bits and pieces. The place we attacked first as a proof of concept was authentication and authorization. It worked well and we started to scale bits and pieces into it.
By “limited success” do you mean in convincing people that was the right direction, or limited success in the actual conversion? If the latter, what sort of issues were most problematic?
The main question is WHY did the app need to be re-written. You must understand why it had to be re-written (hence funding was made available etc) before you can sell any technology solution effectively. Also it is unwise to embark on this alone — you must have a team and a training / staffing plan in place if you want to change the technology stack.
A curmudgeon can refute every single positive thing you can find regarding Elixir if their job is at risk. Incidentally, I find that most of the time it is not about technology, but rather risk management.
I completely agree. It might not be the case but I’ve seen and unfortunately experienced how a team tried to rewrite an app using a different tech stack and failed miserably because they had so little domain knowledge and requirements they couldn’t even rewrite the app using the same technologies. Some of the important questions are “Why the app needs to be re-written?” and “What are the risks?”. If the reason for a rewrite is that the codebase is one hot stinking spaghetti dish, I’m not sure rewriting it in a different tech stack would help you significantly.
I’m doing the rewrite myself (back end at least), and I’m fluent in both Elixir and Ruby. I’m not looking for Elixir/Phoenix to fix anything, as the problems have to do with code organization and database design.
I want to rewrite in elixir because I prefer that now, though I still love rails, and we’ll be able reduce the server footprint as an added bonus.
I’m just finding that the “niche” perception of Elixir spooks some of the team, and the smaller number Elixir devs available if I get hit by a bus is a legitimate concern.
Besides, if no one is willing to take a chance, that perception will never change. If we want to have more people wanting to work with Elixir, we gotta have more companies wanting to invest in it.
This is a journey in which companies and devs need to walk hand by hand.
I used to be the guy who wanted to rewrite services and apps knowing some stack would be better. After some negative experiences, one of which I already mentioned, I’m now not that quick to propose a rewrite. Code organization and database design can be fixed without changing the programming language. Take some time to reorganize the code and maybe even refactor. Tidy your models, DB tables and optimize your queries.
No offense but no matter how much I live Elixir and Phoenix, it sounds to me like a rewrite for the sake of it. My opinion is not important but your team’s is. Unless you can provide business value with the rewrite they will be spooked and rightfully so.
Thanks for the backlink, it’s much appreciated. I’ve tried / worked with many things and my honest opinion is that Elixir due to it’s ergonomics/simplicity and underlying BEAM/Erlang/OTP is worth it and will payoff in the years to come.
Yeah, same here. If you are gonna do a rewrite it must not be a big bang, take a small piece / service do a POC first to weigh the benefits, measure and then make a sound decision based on the data.
IMHO, if you are not interested/don’t need in Elixirs/Erlangs concurrency primitives, messaging, easy scalability and fault tolreance facilities (the OTP part), maybe don’t bother. It’s sad that Elixir is mostly known for Phoenix which is a web frameowork (I know it’s a lot more than that but a lot of people settle only for that) and miss out on the real goodies.
True. However rewriting in Elixir has some very tangible benefits on top of better code organization – see below.
Severely reduced server host.
Increased speed. Phoenix is very often known to return in the space of 2-20ms which is something that most other dynamic languages struggle with without having multi-tiered caches in place.
Using an FP language immediately eliminates 98% of all bugs involving shared state. You are mostly only left with making sure your DB is consistent.
I get your skepticism and I started being more cautious about rewrites myself. But there are cases when there are unquestionable benefits. Rewriting from a good chunk of the dynamic languages out there to Elixir is almost always a win.
I’ve witnessed rewrites from PHP, Ruby (+Rails), NodeJS and even Perl to Elixir and 99% of the problems were not understanding the domain / business logic, not the resulting tech stack. Elixir itself solved many scalability and fault tolerance problems those projects had with zero tuning.
Now if you tell me “let’s rewrite this NodeJS service to Go” I’d absolutely give you a firm “Nope”. There aren’t many benefits to be had in such a rewrite because Golang is in fact not that strongly typed (people use reflection / dynamic-dispatch and the escape hatch of interface{} in order not to deal with static types way too often!).
But rewriting an idiosyncratic Golang codebase to Rust / OCaml / Haskell carries a ton of benefits due to reduced runtime errors and the ability to catch a whole class of bugs at compile-time.
I have also seen two projects where rewriting to Elixir would only make them worse – they were huge, the compromises in the code bases were well-understood by the veterans and there were procedures in place to avoid most foot guns. In these conditions bringing a new language will only bring chaos.
Everything must be judged on a case-by-case basis.
The mere fact that Elixir NX was born and that the Elixir populace in general turned their attention to tooling and ability to generate code shows maturity of the ecosystem.
The language is more or less completed and unless somebody can offer – and implement – something game-breaking then it’s not going to change drastically ever.
The language and the ecosystem are generally stable. There are areas where there’s too much choice – like HTTP clients – but even there people are regularly working on ways to centralize.
I have no doubt Elixir and Phoenix will be around in 5 years but I do sometimes wish Jose, Chris and the core Elixir / Phoenix team had a 50 million dollar a year SAAS app running where they continuously blogged about and made keynote talks about how all of these great features were rolled into the eco-system based on features that were running in production for months in their flagship app / business.
I know they do consulting on the side but it’s really hard to give tangible results due to NDAs and contracts, so chances are the best you can say is “we had a client where we did xyz”, but you can’t release the details so folks on the outside never get to see it in action.
I still think this is why Rails was so successful and continues to be.
Basecamp is just too good of a story to ignore. It’s this real business that was built in unison with Rails. You can be very confident Rails is going to be around and improve because for the last 15+ years it’s been improved upon based on building Basecamp and now Hey.
And even if Basecamp decided to go away tomorrow there’s GitHub, Shopify, AirBnB and other massive sites using Rails with a bunch of engineers from those companies contributing back to the framework, plus the list of core members who are unrelated to Basecamp.
It’s really easy to talk yourself into using it because you can say “it works for them, of course it’s going to work for me”, and the proof is there. You can click around those big sites and see how it all comes together and then envision “well I’m not building GitHub but my app does this similar thing”, etc.
I don’t think what you have suggested would be “better” as we would risk ending up with a bunch of grifters AND the commercial/work-related obligations will inevitably take away the time of the core team members. It is not worse just that the community will end up very different, and I know for sure I would be seriously disinterested in attending a sales conference disguised as a software conference.
Rails will remain maintained because there has been so much built on top of it, that it is now too big to fail. Companies will even pay for LTS branches to backport patches (I just did that for one of our services, shamefully). The further up the tapestry you go, the more legacy systems you will see, which represents more built infrastructure. In fact, the incentives could be severely misaligned here… as old technology dies off, the inevitable need to maintain the few remaining behemoths will push the cost of maintenance activities up.
For new projects, any technology that allows sufficient maintenance and changes to be carried out during the project’s life expectancy should be on the table. It is a matter of balancing build costs vs maintenance costs etc. You can lead the horse to water, and that is the only thing you can do.
Sometimes you end up (fortunately) with one obvious choice and you go and write the system in Erlang/Elixir and never have to touch it again.
Also…
Erlang/OTP has been around for decades — Ericsson uses it in products, Cisco uses it, many other companies use it
Erlang Solutions continuously put out case studies of Erlang & Elixir adoption
If you want to hire one of the Elixir shops, they will obviously walk you through their pitch deck
Existence of Podcasts, Blogs etc provide psychological comfort, as at the end of the day adoption of one toolchain over another is probably more of a sociological problem than a technical one
Lastly… the flip side of your question would be… How to convince somebody that building today’s systems in Erlang/Elixir is a fine choice, and we will be totally fine even in case the technology dies completely and maintainers disappear…?
Paolo – What are the benefits and the drawbacks one can experience by using Erlang instead of C for Embedded Systems?
Peer – The benefits are many, you get much more done in the same time. (…) That Erlang/OTP has industrial strength implementation, well most of the Embedded Systems I work with are used in industrial use cases. (…)
Then there are the whole Erlang/OTP fault tolerance and fault isolation features. (…)
Plenty of OTP’s infrastructure features are needed in Embedded Systems, it’s like it was built for them. Which it actually was because the phone switches Erlang was invented for are very similar to todays Embedded Systems.
Also maintainability: Embedded Systems usually have to be maintained for 10-15 years, sometimes even longer. A system written in Erlang is much more maintainable than a system of same complexity that is written in C.
A lot of current Embedded Systems software only manages to deal with all this by being very simplistic, they have a hard time with the modern connected world. (…)
When I read this I looked into Erlang and I had zero fun, so I forgot about it (I did not know of Elixir, which was pre 1.0 at the time).
So while Elixir is most known for Phoenix, it has great potential in building software systems (see the talk) and embedded systems. What one (wo)man can do in one day with Elixir/OTP/nerves he can never do with C. The embedded software scene is very slow moving. While you web-guys have a new (best) something every week, C gets updates once in decade. So new things (Elixir) will be adapted slowly. But: good things will prevail eventually. Elixir/Erlang/OTP will gain more attention besides web-dev. The whole thing is just too good, it will not go away.
