Info+News+Tech

Introdução

Estamos felizes por ter tido a oportunidade de falar com Ryan sobre seus projetos, os principais desafios em Deno, ouvir suas idéias sobre o futuro do JavaScript e TypeScript, descobrir mais sobre os projetos de ecossistema Deno de terceiros e discutir como ele teria mudado sua abordagem ao Node.js se ele pudesse viajar no tempo!

A entrevista

Evrone: Seu novo projeto Deno é um grande impacto entre os desenvolvedores. O que você está fazendo agora na maioria das vezes?

Ryan: Estou trabalhando em Deno a maior parte do tempo!

Deno é, na verdade, uma coleção moderadamente grande de software que vem junto com o executável que enviamos. Estamos melhorando o tempo de execução do Deno, mas também estamos trabalhando na aplicação da infraestrutura subjacente em projetos comerciais.

Evrone: Você tem experiência prática com várias linguagens de programação: C, Rust, Ruby, JavaScript, TypeScript. Com qual você mais gosta de trabalhar?

Ryan: Eu me divirto mais escrevendo Rust atualmente. Possui uma curva de aprendizado acentuada e não é adequado para muitos problemas; mas para o que estou trabalhando agora está perfeito. É um C ++ muito melhor. Estou convencido de que nunca começarei um novo projeto C ++. A ferrugem é bela em sua capacidade de expressar maquinários de baixo nível com tanta simplicidade.

JavaScript nunca foi minha linguagem favorita – é apenas a linguagem mais comum – e por isso é uma forma útil de expressar muitas ideias.

Não considero o TypeScript uma linguagem separada; sua beleza é que ele está apenas marcado em JavaScript. O TypeScript permite que se construam sistemas maiores e mais robustos em JavaScript, e eu diria que é minha linguagem ideal para pequenas tarefas diárias.

Com o Deno, estamos tentando remover grande parte da complexidade inerente à transpilação do código TypeScript para o JavaScript, na esperança de que isso permita que mais pessoas o utilizem.

Evrone: a digitação gradual foi adicionada com sucesso ao núcleo Python, PHP e Ruby. Qual é, em sua opinião, o principal obstáculo para adicionar tipos ao JavaScript?

Ryan: Os tipos foram adicionados ao JavaScript (com TypeScript) com muito mais sucesso do que em Python, PHP ou Ruby.

TypeScript é JavaScript com tipos. A melhor pergunta é: o que está impedindo a organização de padronização de JavaScript (TC39) de adotar o TypeScript?

A padronização, por design, move-se lenta e cuidadosamente. Eles estão procurando primeiro propor Tipos-como-comentários, o que permitiria que os tempos de execução do JavaScript executassem a sintaxe do TypeScript, ignorando os tipos. Acho que eventualmente o TypeScript (ou algo parecido) será proposto como parte do padrão JavaScript, mas isso levará tempo.

Evrone: Como um usuário VIM respeitável, o que você acha dos editores programadores modernos como o Visual Studio Code? Eles são bons o suficiente para a velha guarda?

Ryan: Todos com quem trabalho usam vscode e adoram. Provavelmente a maioria das pessoas deveria usar isso.

Eu continuo usando o VIM por dois motivos:
1) Estou muito familiarizado e rápido com ele, gosto de poder trabalhar com ssh e tmux e gosto da serenidade de um terminal de tela inteira.
2) É importante que a infraestrutura de software seja baseada em texto e acessível com ferramentas simples.

No mundo Java, eles cometeram o erro de amarrar demais os IDEs aos fluxos de mundo da linguagem, criando uma situação em que praticamente se era forçado a usar um IDE para programar Java. Usando ferramentas simples, asseguro que o software que desenvolvo não se torne desnecessariamente dependente de IDEs.

Se você usar grep em vez de pular para a definição, se tornará intolerável. Pelo que faço, acho que isso resulta em um software melhor.

