Entrevista com Ryan Dahl, criador do Node.js

Ryan Dahl introduziu o Node.js em 2009, aposentou-se alguns anos depois e fez um novo projeto na semana passada: deno - Um tempo de execução TypeScript seguro no V8 ( GitHub , descompactando ).

É hora de relembrar a entrevista que Ryan deu ao podcast Mapping The Journey em agosto de 2017, sobre si mesmo, sua carreira, sobre o Node.js e por que ele parou de fazer isso, no que está trabalhando agora (naquele momento).

Um fragmento da tradução desta entrevista já estava em Habré: Creator of Node.js: "Para servidores, não consigo imaginar outro idioma além de Go" . Este post contém a tradução completa.

Ryan Dahl é engenheiro do projeto Google Brain e criador do Node.js, um tempo de execução JavaScript baseado no mecanismo Chrome V8. Ryan está atualmente envolvido em pesquisas de aprendizado profundo. Ele trabalha principalmente na transformação de imagens - colorização e super-resolução. Ele participou do desenvolvimento de vários projetos de código aberto, incluindo HTTP Parser e libuv.

Pramod: Olá pessoal. Bem-vindo ao Mapeando a Jornada. Quando se trata de Node.js, todo mundo sabe o nome de Ryan Dahl. Ele mostrou que estamos lidando com entrada / saída incorretamente e nos ensinou como desenvolver usando o modelo "puro assíncrono". Nosso convidado hoje é Ryan Dahl, um hacker, programador talentoso e criador de Node. Ryan, estou muito feliz em conhecê-lo, é uma grande honra. Bem-vindo

Ryan: Oi! Também estou feliz em vê-lo.

P .: Ryan, você é mais conhecido como o criador do Node. Diga-me, o que você fez antes de se interessar por tecnologia?

R: Quando criança, eu morava em San Diego. Quando eu tinha 6 anos, minha mãe me comprou um Apple 2C, então eu tive acesso a um computador muito cedo. A propósito, agora tenho 36 anos. Então, eu cresci apenas durante a formação da Internet. No começo, estudei em uma faculdade local e, depois dele, entrei na Universidade da Califórnia em San Diego para estudar matemática. Então entrei na escola de graduação em matemática da Universidade de Rochester. Sim, estudei topologia algébrica - uma disciplina bastante abstrata que me pareceu muito bonita. Mas depois de algum tempo fiquei entediado, porque pensei que ela não tinha aplicações da vida real. Depois de me formar, decidi fazer doutorado, mas percebi que não queria dedicar o resto da minha vida à matemática e desisti do programa. Comprei uma passagem só de ida para a América do Sul e passei um ano lá como "estudante faminto". E então ele começou a fazer sites com um cara, Eric. E assim começou minha carreira como desenvolvedor. Criei um site no Ruby on Rails para uma empresa de snowboard.

P .: Ótimo! Esta é provavelmente uma experiência interessante - saia do programa de doutorado, vá para a América do Sul e torne-se um desenvolvedor web.

R.: Eu faria. É só você se acostumar a trabalhar com tarefas abstratas após a graduação, e o desenvolvimento de sites é um processo muito específico. Mas tentei transformar tudo isso em uma espécie de bela teoria matemática, como as que estudei em magistratura. Acho que gostei muito do Ruby permitir que você expresse seus pensamentos com mais clareza durante o desenvolvimento. Isso me interessou e levou alguns pensamentos. Eu acho que é apenas sobre Rails. O esquema Model-View-Controller não era novo na época, mas parece-me que ele se tornou popular precisamente graças ao Rails. Foi essa combinação que eu gostei.

P: Sim, o desenvolvimento da web é uma atividade interessante e o Ruby é uma ótima ferramenta. Depois disso, você foi um desenvolvedor freelancer na Alemanha. Um de seus projetos foi o Node. Você continuou trabalhando por mais 6-8 meses, certo?

