Como migrei totalmente do VS Code para o Neovim

Uso do terminal

Eu sempre gostei muito do uso do terminal, não só por parecer mais "hacker", mas por produtividade mesmo. Comandos em terminal são sempre mais resumidos e portáveis do que ações em um ambiente gráfico. Por não termos a vivência de utilizar o terminal achamos que é mais difícil, quando não é.

Por exemplo: intalar um programa no linux e no windows.

Para instalar um programa no windows, usualmente precisamos do seguinte passo a passo:

1. Pesquisar no google pelo programa
2. Filtrar possíveis fraudes e baixar preferencialmente do site oficial um instalador
3. Seguir o passo a passo do instalador e torcer para dar tudo certo

Enquanto na maioria das distribuíções Linux seria assim:

1. Abrir o terminal
2. Executar um comando com o gerenciador de dependências da distro (apt, dnf, pacman e etc.)

É muito mais simples e rápido no Linux do que no Windows, mas para quem não é acostumado, parece ser o contrário.

Migração para o Linux

Há mais ou menos dois anos passei a utilizar apenas Linux no meu computador. Essa decisão não me deixou nenhum tipo de arrependimento, inclusive para coisas que normalmente são um problema, como drivers e jogos. Inicialmente migrei para o Ubuntu, onde aprendi muito sobre o Linux, logo depois fui para o Manjaro, que me abriu as portas para o mundo do Arch Linux, que é a distro que utilizo atualmente.

A forma com que utilizo o Linux me faz ser mais produtivo, porque é tudo simples e objetivo. Aprendi muito sobre a computação com o Linux e continuo aprendendo. Foi no Linux que deixei de ter medo de documentações, de ler em inglês e das antiquadas págidas de manuais. Me aventurar em um território até então desconhecido me fez me desenvolver muito mais como programador e também me dá muito mais controle sobre a minha máquina.

Motivação para usar o nvim

Tudo o que escrevi até agora foi para dar o contexto do porquê saí do VS Code para o Nvim. Para a maioria dos desenvolvedores isso não é nenhuma vantagem e provavelmente será perda de tempo. Contudo, é importante saber se isso não é vantajoso por conta de não trazer vantagens ou simplesmente por que você está se tornando dependente de uma IDE. No meu caso, nas muitas tentativas de migração que fiz até dar certo, a realidade era a segunda opção. Eu me via refém das funcionalidades do Vs Code e na maioria das vezes incapaz de programar sem elas.

Pode parecer até engraçado, mas você só irá perceber se é realmente o caso quando tentar algo diferente. Não me entenda mal, eu não defendo a ideia de que um bom desenvolvedor deve fazer tudo na unha, em um bloco de notas e sem nenhum tipo de code highlighting, só estou defendendo de que se você se torna muito dependente dele, deveria no mínimo saber se virar sem esse tipo de coisa, ou utilizar alguma outra alternativa.

Hoje em dia nós já temos muita coisa out of the box e isso atrapalha muito quem está aprendendo. É ótimo ter um Codeium ou um Copilot para escrever uma suíte inteira de testes sozinho, mas se você está aprendendo a construir bons testes, isso dá a falsa impressão de progresso. A melhor forma de saber se você realmente aprendeu algo é se limitando e se desafiando.

Como foi a migração

Com esses motivos em mente, tentei fazer definitivamente a migração por quatro vezes. Nas primeiras vezes acabei desistindo por me sentir fora da zona de conforto, com dificuldades para coisas básicas. Toda vez que tentamos aprender algo que tem uma curva de aprendizado mais alta, ficamos muito frustrados e tendemos a desistir, é normal. Mas na quarta vez a migração deu certo pois eu a fiz de forma gradual.

Eu não migrei diretamente para o vim ou nvim padrão, fui para uma distribuição neovim chamada AstroNvim, que já trás várias coisas pré configuradas. Eu escolhi esse editor pois achei mais parecido com a forma com que eu utilizava o Vs Code, no quesito de atalhos e layout.

Inicialmente eu comecei a apenas fazer pequenas edições utilizando o nvim. Normalmente era um arquivo ou outro de configuração ou apenas uma anotação, apenas para ir me acostumando aos poucos, nada muito radical. Em uma das disciplinas da faculdade eu registrava todas as minhas notas de aula em markdown utilizando o nvim ao invés do VS Code, além de todos os exercícios dessa disciplina.

Aos poucos fui pegando mais confiança para ir me aprofundando cada vez mais nas funcionalidades do editor. Isso as vezes me fazia passar horas pesquisando sobre como fazer algumas coisas no editor, até que chegou um momento que eu não precisava mais pesquisar, ou já havia me habituado a procurar diretamente na documentação do neovim que já vem embutida com o próprio editor. Esse ímpeto de sempre pesquisar, aos poucos foi fazendo com que eu conseguisse moldar o editor para a minha forma de usar. Algo que percebi é que cada pessoa tem uma configuração completamente diferente de vim, achei isso muito interessante.

Contato com o mundo do free software e open source

Provavelmente um dos melhores projetos para se entender como funciona o open source e o free software é o Vim. Existe literalmente zero interesse econômico no projeto, é simplesmente usuários do editor que trabalham para que ele fique cada vez melhor e mais moderno. É incrível ver pessoas completamente diferentes, de lugares diferentes e por diferentes motivos se unindo para contribuir para projetos de pessoas completamente desconhecidas. Isso mostra como software é algo democrático e colaborativo.

