Recently I found some other BEAM programming languages, and most of them choose to compile to core Erlang or standard Erlang. And this makes the Elixir’s choice – the Erlang abstract format become a little mysterious.
Because I’m planning to make a kind of toy language base on BEAM, I’m curious about the pros and cons of each choice.
I would strongly recommend that you use the Erlang abstract format. It will always be better supported by the OTP team and will have fewer compatibility issues.
For example, in OTP 23 we improved the syntax for binary matching. To do that, we had to change how we generated Core Erlang. We stopped using the receive construct in Core Erlang and started using new low-level primops for handling the mailbox. The changes were not in violation of the Core Erlang specification, but it broke tools that depended on the old implementation.
As @bjorng mentioned sometimes the translation from Erlang AST to Core erlang changes which can cause confusion. I had such problem before with LFE when I generated Core. I was generating guards very simply and naively, though correct, and in one version of Erlang one of the optimising passes decided my guards should just fail. Which is not quite what I had intended.
So generating Erlang AT is safer and more future proof.