Primeiro de tudo, este é um artigo traduzido do Node.JS. de despedida de TJ.JS. De fato, sofri algum impacto depois de ler este artigo, mas não concordo com algumas das opiniões do autor. Por exemplo, acho que o registro de pacotes do Node.JS é uma de suas muitas vantagens, mas o GO está um pouco falta a esse respeito. Devido ao nível pessoal, não entendo muitas coisas ao traduzir. Também fui ao blog do autor e Stackoverflow para fazer algumas perguntas para obter respostas. Ainda há muitas coisas que não estão em vigor na tradução, e espero obter um ponto de vista.
Ps. Como iniciante node.js, graças a TJ por seus esforços e percorreu todo o caminho.
texto:
Diga adeus ao Node.js
Deixando o reino do Node.js
Eu tenho lutado contra o Node.js em produção há muito tempo e, infelizmente, já que não gostava mais de trabalhar nesse trabalho, pelo menos neste momento, é minha despedida oficial. Mais importante, preciso de um mantenedor.
O Node é realmente ótimo em alguns aspectos, mas não é uma ferramenta adequada, afinal, para o tipo de software em que estou interessado ultimamente. Ainda pretendo usar o Node como um site, mas se você estiver interessado em manter qualquer projeto, deixe uma mensagem para anotar seu nome de usuário do Github, nome de usuário do npm e nome do projeto para me informar. Normalmente, tudo o que peço é que você não altere completamente sua API existente. Se você realmente deseja fazer isso, é melhor iniciar um novo projeto.
Koa é um projeto que continuarei a manter. (Com CO e amigos)
A história do Santo Graal
Eu sempre amei C, mas todo mundo que trabalha em desenvolvimento C sabe que é valioso, mas propenso a erros. É difícil provar a escolha da linguagem no trabalho diário, pois não é exatamente o trabalho mais rápido. A simplicidade também é a razão pela qual sempre foi elogiada, mas você não vai muito longe sem muitos modelos.
À medida que mais pessoas participam do desenvolvimento de sistemas distribuídos, a tendência de desenvolvimento do desempenho dos nó sobre usabilidade e robustez me deixou mais frustrada. Na semana passada, reescrevi um sistema distribuído relativamente grande em Go, que é robusto, tem um desempenho melhor e é fácil de manter e tem uma cobertura melhor testável devido à beleza geral e mais fácil de desenvolver código síncrono.
Não estou dizendo que Go é um Santo Graal, não é perfeito, mas Go é uma excelente resposta para mim para muitos idiomas que existem hoje. À medida que mais e mais desses idiomas de "próxima geração" como Rust e Julia encontram seu próprio lugar e maduro, tenho certeza de que teremos mais ótimas soluções.
Pessoalmente, estou muito empolgado com o GO por causa de sua velocidade de iteração, estou muito empolgado ao ver que eles estão ansiosos para chegar à versão 2.0 e, de acordo com as notícias que ouvi, elas não têm medo de quebrar as grandes coisas originais. Se for verdade, estou feliz, mais porque acredito que, se for realmente benéfico para esse idioma, devo quebrar rapidamente o que já está lá. Mas também não sou uma gigante de software que executa muitos sistemas. : D
Editado por: Devo ter interpretado mal algumas listas de discussão de envio e elas não estão ansiosas para fazer algumas mudanças destrutivas a qualquer momento. @enneff
Por que ir?
Se o Node funcionar para você e você não tem nada com que se preocupar, ainda é uma ótima ferramenta. Mas se algo o incomoda, não se esqueça de pular da sua caixa e ver o que mais está fora da caixa - eu fui atraído por algumas horas de uso inicialmente, vá para construir o produto.
Novamente, não estou lá para dizer que Go é definitivamente o melhor idioma e você precisa acompanhar. Mas, para sua idade, é muito maduro e robusto. (Na mesma idade que o nó). A reconstrução do tipo é divertida e simples, as ferramentas de lição de casa e depuração fornecidas por Go são ótimas, e a comunidade tem regulamentos muito fortes sobre documentação, formatos, benchmarks e design de API.
Enquanto estava tão acostumado ao nó extremamente modular e tendo experimentado a biblioteca padrão podre de Ruby, quando ouvi falar pela primeira vez, pensei que sua biblioteca padrão era horrível. Depois que mergulhei nesse idioma, percebi que a maioria das bibliotecas padrão é necessária nesta fase, como compactação, JSON, IO, IO buffer, operações de cordas etc. A maioria dessas APIs é bem definida e poderosa. É fácil escrever o programa inteiro apenas usando essas bibliotecas padrão.
Pacotes Go de terceiros
A maioria das bibliotecas GO parece semelhante, a maioria do código de terceiros que usei até agora é de alta qualidade e é difícil encontrá-las no nó, porque o JavaScript atrai desenvolvedores em diferentes níveis de habilidade.
Não há registro para pacotes Go, então você geralmente verá 5 ou 6 mesmos pacotes ao mesmo tempo. Em algum momento, isso pode causar alguma confusão, mas tem um efeito colateral interessante e você deve decidir qual é a melhor opção revisando cuidadosamente cada pacote. Através do nó, geralmente existem pacotes de especificações como "Redis", "Native MongoDB" ou "Zeromq", então você vai parar por aí e inferir que eles são os melhores.
Se você estiver fazendo algum trabalho distribuído, encontrará os impressionantes tipos concorrentes de dados subjacentes de Go para serem muito úteis. Podemos obter algo semelhante por geradores no nó, mas na minha opinião geradores estão apenas pela metade. Sem manuseio de erros independentes, a pilha de relatórios ainda é comum, mesmo que seja melhor. Quando essas soluções funcionam bem, não quero esperar a comunidade reorganizar por três anos.
Na minha opinião, o tratamento de erros de Go é excelente. O nó é ótimo em termos do que você deve pensar sobre todos os erros e decidir como fazê -lo. No entanto, o nó falha em:
Você pode repetir o retorno de chamada
Você não pode fazer um retorno de chamada e se perder em um estado instável (por exemplo, esqueça de passar um erro para lidar com o retorno de chamada. Quando ocorrer um erro, o nó engolirá o erro sem feedback)
Você pode receber o erro de take -away
Emissores podem obter vários eventos errados
Esqueci o evento errado para lidar com ele vai arruinar tudo
Muitas vezes não tenho certeza do que é necessário para lidar com erros
O manuseio de erros é muito redundante
O retorno de chamada é terrível
Em Go, quando meu código termina, termina e você não pode reexecutá-lo em um comunicado. Isso é incerto no nó. Você pensará que um programa é totalmente executado até que uma biblioteca chama inesperadamente um retorno de chamada várias vezes, ou não limpa os manipuladores corretamente e faça com que o código seja executado novamente. É muito difícil encontrar essas razões no código de produção real, por que se preocupar com isso? Outros idiomas não permitem que você experimente essas dores.
O nó do futuro
Ainda espero que o Node faça um bom trabalho, muitas pessoas investem enormemente nele, e tem esse potencial. Eu acho que Joyent e a equipe precisam se concentrar na usabilidade - se o seu aplicativo for frágil e difícil de depurar, refatorar e desenvolver, o desempenho não tem sentido.
Em 4-5 anos, ainda teremos esse erro vago "Erro: getaddrinfo eaddrinfo", e esse fato nos diz onde estão as prioridades de desenvolvimento do nó. Compreensivelmente, quando você se concentra na construção do núcleo do sistema, é fácil perder essas coisas. Eu acho que os usuários expressaram suas opiniões sobre essas coisas repetidamente, mas não viram nenhum resultado. Normalmente, recebemos algumas respostas para afirmar que o que temos já é perfeito. Na prática, esse não é o caso.
Os fluxos são interrompidos, os retornos de chamada não são fáceis de usar, os erros não são claros, as ferramentas não são fáceis de usar, os regulamentos da comunidade existem, mas parecem falta em comparação com o Go. Apesar disso, posso continuar usando o nó para algumas tarefas específicas, como criar páginas da Web ou algumas APIs ou protótipos fragmentados. Se o nó puder corrigir alguns de seus problemas fundamentais, ele terá a chance de permanecer relevante, mas quando há outra solução que executa maior que a disponibilidade quando os argumentos de maior desempenho e maior disponibilidade não vão muito longe.
Se a comunidade do nó decidir adotar geradores e implementá -los em um nó muito central e passar erros adequadamente, há uma chance de tornar isso referenciável. Isso melhorará completamente a usabilidade e a robustez do nó.
A boa notícia é que eu conversei com um cara ótimo e talentoso que contribuiu com o código principal em Strongloop há pouco tempo. Eles estão adotando explicitamente a maneira correta de corrigir esses problemas para facilitar o trabalho de nós futuros, ouvindo as respostas dos desenvolvedores à plataforma e planejando encontrar a maneira certa de corrigir esses problemas. Não tenho certeza de como o conflito entre várias empresas no desenvolvimento simultâneo da parte principal terminará, mas espero que o motorista do desenvolvedor vencê.
Isso não significa que é um ataque a indivíduos, muitas pessoas realmente talentosas estão trabalhando ou no nó, mas isso não é mais algo em que estou interessado. Eu me diverti muito na comunidade de nós e conheci pessoas realmente interessantes.
O significado da história é que você não deve ser restrito pelo seu próprio círculo! Veja o que em outro lugar e você poderá gostar de programar novamente. Existem muitas soluções incríveis fora disso, e o erro que cometi é que esperei muito tempo para brincar com elas!