Evrone: O tempo de execução Deno apresentou as possíveis maneiras de corrigir problemas antigos com gerenciamento de dependências, segurança e muito mais. Você quer que seja como Haskell, um lugar para experimentos, ou você tem algum uso em mente onde possa ser a melhor escolha prática?

Ryan: Não confunda novidade com experimental. O Deno foi criado para ser prático e se baseia em muitos anos de experiência anterior em JS do lado do servidor.

Meus colegas e eu estamos comprometidos em construir um tempo de execução de linguagem dinâmico e prático. As opções de design que fizemos em relação ao gerenciamento de dependência e segurança são bastante conservadoras. Poderíamos ter facilmente introduzido outro sistema centralizado semelhante ao NPM, mas, em vez disso, optamos por um sistema de links baseado em URL padrão da web. Poderíamos ter aberto mais facilmente todos os tipos de brechas de segurança no sistema de arquivos e na rede; em vez disso, optamos por gerenciar o acesso com cuidado, como no navegador.

Deno é um novo software – o que o torna inerentemente inadequado para muitos casos de uso. Mas Deno também é uma grande base de código Rust com alta velocidade, um CI sólido sempre verde e lançamentos regulares programados. Não é um experimento.

Evrone: Em 2020, a maioria das conferências de desenvolvedores de software tornou-se “online” e “virtual”. Você já experimentou o novo formato e o que você achou dele?

Ryan: Eu participei de alguns; mas estou evitando-os por enquanto. Para mim, a melhor parte das conferências são as “pistas de corredor”. Este é um aspecto crítico que falta nas conferências online.

Prefiro assistir as palestras no youtube, no meu tempo livre, na velocidade 2x. Espero poder participar de algumas conferências não virtuais no final de 2021.

Evrone: A ideia de descentralizar o gráfico de dependência de um arquivo em arquivos de código-fonte individuais foi defendida pelo Webpack e elogiada por muitos desenvolvedores. Mas o gerenciamento de dependências é desafiador, levou anos para o Node.js mudar de Common.js para ESM. Quais são os principais desafios de gerenciamento de dependências que você deseja resolver com o Deno?

Ryan: Os navegadores não abençoaram nenhum CDN para distribuir JavaScript – a natureza descentralizada da web é sua maior força. Não vejo por que isso também não funciona para JavaScript do lado do servidor.

Portanto, quero que o Deno não dependa de nenhum banco de dados de código centralizado.

Evrone: Python e JavaScript estão competindo para ser a melhor linguagem de programação de propósito geral que devemos ensinar primeiro aos novos desenvolvedores. Qual é a sua opinião sobre isso?

Ryan: Linguagens de script são boas para iniciantes. Python e JavaScript são, em essência, sistemas bastante semelhantes, com sintaxe diferente e semântica ligeiramente diferente. JavaScript é gerenciado por um comitê de padrões internacionais, executado em qualquer lugar, é cerca de uma ordem de magnitude mais rápido (ao comparar o V8 com o cpython) e tem uma base de usuários maior.

Para certos domínios, existem mais bibliotecas Python disponíveis, particularmente em computação científica. Dependendo do que um novo programador está tentando fazer, Python pode ser apropriado.

No entanto, geralmente, acho que JavaScript é uma linguagem introdutória melhor.

Evrone: O paradigma de simultaneidade assíncrona com um thread principal e pequenos callables “manipuladores” foi um dos pilares do Node.js. Agora, essa ideia é elevada ainda mais com uma nova sintaxe “async / await” e conceito de “corrotinas”. Como um autor de plataforma, o que você pensa sobre eles e suas alternativas disponíveis, como Go “goroutines” ou concorrência baseada em thread Ruby?

Ryan: Os threads do SO não se adaptam bem a aplicativos de alta simultaneidade. Não use Ruby se você tiver muitas conexões simultâneas.

Goroutines são maravilhosamente simples de usar e alcançam o desempenho máximo. Node e Deno são, como Go, construídos em sistemas de notificação de eventos de E / S e SO sem bloqueio (epoll, kqueue).