R: É isso. Depois da América do Sul, mudei a garota para a Alemanha - ela é alemã e precisava voltar para a universidade. Comecei a participar de uma conferência sobre Ruby, onde as pessoas discutiam esse novo paradigma de Model-View-Controller. Lá eu conheci um cara chamado Chris Neukirchen. Ele criou o Rack, um projeto que era essencialmente uma abstração simplificada de um servidor da web. O rack transformou o servidor da web em uma interface com uma única função na qual você pode fazer solicitações e receber respostas. Depois trabalhei com o módulo Nginx em um projeto freelancer para o Engineyard. Deixe-me lembrá-lo de que no Nginx tudo funciona de forma assíncrona; portanto, ao criar um módulo para ele, você precisa evitar bloqueios. Conheci o projeto Rack de Chris Neukirchen justamente quando estava trabalhando com E / S sem bloqueio no servidor da web Nginx. Eu acho que foi por isso que tive a ideia de combinar essas duas coisas.

P .: Acontece que, com base no Rack e no Nginx, você teve a idéia de desenvolver uma estrutura que executasse o código Javascript do lado do servidor e aumentasse significativamente o desempenho. Como você decidiu passar os próximos 6 meses fazendo isso?

R: Esses dois elementos - Rack e Nginx com sua assincronia - juntos simplificaram a interface do servidor web. Em dezembro de 2008, o Chrome foi lançado. E com isso, o mecanismo JavaScript V8. Mais precisamente, não o mecanismo em si, mas o tempo de execução em que a compilação JIT ocorre. Em geral, com o lançamento do V8, comecei a entender. O V8 parecia interessante, arrumado e trabalhou rápido. E de repente me ocorreu. O JavaScript é de thread único e todo mundo já está escrevendo algoritmos sem bloqueio. Quero dizer, todo mundo já está fazendo solicitações AJAX no navegador, que são sem bloqueio de qualquer maneira. Eu pensei: ótimo, JavaScript, além de E / S assíncrona e um pouco de funcionalidade para um servidor HTTP é o que eu preciso. E fiquei tão inspirado com a ideia que, sem interrupção, trabalhei nela pelos próximos 4 anos.

P .: Sim, JavaScript e E / S assíncrona funcionaram bem. Eu acho que os desenvolvedores estavam apenas esperando por essa estrutura. E pergunto por curiosidade: quando você desenvolveu o Node, você tinha algum tipo de mentor ou você mesmo o gerenciava?

R: Em geral, eu fiz tudo sozinho. Alguns de meus amigos são programadores e deram alguns conselhos, mas comecei a trabalhar sozinho no meu quarto. Então me mudei para São Francisco e conheci muitos programadores realmente profissionais trabalhando na Joyent. Já lá, muitos deram conselhos e sugestões para o Node.

P .: Claro. Por favor, conte-nos sobre o processo de desenvolvimento do Nó. Claro, muito tempo se passou desde 2009 ...

R: Para mim, os melhores momentos da vida são quando me imergo em algo com a cabeça, quando acredito em alguma idéia. E quando eu tiver tempo para trabalhar diligentemente nisso. O nó era uma ideia que precisava ser implementada e, se não fosse por mim, alguém a teria adotado. Aconteceu que eu tinha pouco trabalho e tempo livre suficiente. Eu poderia dedicar o Node por vários meses - nesse momento, você pode lançar a versão inicial. E foi ótimo e divertido.

P .: Classe, você fez um ótimo trabalho. O nó é baseado no modelo de programação assíncrona pura. Você acha que essa ideia funcionou bem?

R: Uma pergunta interessante. Já se passaram vários anos e eu mesmo não trabalhei no Node em algum lugar entre 2012 e 2013. Obviamente, o Node cresceu tremendamente durante esse período. Quando ele partiu, dei muitas palestras e tentei explicar que talvez estivéssemos fazendo tudo errado, e a E / S sem bloqueio ajudaria a resolver muitos problemas de desenvolvimento. Ou podemos esquecer completamente os threads e conviver com abstrações de processos e serialização. Mas, ao mesmo tempo, na estrutura de um processo, muitas solicitações seriam processadas e, portanto, obteríamos assincronia. Naquela época, eu sinceramente acreditei nessa idéia, mas nos últimos dois anos percebi que isso está longe de ser a única oportunidade. Especialmente após o lançamento do Go. Na minha opinião, o Go apareceu ainda mais cedo, mas eu o ouvi pela primeira vez em 2012. Então ele já tinha um bom tempo de execução e threads verdes de alta qualidade e, com tudo isso, era fácil usar abstrações. Era como bloquear E / S, mas, pelo que entendi, a interface entre o Go e o sistema operacional por meio de threads verdes é realmente sem bloqueio.

