As promessas de Ruby e Rails

Quando comecei a utilizar Rails, acho que foi na versão 1.2, em meados de 2006, fui atraído pelas muitas promessas feitas. O desenvolvimento web deveria ser mais fácil, mais rápido e mais divertido – algo que um jovem desenvolvedor Java e PHP como eu desejou instantaneamente.

O que os evangelistas de Ruby on Rails não nos contaram, no entanto, era que com aquelas promessas vinha uma contrapartida, na forma de um modelo de programação muito opinioso e altamente inflexível – em ambos: Linguagem e Framework.

A incompatibilidade de impendância entre o design do framework e o design das nossas aplicações logo ficou claro. Rails tornou a escrita de aplicações web fácil e sem dor – já que eram muitíssimos similares ao BaseCamp. Aplicações do tipo CRUD se encaixam nesse caso de uso perfeitamente. Aplicações de gerenciamento de processos empresariais personalizadas, nem tanto.

Ruby fez uma promessa, de que seria divertido escrever os códigos. Mas ninguém nos contou sobre a diversão de executar os códigos em produção ou manter as partes altamente acopladas depois de 10 anos.

Levou anos para nossa comunidade trazer soluções confiáveis para os problemas acima. Eles normalmente envolvem fugir da “Maneira Ruby” de fazer as coisas. DDD, fontes de eventos, separar a lógica de negócios do framework – isso tudo ajuda, mas aumenta os esforços – quebrando as promessas de desenvolvimento rápido e facilidade no desenvolvimento.

A diversão de escrever código inteligente também foi longe demais. Os desenvolvedores em todo o mundo – com boas intenções – lançaram toneladas de bibliotecas act_as_* que deveriam nos ajudar a resolver problemas específicos. Incluindo uma linha ao seu modelo faria ele suportar versionamento, tornar-se um estado de máquina, ou tratar o upload de imagens. Os resultados disso foram tanto árvores de dependências insanamente grandes para algumas aplicações simples, como códigos que nenhum dos desenvolvedores entendeu completamente.

O padrão ressurge

O mesmo padrão de promessas por uma maneira mais fácil, mais rápida e mais divertida de escrever softwares tem sido um tema recorrente. Os microsserviços deveriam entregar uma arquitetura simples orientada a serviços – normalmente sem nenhuma boa maneira de interagir entre si e tratar casos de uso complicados. Bancos de Dados NoSQL deveriam apresentar uma boa performance e reduzir a complexidade de ter que desenhar o esquema do seu banco de dados – uma mentira óbvia se você já tentou fazer exatamente isso em um sistema em evolução. Aplicações web isomórficas em JavaScript prometiam menos códigos e um tempo de desenvolvimento mais rápido, nos deixando com exemplos de arquitetura de espaguete com design e desempenho pobres.

Nesse ponto, uma luz vermelha pisca em meu cérebro quando eu leio outra promessa de uma maneira mais rápida e mais fácil de escrever códigos.

Elixir – um conjunto diferente de promessas

Elixir e Phoenix, ao contrário dos exemplos acima, não promete uma redução significante do esforço que você vai precisar investir para construir aplicações web. Na verdade, em muitos casos, você vai precisar escrever e corrigir mais código você mesmo do que com Ruby On Rails.

Originalmente, o Elixir prometia uma coisa: acesso ao Erlang/OTP com uma linguagem de programação ligeiramente mais familiar como interface. Qualquer desenvolvedor Ruby pode entender facilmente o que o código do Elixir faz somente olhando para ele, as similaridades são impressionantes.

Ao invés soluções prontas para o uso, você recebe blocos de construção. Eles podem vir tanto em forma de módulos Erlang/OTP, ou implementações específicas de Elixir, como GenStage. Esses são, no entanto, os blocos que você precisa juntar – fazendo com que se adequem ao seu caso de uso.

Existiam algumas influencias de Ruby/Rails no início. As primeiras versões do Framework Phoenix não me impressionaram. Acontece que, depois de alguns anos de exposição aos conceitos vindos do Erlang, a cabeça de um desenvolvedor muda significantemente. As versões recentes do Framework Phoenix estão caminhando na direção oposta à do Ruby. Existe mais divisão, mais flexibilidade na organização do seu código. O criador original do Phoenix fez uma apresentação realmente boa sobre as mudanças – e as razões por trás delas ultimamente.

O Elixir não promete que seu código vai escalar horizontalmente. Ele promete te dar as ferramentas que você pode empregar para fazer acontecer. O Elixir não promete sistemas tolerantes a falhas sem esforço. Ao invés disso, ele te dá os padrões de design e blocos de construção de confiança.

Nós temos uma consultoria de Ruby e Rails e eu também observo tipos diferentes de clientes perguntando sobre o trabalho com o Elixir, além daqueles que buscam ajuda com o Ruby. Os clientes de Elixir tendem a ser mais experientes, tendo uma aplicação em produção (possivelmente em Ruby), buscando ajuda para resolver problemas técnicos que o Ruby não pode resolver. Muitos clientes de Ruby ainda nos procuram como um resultado da propaganda do fim dos anos 2000, com a esperança de construir suas startups de forma mais rápida e mais barata.

Alguém poderia dizer que a propaganda do Elixir não é tão grande quanto foi a do Ruby/Rails. Eu acho que é verdade – não é comparável. Isso é resultado das diferentes promessas que cada ambiente fez. Eu espero, no entanto, que isso resulte em menos desapontamentos – já que Elixir não faz promessas de milagres fáceis.

 

***

Hubert Łępicki faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://www.amberbit.com/blog/2017/3/7/elixir-different-kind-of-promises/