Há alguns anos, eu programava exclusivamente em .NET C#. Na empresa onde trabalhava, havia um ERP para Windows Desktop escrito em Visual DataFlex (VDF para os íntimos), e surgiu a necessidade de integrar o sistema com APIs externas. Me perguntaram se eu toparia fazer essas integrações, e eu aceitei o desafio. O problema? Eu não sabia nada de VDF. Começamos, então, a buscar formas de integrar minha implementação em .NET C# com o ERP. Como cada cliente tinha necessidades diferentes e o sistema rodava de maneiras distintas em cada um, acabamos criando duas implementações iniciais:

Primeira implementação:

O ERP utilizava um banco de dados baseado em arquivos .dat, então decidimos levantar um banco SQL Server. O ERP chamaria minha aplicação (que chamávamos de integrador) via linha de comando, eu processaria a solicitação e gravaria os retornos no banco, que seriam lidos posteriormente pelo ERP.

Essa solução funcionou bem para alguns clientes, mas para empresas menores, manter um banco SQL Server só para o integrador parecia um exagero. Além disso, alguns clientes tinham servidores mais simples, já sobrecarregados pelas aplicações existentes, tornando inviável rodar mais uma aplicação.

Segunda implementação:

Em vez do banco SQL, o ERP me enviaria um comando e um arquivo .csv. Eu interpretaria esses dados, processaria a informação e geraria um outro arquivo com o retorno, que o ERP poderia ler. O problema dessa abordagem era que o ERP ficava esperando a execução do integrador para poder ler o arquivo de retorno, o que não me agradava. Nenhuma dessas soluções parecia ideal, então continuei buscando outras formas…

Testando novas implementações

Sou autodidata. Na verdade, na data dessa postagem, acabei de entrar na faculdade de Ciência da Computação. Quem dera, na época, fosse tão fácil quanto hoje, onde basta perguntar para uma IA! Quando surgia um desafio desses, a solução era correr para o Google, Stack Overflow e documentações para descobrir se existiam outras formas de resolver o problema.

Primeiro teste

Na época, queríamos algo mais simples, sem precisar de conexão via HTTP (ironicamente, depois descobrimos que teria sido mais fácil usar isso desde o início). Foi aí que conheci a Interoperabilidade COM, um padrão do Windows que permitia criar uma DLL em C# e expor suas funções para outras linguagens.

No entanto, essa abordagem foi logo descartada, pois exigia a criação de um arquivo de manifesto no VDF, o que traria mais complexidade. Além disso, eu havia acabado de migrar do Windows para o Linux, o que foi mais um motivo para abandonar a Interoperabilidade COM. Foi nesse momento que comecei a enfrentar outro problema: as constantes atualizações do runtime do .NET. Cada nova versão exigia que todos os servidores dos clientes fossem atualizados, o que se tornava uma grande dor de cabeça.

Segundo teste

O .NET Core já havia sido lançado, mas eu ainda precisava resolver o problema das atualizações de runtime. Então, comecei a testar C++. Minha lógica era simples: se eu compilasse o código diretamente para Windows, tudo funcionaria, e eu não precisaria mais me preocupar com runtime. Ah, se fosse tão fácil assim…

Sair de linguagens com muitas abstrações, como C#, e mergulhar no C++ significava horas e horas de estudo. E aí veio outra barreira: vindo de um ambiente onde gerenciadores de pacotes facilitam a vida, configurar dependências e compilação no C++ foi um desafio enorme. Para piorar, eu ainda tinha que lidar com problemas de acentuação, já que os arquivos estavam em ANSI.

E, para ser sincero, como eu havia acabado de migrar para Linux, o que já aumentava e muito a complexidade, até hoje não sei como não desisti nessa fase.

Como descobri o Rust?

Navegando pelos fóruns, comecei a ler sobre Rust, uma linguagem que prometia alto desempenho e segurança de memória. Gerenciamento de memória sempre foi um pesadelo para quem vem de linguagens com Garbage Collector (GC), então a ideia de uma linguagem segura e eficiente me chamou atenção. Além disso, Rust já vinha com um gerenciador de pacotes, então pensei: por que não começar a brincadeira?

Mais uma vez, sofri.

O pessoal nos fóruns já avisava que Rust era bem diferente. A sintaxe não era baseada em C/C++, como C# ou PHP, mas aprender a estrutura da linguagem em si não foi um problema. O verdadeiro desafio veio com Ownership e Borrowing.

Como eu disse antes, na época não existiam IAs para ajudar. O jeito era estudar pela documentação – algo que, hoje em dia, muita gente evita. A cada nova dificuldade com Ownership e Borrowing, minha frustração aumentava, mas, ao mesmo tempo, eu ficava mais determinado. Quanto mais eu lia sobre o potencial do Rust no futuro, mais queria aprender.

Foi então que descobri o FFI (Foreign Function Interface), uma forma de chamar funções escritas em uma linguagem a partir de outra. Depois de bater cabeça com strings em Rust – e me perguntar, ironicamente, por que tantos tipos para representar textos, um char[] resolveria? – acabei lembrando que, em C, isso também nunca foi simples. –, finalmente consegui lançar uma versão de testes. Ela recebia um JSON, processava os dados e retornava outro JSON.

Agora eu havia conseguido exatamente o que queria:

1 - Sem dependência de runtime

2 - Sem arquivos temporários

3 - Sem configuração de ambiente

O integrador agora era um único arquivo DLL (para Windows), que bastava ser colocado na mesma pasta do .exe do ERP. Para o desenvolvedor, tudo se resumia a três linhas de código:

1 - Instanciar o objeto da DLL

2 - Enviar o comando

3 - Ler o retorno

Além de ficar muito mais fácil de implementar no cliente, o integrador se tornou muito mais performático.

Outro ponto que me fez apaixonar por Rust foi a “independência”: antes, eu era o responsável por acessar os servidores para configurar e atualizar o ambiente. Com essa implementação, o próprio suporte do ERP apenas atualizava a DLL no cliente a cada nova versão.

Como estamos hoje?

Atualmente, esse ERP se modernizou: agora utiliza um banco SQL e tem sua própria API REST. No entanto, algumas integrações ainda continuam sendo feitas por DLLs escritas em Rust – que, hoje, estão muito mais bem estruturadas.

Apesar de, no momento, meu ganha-pão não depender diretamente de Rust, sigo cada vez mais apaixonado pela linguagem e acredito que, em um futuro próximo, ela trará retornos financeiros ainda maiores.

Se você chegou até aqui, obrigado por ler sobre essa jornada que começou com um simples integrador, mas que me levou a dedicar incontáveis horas de estudo – e que, na verdade, ainda está só no começo.

Obrigado e fique com Deus!