No entanto, tudo isso estava disponível para o usuário na forma de uma interface de bloqueio e, na minha opinião, esse modelo tem vantagens. Como regra, é mais fácil entender o que está acontecendo nos algoritmos de bloqueio. Quando há uma sequência de ações, você pode segui-la: execute A, aguarde uma resposta ou talvez pegue um erro. Em seguida, execute B e também obtenha uma resposta ou erro. No Node, tudo é mais complicado porque você precisa pular para outra chamada de função.

P .: Eu também gosto muito do modelo de programação no Go. Usar Goroutines é um prazer. Agora, minha equipe está apenas escrevendo um aplicativo distribuído no Go.

R: Sim, para alguns tipos de aplicativos, o Go é mais adequado - por exemplo, ao criar um servidor. Eu nem consigo imaginar como trabalhar com outra coisa. Embora eu ache que o paradigma não-bloqueador funcionou muito bem para o Javascript, no qual não existem threads. Além disso, o Javascript agora tem a palavra-chave assíncrona e você pode trabalhar com funções assíncronas, para que não precise mais se apressar entre funções anônimas e entender os caracteres de retorno de chamada. Versões mais recentes do Javascript tornaram o trabalho mais fácil. No entanto, acredito que o Node não é a melhor opção para um servidor Web em larga escala. Para isso, eu mesmo escolheria Ir. Honestamente, foi por isso que parei de trabalhar no Node. Acabei de perceber que este não é um sistema ideal para o desenvolvimento de um servidor.

Curiosamente, parece-me que o Node realmente se mostrou brilhantemente apenas no lado do cliente. Ele permite que você use astuciosamente scripts ao criar sites. Por exemplo, o Browserify comporta o Javascript do lado do cliente. Isso permite que o cliente processe o JavaScript no servidor. Outro exemplo são pequenos servidores de desenvolvimento ou mesmo servidores de produção que lidam com tráfego ativo. O nó pode ser muito útil e conveniente para algumas coisas. Mas se você estiver criando um servidor DNS distribuído enorme, eu não recomendaria escolher o Nó.

P: Desenvolvedores de todo o mundo acharão útil pensar sobre isso. Para qualquer empresa, é importante escolher a ferramenta certa, para que você tenha uma atitude bastante objetiva em relação ao Node. Você apresentou o Node.js pela primeira vez na conferência JsConf 2009 Berlin. Talvez você tenha se surpreendido por ele ter alcançado o sucesso tão rapidamente?

R: Claro. Em geral, durante quatro anos inteiros não parei de pensar. O Node se desenvolveu em um ritmo incrível e a comunidade realmente gostou.

P: Depois disso, você se juntou à Joyant em San Francisco e trabalhou no Node continuamente, certo? Conte-nos sobre a sua experiência lá. Os desenvolvedores ficaram muito satisfeitos e você estava no centro dos eventos.

R: Sim, foi um dos destaques da minha vida. Eu realmente estava no centro dos eventos, fui a várias conferências. Uma vez visitei o Japão e as pessoas me pediram para tirar uma foto comigo ... até me senti desconfortável. Quando comentei algo na rede, parecia que cem pessoas me responderam imediatamente. Então percebi que tinha que escolher cuidadosamente minhas palavras e pensar em como elas me percebiam - parece que elas realmente me ouviram, e isso era incomum. Eu não gostei de tudo isso. Afinal, sou um programador e só quero escrever código e, às vezes, expressar minha opinião sem muita cautela. A esse respeito, fiquei um pouco desconfortável.

