e rodá-las dentro da BEAM São vistas como uma função em Elixir/Erlang para quem chama; pertencem a um módulo Compiladas e linkadas numa biblioteca compartilhada carregada dinamicamente (.so no linux) Jeito mais rápido de rodar C em Elixir/Erlang: não tem troca de contexto
executada como uma extensão direta do código nativo da VM. A execução não é feita num ambiente seguro. A VM não consegue prover o mesmo que ao executar código Erlang, como: escalonamento preemptivo e proteção de memória.
fora do Erlang Interface orientada a bytes para comunicação, por exemplo usando pipes em Linux O programa de fora reside em outro processo no SO. Cada port é um recurso de um único processo, e somente ele pode falar com a port. Se o processo termina, a port é fechada.
os dois pipes. Não tem como responder via stdout depois. (alternativa: Porcelain, DIY) Comunicação é stream, sem garantias de chunk: tem que parsear! Se tiver coisa muito complicada, vale usar o Erlang Term Format
É criada uma port, mas para um processo que está dentro da BEAM. Assim como NIF: • é carregado um .so feito em C • não tem troca de contexto • se pegar fogo, explode tudo A diferença é que você implementa um processo Erlang em C, portanto pode ser assíncrono e reagir a eventos! (mas é mais difícil de implementar)
em Java. Essas libs tem funções que permitem você rodar seu programa como um nó distribuído do Erlang. O acoplamento fica menor, e você consegue detectar falhas no nó remoto. IMO, faz mais sentido quando são duas aplicações que podem co-existir sem necessariamente depender uma da outra.