Slide 1

Slide 1 text

Por que Elixir?

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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!

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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)

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Conclusão Runtime Devtime