P: Você tinha 29 ou 30 anos quando criou o Node? E ele já se tornou uma tecnologia tão influente.

R: Sim. Mas então eu ainda era mais provável um desenvolvedor iniciante.

P .: Ryan, naquela época havia muitos projetos diferentes que trabalhavam com JavaScript no lado do servidor. O nó não era a única solução, mas era a mais bem-sucedida - por que você acha?

R: É verdade que várias pessoas tentaram adaptar o JavaScript ao trabalho do servidor. Agora nem me lembro dos nomes deles.

O fato é que em todos esses projetos o bloqueio de entrada / saída foi usado, e isso não foi muito bem com a maneira como o JavaScript foi organizado, porque não funciona com fluxos. E se você usar o bloqueio de E / S, não poderá processar solicitações. Ou seja, você precisa processá-los um por vez, e nada resulta disso. Além disso, adicionei um módulo HTTP de qualidade e mostrei como configurar um servidor HTTP, bem como um servidor TCP simples. Tentei garantir que essas coisas funcionassem corretamente e as pessoas pudessem criar sites sem problemas. Devo admitir que criar um servidor Web não é uma tarefa fácil, e muitos projetos precisavam de funcionalidades que a comunidade precisava concluir sozinha. Mas ninguém construiu nada, porque não havia nada para usar o sistema. Na minha opinião, para qualquer nova estrutura ou o produto como um todo, você precisa de uma amostra básica que possa ser usada imediatamente. Essa era a vantagem do Node - as pessoas podiam simplesmente fazer o download e configurar um servidor da Web imediatamente.

P .: De fato, bons projetos são muito importantes, assim como a facilidade de instalação e uso. Muitos outros já foram capazes de escrever código em JavaScript, para que pudessem começar imediatamente a trabalhar. Quando comecei a trabalhar com o Node, meu conhecimento de JavaScript também ajudou muito.

R: Parece-me que estamos acostumados a pensar que alternar entre idiomas é bastante fácil. Mas mesmo se você já conhece algum idioma, não é tão fácil criar um contexto para um novo idioma. Muitos desenvolvedores já sabem Javascript, portanto, estão interessados ​​em usar uma linguagem familiar em um novo contexto, com novas ferramentas. Acontece que o mesmo idioma abre mais oportunidades.

P .: Com certeza. Em 2012, um grande número de desenvolvedores trabalhou no Node. Por que você decidiu sair e entregar o projeto para Isaac Schluter da Joyent?

R: Eu acho que havia duas razões para isso. Depois trabalhei no Node por 4 anos e, em geral, fiz tudo o que planejei. Eu nunca esperei que o Node se transformasse em uma enorme API. Minha idéia era criar um núcleo pequeno e compacto, no qual as pessoas pudessem construir seus módulos. Eu queria dar suporte a vários recursos principais. Os módulos de extensão foram adicionados desde o início, depois organizamos as bibliotecas da rede, HTTP, UDP, TCP e fornecemos acesso a todos os sistemas de arquivos. Em seguida, uma equipe de cinco pessoas prontas para lidar com a importante tarefa de configurar tudo para o Windows. Queríamos usar abstrações do Windows - portas de conclusão - para E / S assíncrona. Portanto, tivemos que reescrever a biblioteca raiz e, a partir disso, obtivemos a biblioteca libuv. Em um ponto, tudo estava pronto e lançamos o Node para Windows. Então eu pensei: ótimo. Atingi meu objetivo e estou feliz por ter conseguido trazer tudo à mente. Obviamente, ainda existem mil bugs que podem ser corrigidos até o final da vida útil, mas a equipe tem pessoas suficientes que podem cuidar disso. Eu queria fazer outras coisas. Além disso, o Go foi lançado e, para mim, o Node não era mais a única solução para o desenvolvimento de servidores. Bem, eu só não queria ser o centro das atenções toda vez que escrevo algo em um blog.