Além disso, também pude entender como o open source se beneficia de produtos de grandes empresas como a Microsoft, ao mesmo tempo que essas empresas se beneficiam com o open source. Um bom exemplo é o pyright da Microsoft. O plugin Python do VS Code, feito pela Microsoft é um projeto de código fechado. Isso significa que nós só utilizamos o produto final, que nos limita a utiliza-lo somente no editor da Microsoft. Contudo, uma parte dele, mais especificamente o type checker, que é o pyright é open source. Isso é uma faca de dois gumes: a comunidade utiliza o pyright em seus projetos, como o neovim e, a Microsoft aproveita as contribuíções da comunidade para o pyright para melhorar o seu próprio plugin do python.

Os mundos close e open source trabalham juntos e se beneficiam mutuamente, esse é o mundo real.

Entendimento de como funcionam as IDEs

Configurar o vim e nvim pode parecer como fazer um editor completamente do zero. No caso do vim é praticamente isso mesmo, pois ele não vem com muitas funcionalidades para auxiliar na hora de escrever o código. Isso tudo faz muito sentido quando olhamos para a história do Vim e seu antecessor, o Vi.

O Vi surgiu para ser literalmente um editor de código. É por isso que o vi e seus sucessores funcionam muito melhor para editar código do que para criar, uma das motivações iniciais para a sua criação, foi a partir da constatação de que um programador passa mais tempo editando código do que escrevendo novas linhas de código. Para isso o vi, vim e nvim possuem inúmeras funcionalidades que aumentam drásticamente a edição de código, como o seu sistema de pesquisa, navegação, macros e etc.

Isso é o completo oposto do que IDEs são, que é basicamente um ambiente de desenvolvimento integrado, ou seja, um conjunto de funcionalidades que auxiliam e facilitam na hora do desenvolvimento, ao contrário dos editores, que possuem essas características para a edição.

Como editores podem se tornar IDEs?

Há muita discução em torno de até onde um editor continua sendo um editor e onde ele passa a se tornar uma IDE. O próprio VS Code é alvo dessas discuções. Normalmente uma IDE possui três funcionalidades principais:

1. Um editor
2. Automações para processos de build
3. Debugger

Obviamente IDEs hoje possuem várias outras funcionalidades, como code highlight, mas elas servem para um propósito: te dar mais produtividade na hora de desenvolver.

A partir desse ponto, podemos concluir também que qualquer editor pode se tornar uma IDE no momento que ele começa a te tornar mais produtivo no desenvolvimento das suas aplicações. Nesse contexto o VS Code, nvim, emacs e vários outros editores entram, pois a partir de plugins conseguem se tornar verdadeiras IDEs nas mãos de seus usuários.

LSPs

Language Servers Protocols, ou simplesmente LSPs, são os resposáveis pela portabilidade e sucesso da maioria dos editores e IDEs modernos. Esses programas tem um objetivo: analizar o seu código e lançar os possíveis erros na sua tela. É a partir de um LSP que sabemos que existe um erro no seguinte código em python:

print('hello world")

sem esse tipo de funcionalidade, poderíamos perder horas procurando um erro bobo como esse em qualquer projeto.

O nvim possui um suporte nativo para LSPs, o que facilita muito na hora de configura-los. Na maioria das distros neovim basta apertar a tecla : para entrar no modo de comando e escrever LspInstall que você poderá instalar o LSP adequado para o arquivo que você está editando e, após instalar, fazer o mesmo para o comando LspStart para iniciar o servidor de linguagem. Esse é o equivalente a baixar um plugin de linguagem no VS Code. Isso pode parecer muito arcaico e rudimentar, mas com o tempo se torna simples e automático.

Existem vários outros programas parecidos com os LSPs:

• DAPs (Debugger Adappters): servem para o processo de debug (exemplo: java-test)
• Linters: reforçam padrões de código (exemplo: eslint)
• Formatters: reforçam formatação de código (exemplo: prettier)

Isso tudo trabalha de baixo dos panos para nos dar produtividade em diferentes IDEs, com o vim podemos ver o que está funcionando de baixo dos panos nitidamente.

Conclusão

Migrar para o nvim me fez ser muito mais produtivo do que eu era utilizando o VS Code, principalmente porque me fez aprender mais e ter mais controle sobre o que eu realmente estou fazendo. Essa mudança me fez me aventurar mais em documentações e manuais, algo que me ajuda até mesmo para pesquisar de forma mais rápida e assertiva quando tenho algum problema no código. É claro que eu não aconselharia a qualquer um trocar o VS Code pelo nvim, mas acho válido se aventurar em novas terras, para não se tornar refém de uma ferramenta.

A partir disso eu pude entender melhor como as IDEs funcionam, além de entender quando um editor de código pode se tornar uma IDE, ao me dar produtividade na hora do desenvolvimento. Por conta disso sei exatamente o que está acontecendo por de baixo dos panos ao utilizar o meu nvim, o que pode ser útil na hora de procurar a solução de possíveis problemas.

Por fim, caso você tenha alguma experiência parecida, fique a vontade para compartilhar nos comentários.