You use hipe exactly the same way you do it in erlang - with a module attribute. The syntax in elixir is @compile .... The hipe bit in the VM manifest is merely stating that this VM has support for hipe-compiled programs.
Hipe doesn’t work too good if you have a code that switches often between hipe and non-hipe code - the switches are expensive.
For the record, you can set the env-var ERLC_COMPILER_OPTIONS with options to be passed to erlc when compiling Erlang and Elixir code (because Elixir code gets translated to Erlang).
No, actually Elixir does output to Erlang code. Erlang Core it might do later, but for now it is still outputting to Erlang itself for a variety of extra ‘free’ compiler checks it gets.
This was caused by reading somewhere, more than once, that Elixir was compiled to the same byte code of Erlang, not translated to Erlang code.
Trying to find that sources led me to this article https://medium.com/@fxn/how-does-elixir-compile-execute-code-c1b36c9ec8cf and for what I can understand Elixir is not translated to true Erlang code as some Erlang developer would write, but instead is translated to an Erlang Abstract Format to take advantage of the mentioned BEAM optimisations.
I was not able to find the sources of my misunderstood but at least I know more about what is the compiler process now
From my understanding it does output to Erlang itself, not Erlang Core, I know that translating to a lower level was eventually planned (and the new debug segments added to the BEAM facilitate making that easier), but I don’t think it’s been done yet? Would love to find out though.
The primary reason to use Erlang Abstract Format instead of Core Erlang is tooling. Using that we get, basically for free dialyzer, cover, debugger and erl_eval. Compiling to Core is also a bit awkward since it’s a moving target - it’s treated as an internal detail of the Erlang compiler and changing rather frequently between releases.