P .: Claro. Sim, nem todo mundo gosta. Quando você começou a trabalhar no Node, provavelmente tinha alguns planos. Você acha que o Node os concluiu agora?

R: Claro, Node excedeu todas as minhas expectativas. Afinal, agora é usado por centenas de milhares de pessoas.

P .: Diga-me, o que você decidiu fazer quando concluiu esse estágio interessante do desenvolvimento do Node?

R: Depois que saí de Joyent, mudei-me para Nova York e tirei umas férias curtas para trabalhar em meus próprios projetos. Eu tive vários deles. O Instagram saiu naquele momento, então era original e descomplicado. Todos disseram: "Uau, é tão simples que eu mesmo teria construído." E, claro, eu também pensava assim. Eu tinha um projeto de rede social, também construí um sistema de compilação para C ++ e outro para HTML, que era semelhante ao Browserify - compilava Javascript e HTML com inteligência. Em geral, eu tinha muitos projetos, mas, parece-me, nenhum deles foi realmente bem-sucedido. Alguns deles ainda estão em desenvolvimento, por exemplo, minha rede social. Algum dia eu vou levá-lo novamente. Foi o que fiz por um tempo. Então comecei a ler e aprender sobre redes neurais convolucionais e como o problema de classificação de imagens é resolvido, e eu estava muito interessado em aprendizado de máquina.

P: Você também era residente do programa Google Brain. Quais são as suas impressões?

R: Sim, recentemente passei um ano em Mountain View. Volto um pouco: o TensorFlow saiu dois anos atrás.

Ao mesmo tempo, no laboratório de aprendizado de máquina, o Google Brain anunciou um novo programa para residentes, segundo o qual cerca de 20 pessoas são convidadas para lá. Penso que a ideia era convidar pessoas que não estão necessariamente familiarizadas com o aprendizado de máquina, mas que pensam em matemática e programação. Aqueles que estavam interessados ​​em trabalhar com essas novas idéias. O aprendizado de máquina está mudando constantemente e muito trabalho está sendo feito, mas agora a comunidade enfocou finalmente as redes neurais. Acredita-se que este seja o algoritmo mais eficiente para aprendizado de máquina. Portanto, surgiu essa idéia - reunir pessoas interessadas em trabalhar com a nova estrutura do TensorFlow, a fim de chegar a algumas conclusões interessantes. Passei um ano no laboratório. Basicamente, desenvolvi modelos e escrevi artigos científicos sobre eles. Na maior parte, trabalhei com tarefas de transformação de imagens. Ou seja, se houver algum tipo de imagem de origem, é necessário prever qual imagem será impressa. Na minha opinião, esta é uma tarefa muito interessante. Um dos exemplos reais é a colorização. Você pode tirar uma imagem em preto e branco e tentar prever quais cores resultarão. O mais interessante é que, para esta tarefa, há toda uma infinidade de dados para treinamento. Afinal, você pode remover completamente a saturação de qualquer foto colorida e obter a imagem em preto e branco original. Um dos principais problemas no aprendizado de máquina é a necessidade de uma enorme quantidade de dados e há muitos dados para essas tarefas. Mais recentemente, muita pesquisa sobre modelos generativos. Por exemplo, existem redes geradoras-adversárias e redes convolucionais de pixels que aprenderam a perceber imagens reais, ou seja, a distinguir entre imagens reais e cópias artificiais que parecem reais.Eu queria usar os resultados desses estudos de modelos generativos e um banco de dados sem fim para treinamento e aplicar tudo isso às tarefas de transformação de imagens. Eu investiguei a super-resolução - este é um processo que permite aumentar a resolução da imagem original. Também trabalhei na tarefa de transformar imagens e concluí dois projetos de coloração.

P: Obrigado pela ótima explicação, Ryan! Também li que o TensorFlow é uma plataforma poderosa para tarefas de aprendizado de máquina. Classificação, transformação de imagens - é claro, sou especialmente bom com elas, mas tenho certeza de que tudo isso é muito empolgante. Você continua trabalhando no campo de aprendizado de máquina?

