What.
What.
(Honestly, whenever I have to go back to programming in a language without cheap threads I am often sad with the BS that comes out of my fingers. Single-threaded languages, even ones wrapped around an event loop with various hacks to try to obscure the single-threadedness, are so 20th century compared to the ones that were built for it from day one.)
I have high hopes for Rust, though. Even quite a few people at Google seem to have converted to the Rust camp, away from Go.
What exactly are you trying to do? Golang was designed from the start for high concurrency programs. Instead of threads, they use go routines.
OTP being missing matters less than you might initially think, too. I implement what bits of supervisor trees can be implemented here: https://github.com/thejerf/suture , and in general, with the way Go is structured, gen_servers and such just sort of melt away into "things you interact with over channels" without much fuss. (IMHO, OTP is generally a good thing, but the reification of gen_X so deeply into the language was an error. I actually prefer Go+Suture's way of bringing up a server; much simpler, virtually no loss of capability in practice. Again, the theoretical difference turns out to be larger than the practical difference.)
(And before someone angrily smashes the reply button, pleases meditate on the distinction between a "small difference" and "no difference", especially the subjective nature of such judgment calls. You can certainly quibble with the size I assign to the differences but please don't reply as if I claimed no difference, or as if I have not demonstrated awareness of the difference between a strictly-enforced no-sharing environment vs. unenforced no-sharing convention, and, likewise, let's not pretend "isolation by convention" is the same thing in practice as "traditional shared-memory threading". Memory sharing can bite you in Go, and while I've gotten pretty used to the necessary patterns to avoid that (spending years in Erlang first is really good training for that), I don't deny it is non-zero cognitive effort required.)
The reason people like Rust is it is different. It's what people wished C++ could have been so many years ago.
With that said though, each of the languages have its place and uses. Sure many things can be done with both of them, but some things only Rust can do/will be able to do(many unstable things still). Both languages will be successful imo.
I can see Go and Rust being taught as the primary languages in the academic world and in the enterprise world. If I were starting out in school, I'd probably pick Go and Javascript.
Elixir looks Ruby-ish, but that illusion breaks down very quickly since the underlying semantics are anything but. Not to mention Elixir doesn't shield you from having to be aware of the Erlang runtime, the VM and OTP.
For people reasons it is not (currently at least).
The second point trumps the first at this time. Unless I'm missing something the logic here is not as intractable as some seem to think.
Haskell is a very good flag for the kinds of people that make good programmers:
* It's hard to learn.
* Chances of getting a job are minimal, therefore people learn it mostly for their own self edification, and have the kind of grit that keeps them studying for a year or two with not external reward.
* Learning Haskell teaches you some fundamentals that aren't readily discoverable elsewhere.
No one is hiring Haskellers right now, so what you have is a pool of very able programmers, who would love to do Haskell (in fact many would love the chance to use Haskell so much that they'd take a pay cut to do so) and very few people offering them what they want.
If you're a start up, you want to hire a stellar team (possibly at a bit of a discount) and your domain is a good fit then you should seriously consider hiring some Haskellers and letting them write Haskell.
tldr: functional languages were the future for Facebook's new spam fighting tool, they weren't for a startup owner who has previous professional Haskell experience. Consider for your next project and possibly live the future now.