How much easier has Phoenix / Elixir been to maintain and upgrade versions than Ruby On Rails?

I am primarily seeking feedback from from people who have experience upgrading comparable applications on both phoenix and Ruby On Rails over enough time they have a feel for the relative difference between the two. I have used Rails since Dec 2006, but am just learning Elixir and Phoenix.

1 Like

On the Elixir side, style of programming involving pattern matching types of say structs in function heads, plus compiler warnings/errors has been an enormous help. Compared to Ruby, where you usually get errors at runtime - not compile time - this has been advantage.

Phoenix itself compared to Rails is not a fair comparison, however. Rails is way bigger, nad includes things like assets pipeline, and activerecord, extension to standard library etc. And Phoenix is pretty tiny and then you add stuff on top like Ecto, webpack etc that you update independently.

The above is, in fact, also an advantage, because you can update Ecto without updating Phoenix in most cases, or vice-versa. With Rails you have to do huge update of Rails itself if you need features that were included in new release of say ActiveRecord. So, incremental updates are a plus.

But over all, if you have a pretty standard Ruby app, and pretty standard Phoenix app, and you have decent test suite to catch errors on both updates, and you update the whole stack - I don’t see much of a difference now that both Rails and Elixir/Phoenix/Ecto APIs are pretty stable.

8 Likes

Pretty much the same feelings as @hubertlepicki - I tend to think Elixir/Phoenix is easier to upgrade mostly by virtue of not including as much. Also for a 1.x release the APIs of both Elixir and Phoenix are remarkably stable.

Worth noting that the biggest Phoenix apps I upgraded weren’t as big as the biggest rails apps I upgraded.

In general, less magic is happening in Elixir/Phoenix which means less small changes in how magic behaves to bite you. Also that it’s more a set of components working together makes it easy to upgrade first one and then the other as Hubert mentioned. That then often translates to 3 small to medium upgrades instead of one gigantic one.

It also feels to me like in Ruby/Rails you often rely on state of things or some specific behaviour (again magic!) which is not the case as much in Elixir/Phoenix. Especially in the Rails community headaches I’ve had is that lots of libraries are effectively designed as ActiveRecord/Rails plugins which are too often tied to some internal behaviour and then break during upgrades and you have to upgrade all these other libraries as well. I’ve seen that way less with the Phoenix/Ecto eco-system.

All that said, Rails seems to have stabilized significantly I’m aware of nothing too big in 6.0 that’d break existing things but in my opinion Elixir/Phoenix upgrades should be easier but that opinion still has to stand the test of a huge application.

I’d be interested in experience reports from bleacher report… @keathley ?

2 Likes

Not even a comparison. I can upgrade Erlang, Elixir, Phoenix, Ecto and issues almost never come up – and when they do, they are usually well-documented because most big Elixir libraries have guides for migrating to potentially incompatible versions.

It has been times better.

2 Likes

Speaking of stable API, from what I read I get the sense that the front end isn’t stable? Presence API and LiveView (is new). I think Presence API had a rewrite because of race condition? But apparently the new API is nicer? The work Chris and the Phoenix team are putting in to this is awesome, though.

Is there any truth to this? Or am I just being silly?

LiveView is alpha/beta quality so it’s got bugs and is actively changing, yes. It’s not part of Phoenix per se, not at least yet. There was the issue you mention with presence API too at one point.

2 Likes

My experience with upgrading rails apps was extremely painful, but that was in the 3.2 and 4.0 days, I’ve heard it’s much better nowadays. On the other hand with Elixir/Phoenix apps the upgrades were usually smooth, especially when it comes to Elixir itself - I usually run Elixir master locally and never experienced issues. The biggest hurdle when upgrading phoenix apps so far was Ecto during the major upgrades, but even that I would classify as “smooth upgrade” in comparison to rails 3.2 :sweat_smile:.

It’s worth noting that neither Ruby nor Rails follow semver and are generally fine introducing breaking changes in minor releases (this happens fairly often for Ruby and very rarely for Rails). Elixir and Phoenix follow semver and barring bugs they shouldn’t introduce backwards-incompatible changes while on the 1.x releases (and as far as I know 2.x is not planned for neither of them right now).

As a last point there are two language features in Elixir, that in my opinion make upgrades much easier - warnings for undefined functions and a built-in way to deprecate functions. This means you can find out about a large portion of the potential issues when you compile your project. Keeping the compilation warning-free will generally mean smooth upgrades.

When it comes to presence and live view - the old presence API is still available and still works - the change was fully backwards-compatible. And yes, LiveView is not even released yet as a package, so it’s fully expected to break - it’s not stable and probably won’t be for some time.

6 Likes

I think that was with Ecto 2.0 however, because update to Ecto 3.0 was super smooth on all of the projects I’ve been involved.

I would say switching from “brunch” to “webpack” was a magnitude more problematic than ever updating Ecto.

1 Like

At B/R we’ve been able to keep pace with all phoenix upgrades. At this point all of our services are running on the latest phoenix including changes to the directory structure (a change that wasn’t actually required). Some of these services have come up all the way from phoenix 0.9 or before. I don’t have that much experience with upgrading ruby and rails; the only experience I did have was painful. But what you said about dependencies being tightly coupled rings true to me. Elixir services are easy to upgrade piecemeal.

Ecto has been trickier to upgrade but that’s because we’re paranoid about performance. We have to care a lot about performance at the db level. So at the moment some of our services are running the latest ecto but definitely not all of them. We load test each service to ensure we don’t encounter any regressions or connection issues that might be specific to our usage. But that’s self-inflicted pain and the upgrade itself is relatively easy.

Upgrading Elixir itself has generally been very painless as well. Not all of our services are on the latest Elixir but that’s more on our prioritization then anything.

Overall I’m very happy with the state of maintaining and upgrading elixir and phoenix apps. The core teams do a really good job of making sure that process is as pain free as it can be.

8 Likes

I suppose I should also mention that we probably have an easier time of it because our services are ftmp just apis. We don’t have the additional burden of wrangling JS libraries and the amount of apis in phoenix and ecto that we utilize is pretty small. We also don’t tend to need or use that many dependencies. Especially compared to a lot of rails projects I’ve seen. So that probably makes our life a bit easier.

1 Like

Less dependencies is true for most Elixir projects I saw. Rails pulls a lot of stuff, many of things you’ll never use directly or indirectly but they are still there.

And many Ruby gems have C extensions. This is the usual point of failure on upgrading (also upgrading system / libs) and Elixir dependencies tend to be more self-contained and just use whatever BEAM provides. Great example are Elixir database drivers that are written in Elixir, compared to C bindings in Ruby, similar story with XML or JSON parsers.

That was practically the only thing that made it harder for me to upgrade. And it was still resolved in an hour – deployment and asset pipelines can be annoying when they don’t want to work together.

Vastly easier–although most of my RoR upgrade problems dealt with a single (Postgres driver) gem in C that had to be built and had a poorly-done build script whose bugs changed every release…

2 Likes