R: Sim, ainda trabalho no Google, mas já como engenheiro, e faço tarefas semelhantes. Estudo modelos generativos e ajudo pesquisadores a construir sistemas e modelos de nova geração.

P .: Ótimo! Embora os modelos generativos quase não estejam relacionados às suas atividades passadas - Javascript, Nó e desenvolvimento web ...

R: Isso é certo. Ainda assim, comecei com a matemática e tenho uma boa base matemática. Bem, eu não sou um daqueles que estão fazendo campanha para uma área específica. Não quero me tornar um guru em JavaScript ou em aprendizado de máquina. Eu só gosto de explorar oportunidades interessantes. Acima de tudo, isso me inspira a inventar e construir algo novo que beneficiará a humanidade.

.: . , . Optimistic Nihilism , , . , ?

R: Sim, preciso ter mais cuidado com as previsões ... Então, apenas compartilho minha opinião pessoal: estamos inimaginavelmente longe de modelar a inteligência humana. Os sistemas de aprendizado de máquina com os quais trabalhamos são muito primitivos ou nada funcionais. Acabei de escrever um post sobre minha residência no Google Brain e listei os problemas que surgem ao desenvolver esses modelos. Parece-me que aqueles que estão longe desta esfera geralmente pensam que você pode pegar um modelo, passar dados para ele e tudo vai funcionar por si só. Mas não é tão simples. Existem muitas armadilhas e questões pouco pesquisadas. Para obter os resultados mais modestos, às vezes são necessários muitos meses de experimentação e personalização de filigrana. Então, ainda estamos muito longe de imitar o cérebro humano,mas tecnologias promissoras já estão surgindo - por exemplo, redes neurais convolucionais ou o método de erro de propagação reversa. E, o que é encorajador, essas tecnologias são baseadas em um modelo de redes neurais, que não é muito parecido com o cérebro humano, mas são, em certa medida, inspiradas no conhecimento sobre ele. Também temos GPUs e métodos para treiná-los, e já sabemos como realizar treinamento distribuído com eles, pelo menos em parte. Portanto, na minha opinião, as bases para sistemas maiores e mais inteligentes estão sendo lançadas agora. Pessoalmente, sou ateu e não acredito que meu cérebro seja mais do que substâncias químicas e neurônios. Minha consciência e a consciência de qualquer pessoa estão de alguma forma codificadas nas interações desses neurônios. Portanto, em princípio, não há obstáculos parapara simular esses processos, são necessárias mais pesquisas e desenvolvimentos nessa área. É muito cedo para prever quanto tempo levará.

P .: Entendo. Ryan, você já viu muitas coisas - me diga, como você acha que a tecnologia evoluirá em 20 anos?

R: Eu acompanho com grande interesse o aprendizado de máquina e as oportunidades que ele abre. Mesmo antes de criarmos a verdadeira inteligência artificial, essas tecnologias podem ser encontradas em muitas aplicações diferentes. Em princípio, eles serão muito úteis em qualquer sistema em que você precise fazer suposições razoáveis. Por exemplo, você pode usar a visão computacional para classificar materiais em centros de reciclagem. Existem simplesmente inúmeras áreas em que as tecnologias básicas de aprendizado de máquina seriam úteis. Eu acho que eles serão cada vez mais aplicados em vários processos, e isso terá um enorme impacto no campo da tecnologia e na humanidade como um todo.

P .: Concordo: o aprendizado de máquina é um tópico interessante. É tão interessante ver como carros sem motorista dirigem ao longo de Mountain View. Algum dia no futuro, será ótimo apenas recostar-se em uma cadeira e confiar à máquina controle total. Ryan, obrigado pela excelente estrutura do Node e por nos visitar. E boa sorte em projetos futuros!

R: Obrigado pelo convite, foi interessante conversar!

P .: Obrigado! Isso é tudo. Fiquei feliz em conversar com Ryan, um cara humilde e ótimo. Ele já alcançou muito no início de sua carreira como desenvolvedor e foi uma maneira impressionante. Encontre-me em duas semanas para ver a próxima história!