Por que Elixir?

Talk da Elixir Meetup #5 - https://www.meetup.com/elixircwb/events/252381278/

Nela foram apresentados argumentos a favor de usar Elixir em produção, assim como refutados alguns argumentos contra.

Links:

- Proposta de feature apresentada: https://elixirforum.com/t/proposal-moving-towards-discoverable-config-files/14302
- Apresentação do Sasa Juric de onde tirei argumentos a favor: https://www.youtube.com/watch?v=pO4_Wlq8JeI

Transcript

1. Por que Elixir?
2. 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
3. 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
4. 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
5. Linguagem muito nova - Pode mudar drasticamente: não confere - Core team envolve a comunidade nas decisões - A linguagem segue semantic versioning a risca
6. 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!
7. 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
8. 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
9. 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
10. Escalabilidade - Atividades como runtime citizens - Processos tem identidade - Runtime consegue responder vários detalhes sobre os processos
11. 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)
12. 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
13. 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
14. 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
15. 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
16. Conclusão Runtime Devtime