JavaScript é inerentemente um sistema de thread único, portanto, uma única instância de Node ou Deno geralmente não pode tirar proveito de todos os núcleos da CPU em um sistema sem começar a criar novas instâncias.

Node / Deno são ideais para JavaScript, mas Go é, em última análise, a melhor escolha para sistemas de alta simultaneidade na ausência de outros requisitos que podem inclinar a preferência para JS.

Evrone: Com tanta concorrência ao redor, como você vê o futuro do JavaScript e do TypeScript, especialmente relacionado às áreas de back-end, incorporado e ML?

Ryan: Linguagens dinâmicas (ou ‘scripts’) são úteis. Muitas vezes, o problema que um programador está abordando não está vinculado à CPU. Mais frequentemente, o problema é limitado pelo tempo da engenharia. É mais importante ser capaz de desenvolver e implantar rapidamente.

Das linguagens dinâmicas, JavaScript (JavaScript puro ou JavaScript com tipos) é a mais popular e de longe a mais rápida. No futuro, acredito que a única linguagem dinâmica que alcançaremos será essa estranha linguagem evoluída que surgiu dos navegadores da web.

Com Deno, estamos trabalhando para remover os obstáculos na aplicação de JS em locais onde atualmente não é usado com frequência, como no ML. Por exemplo, provavelmente iremos adicionar suporte WebGPU ao Deno, permitindo a programação fácil e pronta para uso da GPU que eventualmente permitirá que sistemas como TensorFlow.js sejam executados no Deno.

Como mencionei antes, as linguagens dinâmicas têm suas limitações e não são apropriadas para todos os domínios de problemas. Se você estiver programando um banco de dados, faz sentido escrever em uma linguagem que ofereça o máximo de controle sobre o computador – como Rust ou C ++. Se você estiver escrevendo um servidor de API de alta simultaneidade, é difícil imaginar uma escolha melhor do que Go.

Evrone: sistemas operacionais modernos e seu novo tempo de execução Deno introduzem permissões granulares para compensar os riscos de segurança de softwares e dependências de terceiros. Mas é possível para usuários finais e desenvolvedores que usam dependências tomar boas decisões enquanto “permitem” e “recusam” solicitações de segurança de aplicativos? O que você acha sobre o risco de que dentro de alguns anos clicaremos automaticamente em “permitir tudo”, como a maioria de nós faz com as “confirmações de segurança” de cookies de sites agora?

Ryan: Pop-ups de cookies de sites não são a melhor analogia – eles são um subproduto legal bastante inútil.

Melhor é a caixa de diálogo integrada que diz “Permitir que este site acesse sua câmera” ou “Permitir notificações na área de trabalho” ou “Permitir que este site veja sua localização”. Eles não são inúteis – esses são recursos de segurança bastante importantes.

Os programadores executam muitas automações aleatórias em seus computadores. Ninguém tem tempo para auditar todo o código que está prestes a executar, nem é suficiente para executar tudo em um contêiner Docker: quando você executa o lint, isso é isolado? Não, a resposta é que você deve confiar que o script lint não invadirá seu sistema. Eu acho que é muito apropriado permitir que os usuários vejam e potencialmente rejeitem o acesso desnecessário ao sistema.

Evrone: A nova ideia de “pilha completa” promove os desenvolvedores a escrever código de front-end e back-end, o que agora é surpreendentemente fácil com a mesma linguagem e pilha de tecnologia compartilhada como TypeScript. Você acha uma boa ideia que muitos desenvolvedores coloquem tantas coisas diferentes em seu escopo de trabalho diário?

Ryan: Reduzir a complexidade é sempre benéfico. Quanto menos linguagens, VMs, estruturas e conceitos um programador tiver de interagir, melhor.

