Elixir/Erlang almost couldn't be more different in this regard, which basically embrace runtime failures (things fail, so... "Let it fail quickly"). An uncaught runtime error in Elixir/Erlang causes the node to shut down after logging the error and, if it has a supervisor node (which is quite likely), the node is restarted in a fraction of a microsecond. The developer is expected to monitor the logs and watch for common faults and fix those. This is in fact where the "nine nines" reliability comes from- restarting nodes extremely quickly after runtime errors.
The Erlang philosophy is basically, "these systems exist in the real world, which is sometimes unpredictable and flaky... accept it and allow the code to move on quickly." This happens to be a good strategy for website code- Remember that Erlang was built to run cell networks... How often are cell networks down these days?
I was also a "disenfranchised" Ruby guy, tired of working on classes of bugs that would never even see the light of day in a functional language, which is why Elixir's syntax was appealing (I had already looked at Erlang, but I didn't like its syntax). Again, there's taste and opinion here, of course. Coding has become awfully fashion-driven, of late.
There's a class of programmers who don't care about syntax or don't see the point of it. Ruby/Rails folks are not typically that type of programmer, and that's the first group who will likely migrate to Elixir.
Finally, what really raised my eyebrows about Elixir was its macro facility http://elixir-lang.org/getting-started/meta/macros.html Prior to Elixir, full-fledged macros were only a feature of homoiconic languages (the Lispy ones where the syntax is also a data structure). Elixir came up with a clever way to do macros, while retaining syntax.