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.

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.

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 .

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.