Executando verificação de segurança...
Respondendo a "Essa issue acabei de ver, nunca tinha visto, ma..." dentro da publicação Rust, Go, mas e Vlang?
1
kamuridesu

TL;DR: A lang promete demais e entrega de menos

Texto completo:

Sim sim. A questão do null é a lang prometer null safety quando o compilador sequer emite um warning.

Outra questão não é nem querendo que em tão pouco tempo a equipe implementasse tudo, mas sim que eles parassem de falar que a lang tem features que ainda não tem. Novamente, a questão do null safety, que está no README do repositório mas ainda não foi implementado.

O gerenciamento de memória, pelo menos da ultima vez que vi, estava horrível também. O sistema "inovador" de gerenciamento de memória dela (que é só inserir varios free ao transpilar para C) aumentava o memory leak.

Já fazem cerca de dois anos desde a ultima vez que tentei usar. Vou repetir alguns testes e ver se algo mudou, mas com pouca fé.

Carregando publicação patrocinada...
1
Andreldev

Put's, de fato essa quebra de espectativa é ruim mesmo!

Olha sobre essa parte do warning de uso de nil, ou eu ou o post está errado.
Mas olha esse link e faz uns testes https://play.vlang.io/?query=7303deca28
Deixei algumas partes comentadas só para melhorar no teste.

E ele não permite nem compilar(falha com o C), e mesmo assim só é possível utilizar em um bloco unsafe, se o método estiver com um atributo unsafe, ainda assim não é suficiente, porque para cada uso inseguro que a linguagem não recomenda, precisa estar em um bloco unsafe assim como qualquer linguagem, mas cada linguagem possuí sua régua do que é seguro ou não.

E o gerenciamento de memória atual está de fato ruim. Eu esperava que fosse melhor, hoje ficou por padrão o uso de GC, porém ainda está em constantes melhoras(até porque o nativo não pode ter sobrecarga de GC) o gerenciador de memória da linguagem, mas eu to torcendo pra que no final possamos usar tudo o que foi prometido.

(Não sei você, mas eu acho massa demais não precisar estar dando free e vendo onde a memória pode vazar, e com custo zero!(só precisa funcionar 🤣🤣). E eu falo isso porque esses dias tive que estudar um vazamento de memória de um app grande desenvolvido com delphi, não foi uma tarefa trivial. Um free simples depois de um uso é tranquilo, mas tem as passagens de referências de onde começa e onde termina, mas isso você já sabe 😜.)

E vlw demais, esse assunto ta rendendo de uma forma massa! 💪🏻

1
1
Andreldev

Vou sugerir a alteração hoje lá no discord...

Mas a questão do nil, já era possível fazer, só introduziram uma palavra chave para isso.
Eu acho que está tendo uma certa confusão sobre null.

Olha essa delícia aqui https://www.baeldung.com/scala/nil-null-nothing-unit-none. Todos os sabores de null possível, cada lang tem sua abordagem...

Mas eu acho que o mais sensato é o que o C#(acredito que tenha outras que faça o mesmo) vem fazendo em torno do null, usando Nullable<T>.
Lê só https://carlosschults.net/pt/null-problematico. Aqui ele vai falar do início do problema até como contornar esse vício de uso.
Independentemente da linguagem sempre vamos querer tratar a falta de um dado com outra coisa e não com um dado assim... "" ou 0 ou até mesmo Class(instanciada, mas sem valor concreto!). Sempre setimos a necessidade de representar essa ausência de dado.

A maioria do que falo acima, é baseado em muito achimos de uso diário!