27 de maio marca 10 anos desde que
Ryan Dahl lançou a primeira versão do
Node.js. Na última década, o projeto se tornou mais do que bem-sucedido, mas o próprio Ryan já mudou para outras coisas. O que ele está fazendo agora? Como o novo projeto dele pode ajudar os desenvolvedores de JavaScript? O que ele pensa das diferentes línguas, educação e mudança geracional?
25 de maio, dois dias antes da data da rodada, Ryan falará em São Petersburgo em nossa conferência do HolyJS. Enquanto isso, os membros do comitê do programa HolyJS
Eugene bunopus Kot e
Dmitry dmitrymakhnev Makhnev perguntaram-lhe detalhadamente tudo o que
foi dito acima. No Medium, publicamos uma
versão em inglês da entrevista e, para Habr, fizemos uma versão em russo.
Eugene : Muitos leitores já o conhecem graças ao Node.js, mas você poderia nos contar um pouco sobre você?
Ryan : Eu venho de San Diego, Califórnia. Estudei matemática na universidade, e minha especialidade na pós-graduação na Universidade de Rochester era a topologia algébrica. Mas depois de três anos, pensei: “No que estou desperdiçando minha vida? São coisas muito estranhas e abstratas.
Por isso, saí da faculdade, fui viajar e, depois de algum tempo, participei da programação. Eu acho que muitos fizeram um caminho semelhante. Em meados dos anos 2000, envolvi-me em desenvolvimento web. No começo, gostei de Ruby on Rails e Ruby em geral. Quanto ao Node, é uma sorte estar no lugar certo, na hora certa. Coincidentemente, eu estava pensando nos problemas correspondentes exatamente quando o Node se tornou possível.
Eugene : Então foi sorte? Ou você teve uma certa visão desse projeto e, desde o início, assumiu que seria super bem-sucedido?
Ryan : Uma pessoa trabalhará em um projeto se não torcer para ter sucesso? Naturalmente, na maioria das vezes essas esperanças não são atendidas. Desistimos e começamos a fazer outra coisa - como aconteceu com todos os meus projetos, exceto um. Com Node, eu definitivamente tive sorte. Então o Chrome acabou de sair (e com ele o V8), e pensei muito em E / S não bloqueadora e como elas podem ser representadas por estruturas da web, e tudo isso correu bem com o JavaScript.
Eugene : Agora você está fazendo
Deno . Você pode falar sobre o trabalho atual e os planos futuros?
Ryan : Meu colega de longa data
Bert Belder e eu estamos tentando criar uma startup. No último ano e meio, trabalhamos com ele em vários projetos, um deles é o Deno. Bert desempenhou um grande papel no desenvolvimento do Node, ele fez a maior parte do trabalho de portar o Node para o Windows. Além disso, ele é um dos autores de
Libuv .
Eugene : Você acha que Deno espera grande sucesso no futuro próximo? Você continuará trabalhando nisso, digamos, em cinco anos?
Ryan : Eu não tenho idéia se Deno existirá em cinco anos - provavelmente não, porque a maioria dos projetos termina em nada. Mas, por enquanto, Deno me captura e me dá satisfação no trabalho.
Acho que, no momento, não estou satisfeito com o estado em que estão as linguagens dinâmicas. Sinto falta de uma ferramenta rápida, conveniente e bastante versátil. Tanto o Node quanto o Python são bons, mas acho-os excessivamente complexos ou mal projetados de algumas maneiras. Então, no final, estou tentando criar uma ferramenta para meu próprio fluxo de trabalho.
Eugene : Enquanto preparávamos as perguntas, lemos
uma entrevista no site Mapping the Journey. Lá você disse que estava trabalhando com aprendizado de máquina. E logo depois disso, eles levaram e
apresentaram o Deno no JSConf EU. Então seus interesses mudaram?
Ryan : Nos últimos anos, tenho me dedicado a algoritmos de aprendizado de máquina. Não vou entrar nos detalhes do projeto em que estava trabalhando, mas era uma estrutura de aprendizado de máquina JavaScript. Por causa disso, tentei o Node pela primeira vez em anos e isso esclareceu alguns dos meus problemas com o Node. Isso levou à apresentação no JSConf, na qual o protótipo Deno foi mostrado. Então o projeto mostrou um enorme interesse, para que Bert se juntasse. E continuamos a trabalhar nisso. E depois voltarei a esses projetos de ML.
Eu quero especialmente conectar o Deno ao WebGL. Como você provavelmente sabe, o Deno roda na V8, que por sua vez faz parte do vasto mundo da infraestrutura de software Chrome. O Chrome possui uma biblioteca Angle que implementa o WebGL. Conectar-se a isso permitiria que Deno programasse a GPU. E as GPUs são necessárias para o treinamento de modelos de muitas redes neurais modernas. Eu realmente gostaria que o Deno me fornecesse o processo desejado de trabalhar com programação matemática. Acredito que uma parte significativa das tarefas de estatística e matemática como um todo se resume a um tipo de jogo de dados, e isso é muito conveniente para linguagens dinâmicas.
De um modo geral, não existem tantas línguas dinâmicas no mundo, especialmente quando se trata de popular e rápido. Portanto, o JavaScript é ótimo para definir um modelo. Em muitos casos, os cálculos serão transferidos para a GPU, portanto, a velocidade de um idioma dinâmico ou o tempo de execução não serão tão importantes. Em geral, pretendo voltar a todas essas coisas mais cedo ou mais tarde, mas até agora meu foco está em Deno.
Dmitry : O Deno está pronto para uso na produção agora? Você conhece casos interessantes de uso real de Deno?
Ryan : Parece-me que pessoas diferentes têm limites de dor diferentes. Se você está pronto para conviver com bugs, falta de documentação e alteração de APIs, em algumas tarefas o Deno pode ser usado ainda hoje. Mas, em geral, ele ainda não está pronto para a produção. Agora está na versão 0.3 e designarei como 1.0 a versão que considero adequada para uso por outras pessoas. Este é um projeto de larga escala, estamos criando uma nova plataforma. Para fazer isso, muito trabalho precisa ser feito, e estamos tentando fazê-lo corretamente. No entanto, se você é um hacker, não tenha medo de sujar as mãos e deixar um problema ou solicitação no caso de um problema - isso pode ser usado.
Eugene : O que precisa ser adicionado ao Deno para que as empresas comecem a usá-lo na produção?
Ryan : No caso de Deno, focamos em situações diferentes das do Node.js. Estamos tentando fornecer um acesso de nível inferior ao computador. Em particular, queremos que o Deno possa ser importado como
caixa de ferrugem e que possa ser incorporado em outros sistemas.
Suponha que você tenha seu próprio servidor Web ou sistema sem servidor e deseje fornecer aos clientes a capacidade de executar JavaScript. Talvez você não queira descer para o nível V8, um V8 bruto fornecerá pouco. É necessária alguma infraestrutura, mas o tempo de execução completo que alguém em um computador de mesa pode ter já é demais. Esperamos cobrir esse cenário de "incorporação". Ainda estamos trabalhando na aparência da API nesse caso. Também temos problemas de desempenho que estamos
seguindo . Precisamos fornecer uma documentação melhor. Em geral, há trabalho a fazer.
Dmitry : Uma das tarefas de Deno é o suporte interno ao TypeScript. Recentemente, o TypeScript se espalhou bastante, muitas empresas começaram a usá-lo não apenas no navegador, mas também no Node.js. Ouvi dizer que o pessoal da equipe principal do Node.js. também o elogiou. Na sua opinião, o TypeScript pode substituir o JavaScript nos navegadores e adquirir seu próprio tempo de execução (possivelmente com uma máquina virtual)?
Ryan : Um dos benefícios do TypeScript é que ele é um superconjunto de JavaScript, portanto não o substituirá. O que eu realmente posso imaginar é que o TypeScript se enquadra nos padrões e os tipos opcionais aparecem no JavaScript, mas isso acontecerá muito em breve.
Linguagens dinâmicas são muito úteis para o estágio inicial de desenvolvimento, por exemplo, quando você protótipo de algo. A vantagem do TypeScript (e a idéia de tipos opcionais em geral) é que, à medida que o protótipo amadurece gradualmente, você pode gradualmente "torcer" a implementação anotando o código com os tipos. Isso não precisa acontecer ao mesmo tempo, portanto você ainda pode se mover muito rápido e delinear novas idéias em JavaScript.
Quanto à possibilidade de usar tipos na máquina virtual V8 para otimizar o tempo de execução, eu não sei. Parece muito difícil, e não tenho competência suficiente para dizer se haverá um ganho significativo. Na Deno, usamos o compilador TypeScript implementado em JavaScript. Você pode imaginar uma implementação Rust de um compilador que se traduz em JavaScript mais rapidamente. Isso é possível, o projeto
swc está trabalhando nele.
Eugene : O TypeScript pode substituir o JavaScript? Suponha que, no ES 2020, o TypeScript seja mesclado em um idioma com JavaScript.
Ryan : Sim, tipos podem muito bem ser adicionados ao padrão. O TC 39 parece regular os padrões de JavaScript? Até onde eu sei, até agora essa possibilidade não foi discutida. Mas acho que ainda há muito tempo, embora seja possível.
Eugene : Você conhece o Dart? Você já usou isso? O que você acha dele?
Ryan : Tentei por curiosidade, mas isso foi há muito tempo. Os objetivos do Dart são semelhantes ao TypeScript - é uma linguagem dinâmica com tipos opcionais. Como eu disse, isso permite que você organize muito convenientemente seu fluxo de trabalho. Mas, diferentemente do TypeScript, o Dart não é um superconjunto de JavaScript, é uma linguagem diferente. Talvez por isso, se espalhe muito mais lentamente.
É verdade que Flutter ganhou popularidade agora, então talvez eu tenha ficado para trás na vida aqui. De uma forma ou de outra, o TypeScript conseguiu atingir o mesmo objetivo sem criar uma nova linguagem.
Quando um novo idioma aparece, é fácil para ele despertar curiosidade, mas levar as pessoas a usá-lo é muito mais difícil. Os benefícios devem ser muito significativos. Por exemplo, eu era muito cético sobre Rust. Pareceu-me que tudo o que ele pode fazer já está em C ++, que eu uso ativamente. Só recentemente conheci o Rust mais de perto e ficou claro que para mim ele pode substituir facilmente o C ++. Em geral, para que um novo idioma seja bem-sucedido, ele precisa ser uma ordem de magnitude melhor do que o antigo.
Eugene : Com idiomas - como com carros, de qualquer maneira você às vezes pega um ônibus.
Ryan : Exatamente.
Eugene : Apesar da popularidade do TypeScript, o JavaScript agora é geralmente onipresente: no back-end, front-end, em dispositivos móveis, no React Native, no Raspberry Pi e assim por diante. Aparentemente, temos uma revolução, e há uma linguagem que pode fazer tudo. Isso é realmente assim? Ou sempre haverá idiomas especiais para tarefas especiais?
Ryan : O JavaScript é tão interessante porque funciona em qualquer lugar. Mas é importante notar que, embora muitas pessoas percebam o TypeScript como uma linguagem separada, ele compila em JavaScript. Portanto, do meu ponto de vista, o TypeScript também funciona em qualquer lugar. Em geral, eu concordo com sua declaração. Obviamente, no futuro próximo, o JavaScript continuará sendo o idioma dos navegadores e de vários dispositivos. Portanto, continuo a usá-lo - ele oferece uma ampla gama de possibilidades.
Dmitry : Mas você não acha que essa popularidade do JavaScript poderia ser pior? A web agora se tornou uma plataforma indispensável para qualquer serviço, e o JavaScript é o único idioma no qual você pode escrever serviços da web em produção. Talvez fosse melhor se tivéssemos uma escolha, e todas as plataformas não fossem afiadas em um único idioma? Talvez precisemos de diferentes máquinas virtuais nos navegadores?
Ryan : Eu acho que foi isso que causou a popularidade do Wasm. Nele, você pode compilar, digamos, Rust em código que pode ser executado em um navegador.
Parece incrível, mas eu me pergunto o quão bem ele funciona para idiomas com coleta de lixo ou outras ferramentas de tempo de execução. Embora possa ser tecnicamente possível usar o Python através do Wasm para criar um site, suspeito que o resultado seja complicado e lento. Eu acho que apenas a experiência será mostrada aqui.
Dmitry : Ou seja, se eu quiser usar algo em vez de JavaScript, preciso aprender uma linguagem que possa ser transformada em Wasm?
Ryan : Ou em JavaScript. O fato é que o JavaScript tem um coletor de lixo e muito mais. Portanto, se você usar uma linguagem dinâmica, faz mais sentido traduzir para JavaScript do que compilar no Wasm e, ao mesmo tempo, compilar todo o tempo de execução, incluindo coletor de lixo e muito mais. Você precisará investir muitos recursos, embora o V8 provavelmente faça melhor com a coleta de lixo. Mas sim, o Dart compila em JavaScript e você pode escrever sites nele. Existem outros idiomas que fazem o mesmo.
Dmitry : Como estamos falando de idiomas diferentes, qual idioma antigo ou novo você acha interessante para estudar em 2019?
Ryan : Eu realmente gosto de Rust. Ele tem muitos achados interessantes, por exemplo, a idéia de um único objeto mutável. Possui um ótimo compilador que fornece código extremamente otimizado. Mas entender Rust não é fácil. Levei vários meses para entender o que estava acontecendo lá. Em geral, Rust é uma linguagem muito interessante, mas de modo algum universal.
Se você está apenas escrevendo um aplicativo, provavelmente não o escreverá no Rust, mas em algo mais simples: Ruby, JavaScript ou Python. Mas há algumas situações em que a Rust faz seu trabalho de maneira brilhante. Por exemplo, é ótimo para escrever bancos de dados, servidores da Web ou, no nosso caso, máquinas virtuais. Ele oferece controle total sobre tudo o que acontece no seu código, mas com o custo da complexidade, que é aberto ao desenvolvedor.
Ferrugem é uma nova palavra ao escrever código de baixo nível; possui vantagens significativas sobre o Go. O Go possui um coletor de lixo, por isso é ótimo para servidores de alto desempenho, é conciso e é muito simples escrever nele. No entanto, há momentos em que ter um coletor de lixo pode ser um sinal de menos, não uma vantagem. Deno, por exemplo, tem esse caso. Enrolamos um V8 que já possui um coletor de lixo. Dois colecionadores em um processo acabariam, e sua interação pode parecer catastrófica. O V8 já é monstruosamente complexo por si só. Em geral, Rust é perfeito para nossos propósitos. Será interessante ver quais novas aplicações existem para o Rust quando ele pode ser compilado no Wasm.
Dmitry : O que você acha da crescente popularidade das linguagens funcionais? Por exemplo, Elm para o frontend, ou Idris.
Ryan : Eu não tentei nenhum deles, então não posso dizer nada sobre eles.
Eugene : E as linguagens funcionais em geral?
Ryan : O estilo funcional é muito bom. Isso não significa que o aplicativo inteiro deva consistir apenas em mapa, redução e similares. Há situações em que é mais fácil trabalhar em um estilo imperativo e mais fácil de ler. Ambas as abordagens são muito bem combinadas em Rust e JavaScript, portanto, não é necessário limitar-se a apenas uma. Por fim, a CPU ainda é imperativa, funciona de acordo com as instruções enviadas a ela. Portanto, é aconselhável pensar em código no mesmo paradigma.
Eugene : E em que estilo Deno é escrito? Orientado a objetos ou funcional?
Ryan : Usou os dois. Tudo depende do objetivo específico que estamos tentando alcançar.
Eugene : Já discutimos quais idiomas você prefere, mas e as ferramentas? Qual é o seu IDE favorito? Você escreve no MacOS ou Linux?
Ryan : Eu escrevo no vim, uso o iTerm2 e meu computador é um pequeno MacBook. Viajo muito e, por isso, frequentemente trabalho em um laptop. A certa altura, notei que, depois de trabalhar atrás de um monitor grande, é muito doloroso para mim mudar para um laptop. Portanto, eu me ensinei a trabalhar em um laptop o tempo todo.
Na minha casa é uma unidade de sistema baseada em Linux, estou conectando a ela via SSH. Eu sou bastante antiquado na escolha de ferramentas, principalmente essas são coisas do tipo UNIX. Estou usando o LLDB para depuração.
Eu trabalhei no Visual Studio Code, mas agora estamos criando nossa própria plataforma, portanto não há muitas integrações que você se acostuma a esperar do IDE. Normalmente, essas coisas não têm nada a ver com o que estou trabalhando e, no final, tudo isso me distrai. Estou acostumado a trabalhar com código simples, isso é especialmente conveniente no desenvolvimento de software de baixo nível. Acho que se escrevesse um site ou aplicativo para uma plataforma popular, usaria o Visual Studio Code.
Eugene : Em geral, você é um programador da velha escola.
Ryan : Provavelmente sim.
Eugene : Então a próxima pergunta será sobre a escola. Aparentemente, as habilidades básicas de programação em um futuro próximo serão estudadas na escola, juntamente com matemática, inglês e outras disciplinas. O que você acha disso? Talvez em um futuro um pouco mais distante, o aprendizado de máquina também entre no currículo da escola?
Ryan : Eu tenho programado nos últimos 15 anos e, durante esse período, nossa comunidade cresceu muito. Em 2005, pareceu-me que eu perdi o mais importante, embora pelos padrões de hoje ainda fôssemos poucos. Agora, programadores estão em toda parte. Obviamente, a programação cresceu para um grande público. Tornou-se uma habilidade importante para um grande número de pessoas. E com isso em mente, sim, a programação deve ser ensinada no ensino médio. Mas sobre aprendizado de máquina, acho que coisas mais fundamentais são mais úteis para estudantes do ensino médio.
Parece-me que nas aulas de matemática vale a pena estudar mais ativamente as estatísticas. Nos EUA, no ensino médio, os alunos passam por álgebra, equações quadráticas, o início da análise analítica, derivadas e similares. Álgebra e matan ocupam a maior parte do programa e, em seguida, uma parte muito pequena das pessoas os utiliza regularmente. Mas muitos profissionais precisam ser capazes de processar dados estatísticos.
Quanto ao aprendizado de máquina, ele ainda está em estágio experimental. É improvável que, em dez anos, tudo pareça o que é agora - essa área está mudando muito rapidamente.
Eugene : Como estávamos conversando sobre a geração mais jovem, fizemos uma excursão da escola em nosso escritório há cerca de uma semana. , 15 , , Python Rust. , 2005 , , -, . , YouTube . , .
: .
: , ?
: , . , . YouTube . , . . , , - , . , . .
: , , . ? - , ?
: , , . , . , , . - Rust, , Rust. , : .
: , , — ? - Rust, . ?
: . - ?
: . , , . ? pull requests ? , ?
: . .
: , . YouTube, . - ? ?
: — . YouTube, . Hacker News Reddit, — - . , , - . YouTube . - , . , (, ), YouTube.
: ?
: , . , , JavaScript. — , . . , , . HolyJS. ?
:
2016 , .
:
, NodeJS . . ? ? ?
: , Joyent. , , , . , , Deno, . , Deno.
: , ?
: , , . , , , . , . -, , , . , . , , , , , . , — …
: , V8 Volkswagen Beetle?
: !
: , V8.
: , , . , . , , , .
: . ? , . , . ?
: , . , . . , Facebook Google, . - , — , . , . , . - , .
: IT , « » , . , . , IT , ?
: , « » — , . , . , , . , . .
: . , — , — . , . ?
: . , . .
: . , ?
: . .
: , , ?
: , . , - , — . , — , .
: HolyJS 2019 -. , !
: , .
No HolyJS em maio, Ryan vai falar mais sobre Deno: ele abrirá o evento com sua performance “Deno, um novo caminho para o JavaScript”. Além disso, a conferência terá dezenas de outros relatórios.
Devido à alta demanda, fechamos a venda de ingressos para visitas pessoais, mas os ingressos on-line permanecem disponíveis (eles dão acesso à transmissão on-line de todos os relatórios durante a conferência e a seus vídeos depois). Portanto, mesmo que você não esteja em São Petersburgo, de 24 a 25 de maio, ainda poderá assistir às apresentações de Ryan e outros.