Por que Elixir? 

Quem sou eu? - 10 anos de dev - 5 anos de sofrimento - 4 anos com Delphi - 1 anos com Java - 5 anos de alegria - 3 anos com Ruby - 2 anos com Elixir - Atualmente trabalhando como Backend dev para teamweek.com 

Por que NÃO? - Linguagem muito nova - Poucas ferramentas - Pode mudar drasticamente - Comunidade pequena - Difícil de encontrar ajuda - Poucas bibliotecas - Pouco profissional - Difícil de contratar - Difícil de ensinar 

Linguagem muito nova - Poucas ferramentas: não confere - Console interativo - Ferramenta de build e gerenciamento de dependências - Documentação built-in - Ferramentas de debug 

Linguagem muito nova - Pode mudar drasticamente: não confere - Core team envolve a comunidade nas decisões - A linguagem segue semantic versioning a risca 

Comunidade pequena - Difícil de encontrar ajuda: não confere - Existe um forum oficial, e as perguntas são indexadas pelas ferramentas de search - Tempo médio de respostas no forum menor que 1 hora e a resposta é útil e pesquisável - Documentação é muito valorizada pela comunidade - Poucas bibliotecas: talvez sim, mas o quanto isso é importante? - Quase 7.000 bibliotecas publicadas, e mais de 100.000 downloads por dia - É pouco? Quantas você usa no seu projeto? Você precisa mesmo daquela biblioteca is_negative? - Desenvolver bibliotecas é fácil e divertido, try it! Mas não reinvente a roda, contribua para as que existem! 

Pouco profissional - Pouco profissional: talvez sim, mas você pode mudar isso - Você pode se tornar um - Difícil de contratar: sim, como qualquer linguagem - Qual é a porcentagem de profissionais contratados que atendem os requisitos? - Profissional de qualidade é escasso em qualquer área - Profissional de qualidade está disposto a aprender - Difícil de ensinar: nem tanto - Aprender a programar não é fácil em nenhuma linguagem - Programadores tem preconceito! Mudar dói, mas quem não muda, morre - Paradigma funcional é mais simples e prático que OO 

Por que SIM? - Escalabilidade - Mudanças frequentes de contexto - Atividades como runtime citizens - Controle total do runtime - Monitoramento de processos - Gerenciamento de processos - Tolerância a falha - Shared-nothing concurrency - Supervision trees 

Escalabilidade - Mudanças frequentes de contexto - Um scheduler por core do processador - Cada scheduler divide igualmente as reduções entre os processos - Processo leves em comparação com threads e processos do sistema operacional 

Escalabilidade - Atividades como runtime citizens - Processos tem identidade - Runtime consegue responder vários detalhes sobre os processos 

Controle total do runtime - Monitoramento de processos - Debug e trace de processos - Término de processos é observável - Gerenciamento de processos - Processos paráveis (gracefully ou brute force) 

Tolerância a falhas - Shared-nothing concurrency - Aqui vem o trade-off: comunicação entre processos são cópias de dados - Em troca você ganha: - GC não é stop-the-world - Recursos que o processo abriu são liberados quando ele morre - Falhas em um processo não causam efeitos colaterais 

Tolerância a falhas - Supervision trees - É o que liga todos esses recursos que vimos até agora - Um processo que cai não afeta processos que não tem relação na árvore 

Tolerância a falhas - Supervision trees - É o que liga todos esses recursos que vimos até agora - Um processo que cai não afeta processos que não tem relação na árvore 

Conclusão - Por que sim? - Escalabilidade - Controle total do runtime - Tolerância a falha - Argumentos de runtime - Por que não? - Linguagem muito nova - Comunidade pequena - Pouco profissional - Argumentos de devtime 

Conclusão Runtime Devtime