2 years ago, I went all in with elixir/phoenix with my startup. Happy to see a language like this which appears to handle integration with the beam ecosystem as a first class consideration. I can see this being useful for some parts of the app where I need to integrate with external services.
Hola folks, I'm making Caramel. AMA.<p>There's usually updates on Twitter too here: <a href="https://twitter.com/CaramelLang" rel="nofollow">https://twitter.com/CaramelLang</a>
This looks very cool, and I have been casually looking into OCaml lately.<p>Please excuse this naïve question, but what is the main value proposition here over plain OCaml: Erlang/BEAM library ecosystem interop, or more something relating to high concurrency? It wasn’t really clear to me from the website/docs.
I loved working with the Beam VM and Elixir. I just wish it had a stronger presence in the Data/ML/AI fields. As scalable and trivially parallizable as Elixir is with a fast SciPy/NumPy/Pandas type of eco-system and you'd have a fantastic environment for data heavy apps IMO.
This is cool. It seems that it even supports Reason syntax.<p>There are really many languages start targeting BEAM lately. Quite a pleasant trend since Erlang was always underrated IMO.
being unable to do dynamic dispatch seems like a big show-stopper for distributed/meshed apps, which seems to be the only reason for targeting the BEAM to begin with, no?<p>If you don't pass functions around as MFAs in a distributed app you run into trouble with upgrading your cluster as they'll have different versions of a function during a rolling deploy
Obligatory list of alternative Erlang VM languages:<p><a href="https://gist.github.com/macintux/6349828#alternative-languages-targeting-the-erlang-vm" rel="nofollow">https://gist.github.com/macintux/6349828#alternative-languag...</a>