Em questão de escala, Rust está se tornando essencial? · thenexusprime

Há algumas semanas atrás tivemos o maior caso de AI Slop do ano (acredito eu), que foi o caso do Bun recriado em Rust. Isso criou uma pequena intriga entre o Andrew Kelley (criador do Zig) e Jarred Sumner.

Isso até mesmo rendeu críticas do Andrew ao Jarred sobre sua qualidade de código, acusando de ser o fator problema e não uma limitação da linguagem. O Jarred, entretanto, manteve sua escolha por algumas questões que eu queria ouvir de vocês se realmente fazem sentido.

Uma das grandes qualidades do Rust é óbvia: o controle de ponteiros. Ele te faz pensar sempre "de quem é esse dado?" e não deixa você passar adiante até resolver essa questão.

Mas isso não seria possível da mesma forma usando Zig em uma estrutura de "free"? Eu sei que deixar com que o compilador faça o trabalho por você de controlar quando liberar é ótimo, mas estou me perguntando se, caso eu escolhesse uma linguagem sem ownership, uma estrutura para lidar com "free" em vez de deixar cada serviço liberar sua própria memória seria uma solução para a escalabilidade do meu produto.

Vocês, desenvolvedores de C, C++ ou linguagens do tipo, já lidaram com problemas como "use after free" e "dangling pointers"? Como resolveram isso em questão de escala?

Queria entender se, na prática, uma boa arquitetura de gerenciamento de memória consegue chegar perto dos benefícios que o Rust oferece nesse aspecto, ou se em determinado nível de complexidade o ownership em compile time acaba se tornando essencial.

Não é bem controle de ponteiros que faz Rust ser interessante.

Nem Zig, C, ou C++ possuem controle do tempo de vida, por isso, todos os programadores nessas linguagens já sofreram com diversos problemas por desconhecer o tempo de vida. Isso é solucionado com cuidado, alguma ferramenta que ajuda ou criando um mecanismo que automatize isso.

Zig tem mecanismos que ajudam, inclusive melhorar a performance, mas não garantem nada. Pode ser suficiente para alguns programadores em alguns casos. Não vou entrar em detalhes.

Quando cria algo que automatize basicamente está criando um garbage collector, então provavelmente deveria escolher uma linguagem que tem um pronto e maduro para uso. Essas linguagens só devem ser escolhidas para uso se você está fazendo um sistema operacional, driver, serviços que precisa altíssima eficiência, mais em memória do que processamento, ainda que algumas linguagens com GC podem entregar resultado parecido sem muito trabalho ou risco.

Só é necessário o controle manual da memória onde você precisa o máximo de controle do que está na memória, e provavelmente ter a melhor performance, embora em muitos casos o GC pode ser mais perfermático. A esmagadora maioria das aplicações não precisa disso, nem deve se questionar.

Embora o controle manual de memória costume manter baixo o consumo de memória, frequentemente ele é mais caro em processamento, a não ser que utilize mecanismos complexos e aceite que a memória sobreviva mais tempo do que ela é usada.

Então a escolha está entre:

usar o gerenciamento automático de memória
o controle do tempo de vida das porções de memória, que o compilador pode conseguir fazer sozinho em alguns casos e você tem que fazer em outros
se arriscar e fazer o melhor que pode para não ter erros de tempo de vida.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).