Perguntas Desconfortáveis Parte 1

Imagem de capa Perguntas Desconfortáveis Parte 1

Questão

O que você faria se encontrasse uma ferramenta com significativamente mais funcionalidades do que aquela que você já está confortável em trabalhar?

Introdução

Essa série tem o objetivo de gerar conteúdo para provocar seu pensamento. A intenção não é fornecer uma abordagem ou ponto de vista correto/incorreto, mas sim oferecer uma pergunta desconfortável para que você tenha que realmente ir fundo na sua mente para entender o porquê de suas decisões, e quais as motivações por trás delas.

Outro objetivo é o de compartilhar conhecimento, experiências pessoais e descobertas, assim como recebê-las da comunidade, com a intenção de gerar um espaço saudável para discussão sobre as questões apresentadas.

Contexto sobre a questão

No fim de 2017, descobri uma linguagem de programação chamada Elixir [1]. Fui contactado por uma empresa para uma vaga de desenvolvedor frontend, e olhando no blog deles, vi que eles adotaram Elixir como uma das principais ferramentas no desenvolvimento backend deles. Até esse ponto, eu nunca tinha ouvido falar de Elixir ou Erlang [2]. Como estava primariamente na comunidade JavaScript nesse ponto, isso nunca foi algo discutido na minha bolha.

Então eu comecei a ler os artigos no blog deles sobre Elixir e procurar quais funcionalidades tinha, e então eu descobri outra ferramenta: Erlang, e depois desse ponto, eu realmente comecei a entrar na toca do coelho 🐇 💊, e provavelmente sem retorno 😄.

Eu li diversos artigos [3] sobre Elixir e Erlang, e fiquei realmente maravilhado com os recursos robustos que a plataforma Erlang tinha.

Obs: depois desse evento, eu comecei a buscar várias outras linguagens de programação para ser minha principal no desenvolvimento backend: Eu li sobre Go, Rust, Clojure, Haskell, mas a que me fisgou foi Elixir/Erlang, embora eu realmente queira aprender Rust no futuro.

Essa comparação [4] feita pelo Saša Jurić realmente atraiu minha atenção:

Comparação Erlang

Essa tabela é do livro Elixir in Action do autor Saša Jurić.

⚠️ Não entre nessa também ⚠️

No mesmo tweet, tivemos algumas contestações válidas sobre a imagem anterior, com algumas igualmente válidas respostas do Saša. Gostaria de copiar tal conversa aqui uma vez que acredito que ela deve ser eternalizada por causa de seu conteúdo pragmático:

"Bom... não refaça o Redis, use o Postgres, e você ainda usaria upstart (isso simplesmente não chegará tão longe com tanta frequência)." - Jim Gray

"RabbitMQ também é bem útil se você está fazendo vários trabalhos em background (e é escrito em Erlang)". - Jim Gray

"Não refaça o nginx também, WTF, eu sei que Erlang é legal e tal mas não refaça coisas que já funcionam bem..." - Jim Gray

"Essa foto é uma história real, e o Erlang foi suficiente para as necessidades nesse caso." - Saša Jurić

"Eu nunca disse que ele é um substituto completo para todos os casos" - Saša Jurić

Aviso sobre Erlang no livro Elixir in Action

"Mas se suas necessidades são simples, o Erlang vai ser suficiente, fazendo a arquitetura geral ser mais simples" - Saša Jurić

"Essa é uma simples solução para um problema simples, e você sempre pode caminhar para outra solução depois quando tiver razões reais" - Saša Jurić

Erlang traz muito poder e minimalismo ao mesmo tempo para o desenvolvedor, e os deixa lidar com tópicos difíceis, como concorrência, manipulação de erros/tolerância a falhas, para citar alguns pontos, de uma forma elegante, através do actor model, pattern matching e árvores de supervisão, por exemplo.

Eu me lembro de ter ficado realmente chateado por ter sido exposto a tais ferramentas "muito tarde", e na verdade esse é um dos motivos que estou escrevendo esse artigo: talvez eu possa ser a pessoa que vai ao menos informar outra pessoa que tais tecnologias existem e talvez isso possa mudar seus planos, e consequentemente mudar sua vida como isso mudou a minha.

Em 2017, eu estava em um momento de tentar escolher um lado do desenvolvimento de produto: embora eu ame e gostaria realmente de aprender tudo desde design de produtos até DevOps, eu estava tentando focar em um lado. Eu tinha escolhido desenvolvimento frontend inicialmente, focado no desenvolvimento de SPAs com JavaScript, mas depois de ver a plataforma Erlang, eu fiquei e ainda estou incapaz de esquecê-la.

Mesmo sendo proficiente em JavaScript, então seria realmente conveniente pra mim especializar apenas em Node.js, eu tomei a pílula vermelha e agora eu não posso ignorar a robustez que a plataforma Erlang tem a oferecer. Mais de 30 anos de engenharia focada na construção de uma plataforma distribuída, concorrente e tolerante a falhas não é algo que se possa jogar fora conscientemente.

O impacto dessa descoberta mudou a minha vida, e agora eu sinto que realmente encontrei o caminho que se alinha profundamente comigo: uma jornada para me tornar um especialista na engenharia de sistemas distribuídos, e ensinar isso para os outros da maneira mais acessível, simples, e minimalista.

Resposta pessoal à questão

Tente evitar a todo custo o Desenvolvimento Orientado ao Hype ("Modinha"), mas nunca feche sua mente para novas tecnologias. Se você encontrar algo que tenha vantagens reais ao que está usando agora, não fique na sua zona de conforto. Comece uma nova jornada e conquista esse novo mundo!

Leituras recomendadas

Se você estiver interessado em aprender mais sobre o que me fez mudar de objetivos de carreira, e ir em direção ao ecossistema Erlang e engenharia de sistemas distribuídos, tenho alguns artigos que realmente encorajo você a ler, não para você adotar o Erlang, mas para você ter mais informações sobre o que atualmente existe e dessa forma, você será capaz de comparar o Erlang (e Elixir) com sua tecnologia atual.

Referências

  1. Elixir
  2. Erlang
  3. dev-log elixir - obs: I actually consumed much more resources than what is registered there 😅
  4. Tweet do Elixir Tip: One of the best reasons to use Elixir/Erlang from Elixir in Action

Artigo original: Uncomfortable Question 001