Elixir is what I would choose. I think of deployment as a one time cost. So, the cost of exrm+docker solves your build problem and then your deployment is like a "single binary". (except its a single docker container which is sufficient for me, maybe not for you.)
As I understand it the go runtime must pause to resolve atomic locks for all the goroutines running. So, when you're doing a dozen goroutines in your app it's not a problem, but you couldn't do thousands of them. Meanwhile elixir processes can handle millions of processes without blocking like that, and that plus the ... strength... of immutable memory (vs. shared in go) makes me like elixir, especially when concurrency is important. (I don't consider go to be a concurrent language in this regard.)
Good tooling and debug support: I can't compare the two languages in this regard, go seems to have good library support. Elixir has excellent tooling and debug support (REPL mainly, and really nice error messages), and I think Elixir has good library support too.
Fun to write: So far for me, Elixir wins this hands down. Go is running neck and neck with Erlang in the "not very fun to write" range for me.
Of course this is all personal opinion.
The only objective thing is- if you need real concurrency and to build a distributed system (go doesn't even have the concept of language support for Nodes) then Elixir is the way to go.
If on the other hand you need max compiled speed on a single node, the Go wins hands down.
No such thing as Elixir processes. They're Erlang processes because they're constructs of the EVM. Whether or not you consider the latter fun to write is irrelevant.
Thanks! The point about immutability is important. Based on the comments I've been seeing on HN, I had a feeling that Docker brings its own set of problems. But, it may be worth checking it out.
> I think Elixir has good library support too.
I guess the support will be even better if you consider using Erlang libraries.
I learned erlang first, years ago. I absolutely fell in love with it. Somewhere when I wasn't writing a lot of erlang code, it crusted over and now the erlang syntax bothers me. While elixir is more than a syntax, yes, that is part of its value for me.
To me, in my head, symbolically Elixir and Erlang are the same language, the concepts I'm using most of the time are representable in both. I just find Elixir more fun and easier to write quickly.
As I understand it the go runtime must pause to resolve atomic locks for all the goroutines running. So, when you're doing a dozen goroutines in your app it's not a problem, but you couldn't do thousands of them. Meanwhile elixir processes can handle millions of processes without blocking like that, and that plus the ... strength... of immutable memory (vs. shared in go) makes me like elixir, especially when concurrency is important. (I don't consider go to be a concurrent language in this regard.)
Good tooling and debug support: I can't compare the two languages in this regard, go seems to have good library support. Elixir has excellent tooling and debug support (REPL mainly, and really nice error messages), and I think Elixir has good library support too.
Fun to write: So far for me, Elixir wins this hands down. Go is running neck and neck with Erlang in the "not very fun to write" range for me.
Of course this is all personal opinion.
The only objective thing is- if you need real concurrency and to build a distributed system (go doesn't even have the concept of language support for Nodes) then Elixir is the way to go.
If on the other hand you need max compiled speed on a single node, the Go wins hands down.