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

Existem várias críticas a V, desde sua concepção. A linguagem até hoje não consegue cumprir vários de seus objetivos.

Uma pessoa escreveu um artigo em seu blog e foi bloqueada no Twitter pelo time da Vlang.

Houve também uma discussão no Github onde o autor deletava comentários e sempre reagia com postura agressiva a qualquer crítica válida. Ele diz que algumas críticas são desinformação mas não as corrige. Isso levantou muitas suspeitas.

Enfim, tenho muitas dúvidas sobre essa linguagem. Vou esperar até sair a stable para ver se entregaram tudo o que foi prometido.

Carregando publicação patrocinada...
3

É foda, mano.
Eu tento contruir com o projeto faz um tempo.
Já fiz várias coisas para contrubuir para o projeto. Se eu vejo algo que não funciona, eu vou lá e crio um PR. O problema é várias pessoas vão só para criticar (não que críticas tbm não seja bom) e nunca para contribuir. Aí vão lá, criticam não ajudam em nada e esperam que a solução esteja pronta no outro dia. O vlang evoluiu muito; tem muito a evoluir ainda (ainda está em beta). Mas precisa de alguns detalhes para serem ajustados.
O foda é que os caras estão sozinhos para resolver.
Se vc participa do grupo no discord (https://discord.gg/vlang) vai ver que todo mudo lá é muito gente boa. e tá todo mundo dando o sangue para a linguagem evoluir.

1

Eu não tenho problemas com a lang se não tivessem prometido tanto. Eu te prometo um fusca que anda na terra e na água e te entrego um que mal anda na terra, claro que você vai ficar decepcionado e me questionar.

Leia novamente aqui: https://www.tabnews.com.br/kamuridesu/1f8a702a-a48c-4671-abf6-12228feaeebb

As críticas não foram sobre a linguagem em si, mas sim sobre o que foi prometido. A linguagem é boa, mas engaram as pessoas dando a entender que x funcionalidade já havia sido implementada quando não foi.

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.

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!

1

A moeda sempre tem 2 lados,
Nunca tinha ouvido falar disso, minha analise não é em relação "ao que ocorreu", mas aos comportamentos,
Neste "mundo atual de tecnologia" sempre esperamos o perfeito e melhor (que o anterior), dificilmente damos chance à evolução de algo que iniciou "do zero",
Por outro lado, quem desenvolveu, (às vezes, ) tem "amor" pelo que fez, e reluta em aceitar críticas.
Mas os dois lados, estão certos e errados em parte, o meio termo seria o ideal, mas muitas vezes é dicifil de encontrar.

1