O programa Build It Yourself feito por você mesmo

• Outra forma de pensar sobre dependências

  • Propõe uma nova perspectiva sobre dependências. É necessário reduzir o uso excessivo de dependências e mudar para uma abordagem de escrever código diretamente.

• O problema das dependências

  • O "consumo de dependências" é o ciclo interminável de atualizações, patches, auditorias e dependências transitivas que os desenvolvedores instalam em busca de produtividade.
  • JavaScript e Rust são especialmente vulneráveis ao problema das dependências. Por exemplo, um novo projeto com Tokio inclui 28 crates, e um projeto com Rocket sobe para 172.

• O problema do tamanho do terminal

  • O crate terminal_size oferece uma função simples para medir o tamanho do terminal, mas exige vários crates adicionais.
  • Isso acaba gerando uma situação em que é preciso compilar milhares de outras funcionalidades.

• A necessidade das dependências

  • Como são construídas sobre bibliotecas de abstração de plataforma, atualizações são necessárias para evitar duplicação de código e reduzir o tempo de compilação.
  • Muitas vezes também se tornam uma causa importante de problemas de segurança.

• O objetivo do código

  • O código deveria ser escrito de forma que não precisasse de atualizações. No ecossistema Rust, código estável acaba sendo desfavorecido.

• Vantagens de escrever código diretamente

  • Ao escrever o código diretamente, não há necessidade de novos crates e a necessidade de manutenção diminui.
  • Com ferramentas como o ChatGPT, é possível criar rapidamente implementações sem dependências.

• Open source e cultura corporativa

  • A cultura corporativa de revisão de código influencia o software open source.
  • Usar novas bibliotecas tende a ser visto de forma positiva.

• A necessidade de uma nova perspectiva

  • Devemos elogiar engenheiros que escrevem pequenas funcionalidades por conta própria.
  • Devemos olhar com desconfiança para grandes grafos de crates.

• Bibliotecas importantes

  • Também existem bibliotecas importantes que resolvem problemas complexos. Por exemplo, bibliotecas gráficas ou implementações de protocolos.

• A importância de construir por conta própria

  • Devemos celebrar quando for apropriado construir por conta própria.
  • Devemos reconhecer o mérito de autores de bibliotecas que criam bibliotecas open source com poucas ou nenhuma dependência.

• Conclusão

  • Devemos mudar para uma abordagem de reduzir dependências e escrever código diretamente.
  • minijinja é um exemplo de minimização de dependências, dependendo apenas de serde.

[GN⁺]

Comentários do Hacker News

• Gosto da linguagem Rust, mas odeio os problemas de dependência dela. O gerenciamento de dependências em C++ é melhor. Em C++, você pode controlar as dependências por conta própria, mas em Rust acabam surgindo dependências demais e isso faz a pessoa desistir. Também do ponto de vista de segurança, não dá para saber exatamente o que estou distribuindo. Rust não tem compatibilidade de ABI e também carece de uma cultura de bibliotecas compartilhadas. Isso destrói o modelo de distribuição de pacotes do sistema operacional.

• A API de terminal não é estável. O ioctl TIOCGWINSZ não é padronizado, e a função tcgetwinsize() só foi adicionada ao POSIX em 2024. No lado do Windows, é ainda mais complicado.

• Ressuscitei um app web que fiz em 2006. Para aprender novas técnicas de CI/CD, projetei demais o processo de deploy do app. Usei PHP e MySQL, e escrevi a maior parte do código por conta própria. Levei apenas uma hora para trazer de volta um app de 19 anos. Já o app em Spring Boot usado no meu trabalho atual é difícil de atualizar por causa de problemas de dependência.

• NodeJS teve um grande impacto na minha carreira, mas o NPM causa muitos problemas. Quando tento adicionar uma nova dependência, ela entra em conflito com outras. No caso do Expo, existe o problema de que o projeto padrão de React Native nem compila no Android. Isso me dá confiança ao ver que até projetos de grande porte podem distribuir templates não funcionais.

• O ecossistema de Rust tem muitas dependências quando comparado ao Go. Em Go, as interfaces são satisfeitas implicitamente, então não há necessidade de dependências adicionais.

• A abstração de bibliotecas tem custos ocultos. Quando um pacote muda o design, isso gera instabilidade. O simples é o que sobrevive por mais tempo. Vi problemas parecidos não só em Rust, mas também em outras linguagens.

• Usar ChatGPT ou Cursor para criar rapidamente uma implementação sem dependências é mais rápido. Muitas dependências de serviços SaaS/3rd party já resolvem problemas que já estavam resolvidos.

• Flask e Bottle tinham funcionalidades parecidas, mas o Flask se tornou mais popular. O Bottle era um único arquivo e não tinha dependências, então era fácil copiá-lo para dentro de um projeto. Porém, por não acompanhar as práticas modernas de Python, ele acabou parecendo ultrapassado.

• Precisamos de engenheiros competentes que consigam desenvolver soluções por conta própria. Dá para criar facilmente soluções melhores do que bibliotecas existentes. Em um projeto, escrevi um parser para uma variação de Markdown, mas os membros da equipe não quiseram usá-lo por motivos de manutenção.

• É problemático compilar centenas de funções usando apenas uma única função. Em um projeto que atualizava dependências de 3rd party, estávamos usando apenas um método de uma biblioteca matemática. Recomendei ao engenheiro que consultasse a página da Wikipedia e implementasse o método diretamente. O problema não é usar dependências de 3rd party em si, mas a necessidade de um conceito que permita importar só uma pequena parte da biblioteca. Um "microframework" pode ser a solução.