I highly agree with your comments about Go and its adoption, etc. I went with Elixir because of my previous comments elsewhere: I see Erlang’s implementation of the actor model as a naturally distributed and concurrent architecture, whereas I see Go’s implementation as a highly focused collection of concurrency patterns (but I’m not a Go expert). The barrier to entry with Erlang is what I’m talking about with the need for better tooling. IMO Elixir is already doing just about everything else with regards to dropping barriers and being attractive.
I also wanted to mention on the static vs dynamic aspect: I have recently come to appreciate guards as essentially more powerful “static” type contracts. If I expect a certain type in a function signature, I create a guard for it. On top of that, for free, I get even more robust contract declaration through the same guard mechanism. So whereas in .Net I would have to implement Code Contracts using a separate extension that combines static analysis and interweaved runtime injection (if using runtime contracts). So what I’m saying is, guards provide both “typing” and the more advanced (pre-condition) “contracts” as a natural, tried-and-true aspect of the language. I think also that with a bit of syntactic sugar, guards could even be implemented with a “type” syntax similar to:
def foo(bar) when is_atom(bar) do
becoming…
def foo(<atom> bar) do
or however you want to indicate a type. But, and I hate to sound like a broken record, there needs to be kick-butt tooling to give us solid intellisense, jump-to-def, and refactoring (at a minimum!).
