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.
> Again, there's taste and opinion here, of course. Coding has become awfully fashion-driven, of late.
I agree and that's a really enlightened view. But I'm quite glad - it means the ecosystem is maturing if we now can be fashion driven, rather than having to care about "does it work?"
I really like this language, I've met Jose Valim and he's a super nice, super smart guy, as is Chris McCord. So I feel naturally motivated to promote it. Also, it's just lots of fun to work with!
> it means the ecosystem is maturing if we now can be fashion driven, rather than having to care about "does it work?"
Well in my case, as I said, I got tired of certain classes of Ruby bugs, and certain, shall we say, "uglinesses" which presented themselves, but only after (sigh) YEARS of working with Ruby. In a way that's an argument FOR Ruby! It will only start to look ugly years after you work with it. ;) More than can be said for MANY other languages!
So far I haven't seen too much "ugly" in Elixir (which is good, as it should be in the "beautiful bouncing baby" phase!). In fact, in some ways it's even more Rubylike than Ruby is, such as with being able to define your own sigils: http://elixir-lang.org/getting-started/sigils.html And of course the macro facility is pretty much the ultimate definition of Ruby's oft-touted "metaprogramming." Chris McCord already has a book out on it, actually: http://smile.amazon.com/Metaprogramming-Elixir-Write-Less-Co...
Its a completely different language, with a completely different set of people thinking it is the way to go going forward. They have very little in common.
> Or where Go didn't live up to its promises?
As there are in the present, there will probably be more than one significant web application language in the future. Its not impossible that Go and Elixir could both be among them. Its not really an XOR type of situation.
I'm also not sure elixir is so great (not enough experience with the language and no time to try it right now) but at least at a glance it seems to put a cleaner face on some of Erlang's strengths, so at least it brings something new to the table.
And looking at the state of competing and ever-growing landscape of Javascript frameworks, I'm not convinced multiple big things is better.
1. elixir is less strongly typed than go
2. elixir is more purely functional
3. elixir has a smaller community and is less backed
[1] http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-...