qqwy

We are happy to announce the open-source release of opsqueue, our opinionated queueing system. Opsqueue is a lightweight batch processing queue, optimized for high-throughput situations. It is very operationally simple and flexible to use, with a novel prioritization approach where decisions can be made in the middle of ongoing work.

They are not equivalent, as Erlang/Elixir uses structural typing whereas Haskell/ML uses nominal typing.

In Erlang you can define the following:

  equal(X, X) -> true;
  equal(_, _) -> false.

In Haskell, the following does not compile:

  equal x x = True
  equal _ _ = False

instead, we need to write something like

  equal x y | x == y    = True
            | otherwise = False

A subtle difference, but in some cases the structural semantics really do make patterns a lot cleaner (shorter without sacrificing readability). I think that this style of pattern-matching semantics is a consequence of Erlang's roots in Prolog, which works similarly (and not only checks for structural equivalence but even does unification when necessary).

Go is a language that is built in a way that makes it impossible to write generic code. This has been done on purpose, to make sure that the language stays simple (['Less is exponentially more'](https://commandcenter.blogspot.nl/2012/06/less-is-exponentia...), so that it can be easily understood and used and maintained by large teams.

However, I personally am against the idea that it is a good idea to solve your problems by giving a restrictive tool to large groups of mediocre programmers. Rather, I like the smaller, smart teams approach, which is what both Rust and Haskell fit much better.

If by 'used more' you mean that more people will use it, then Go will undoubtedly win because it has a much lower learning curve because there is just not a lot to learn. However, I do not think that Go will allow as innovative solutions to be created as Rust or Haskell do.