Evrone: Como você planeja lidar com as atualizações de versão da própria linguagem TypeScript? Dentro do ecossistema Node.js, as atualizações de sintaxe do JavaScript com o mecanismo V8 geralmente resultam em alguns pacotes que não funcionam.

Ryan: A linguagem TypeScript está quase completa em termos de recursos. Os usuários que dependem de recursos de linguagem de ponta podem experimentar instabilidade – não faça isso.

Evrone: Como você vê uma boa educação para um desenvolvedor de software? Precisamos de uma “ciência” como a “ciência da computação” com toda a matemática, algoritmos e estruturas de dados ou precisamos de outra coisa?

Ryan: Pessoas que querem uma carreira em programação deveriam ir para a universidade e estudar ciência da computação. É claro que alguém pode se dar bem com um diploma em áreas relacionadas (como engenharia elétrica, física, matemática); existem muitos engenheiros muito capazes que não têm nenhum diploma.
Mas há realmente algo a ganhar ao passar alguns anos aprendendo os fundamentos e fazendo muitos laboratórios muito difíceis.

Evrone: Com a introdução de plataformas sociais como o GitHub, agora é fácil para desenvolvedores individuais e grandes empresas usar o código aberto e contribuir de volta. É uma “era de ouro do código aberto” agora ou existem problemas que não são visíveis à primeira vista?

Ryan: Certamente o código aberto agora é padrão, a situação do licenciamento é amplamente compreendida e geralmente resolvida. Ainda há dúvidas sobre o modelo de incentivo para manutenção, talvez os patrocinadores do Github estejam ajudando nesse sentido.

É melhor do que antes, mas espero descobrir uma maneira de as pessoas que mantêm partes importantes de software serem pagas de forma independente por seus esforços.

Evrone: Deno já tem alguns anos. Quais são os principais desafios técnicos do projeto no momento?

Ryan: Há muita coisa acontecendo: estamos criando vínculos para o servidor da web Hyper, que fornecerá HTTP / 2 e provavelmente será muito mais rápido do que o servidor da web atual. Estamos construindo “deno lsp”, que fornece o protocolo de servidor de linguagem para que VSCode (e outros IDEs) possam falar diretamente com Deno para obter destaque de sintaxe, verificação de tipo, formatação, etc. – espere que a experiência de edição melhore drasticamente no próximo alguns meses.

Estamos trabalhando para passar o máximo possível nos testes de plataforma da Web – portanto, o Deno está se tornando muito mais compatível com a Web com o tempo. Confira o roteiro do primeiro trimestre para obter mais detalhes.

Evrone: Nossa pergunta típica de viagem no tempo: se você pudesse viajar no tempo e dar apenas um conselho para o seu eu mais jovem quando começou a desenvolver o Node.js, que conselho você daria?

Ryan: No início do Node, eu não tinha certeza se a E / S assíncrona era tratável de usar em grandes projetos por programadores novatos. Eu comecei a dar palestras fazendo essa afirmação, mas não tinha certeza de como isso funcionaria.

Se eu pudesse voltar no tempo, me asseguraria de que funcionaria. Eu então diria a mim mesmo que o Node se tornará uma peça fundamental de software e que grandes projetos de software requerem preocupações diferentes de pequenos projetos: orçamento, comunicação, organização. Eu diria a mim mesmo para gastar mais tempo com esses problemas meta.

Evrone: Algum conselho para desenvolvedores que desejam oferecer suporte ao Deno com seus pacotes npm?

Ryan: Use módulos ES e dê uma olhada em nossa camada de compatibilidade de Nó.

A conclusão

Ficamos felizes em falar com Ryan e aprender mais sobre sua vida, pensamentos e projetos. Na Evrone, usamos frequentemente Node.js para desenvolver soluções personalizadas para nossos clientes. Se você gosta tanto quanto nós, envie-nos uma mensagem através do formulário abaixo e vamos bater um papo!

Encontre aqui vagas em Node

Entrevista via Evrone.com

Deixe uma resposta

Info.CEVIU