Executando verificação de segurança...
1

Essa issue acabei de ver, nunca tinha visto, mas os post de blogs e o twiter tava ciente.

E realmente foi muito triste isso, foi uma decisão muito chata de como lidar com isso!

Tem muitos problemas citados que não são problemas, mas também não é solução é uma adaptação...
Acho que o mais fácil de citar é o null.
Ele é um problema! Mas e porque é permitido usar no V, porque ele precisa lidar com a interoperabilidade com C.
Olha que legal isso A história do null

E a última coisa, ainda tem muito problema no V! Tem pouca gente trabalhando no V, dev ser dificil fazer o que V faz em 3 anos com 15 dev(chutando) ativos. Go ta ai já tem 13 anos.

Carregando publicação patrocinada...
1

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é.

1

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

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!