TypeScript 7 Lançado Oficialmente e Nossa, Como É Rápido

Portuguêsالعربية Deutsch English Español Français हिन्दी Bahasa Indonesia 日本語 한국어 Русский 中文

컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00O TypeScript 7 foi lançado oficialmente e, após mais de um ano de desenvolvimento árduo,

00:00:05portar o compilador para Go provou que você pode simplesmente fazer tudo com IA, então tenho

00:00:10certeza de que os desenvolvedores estão felizes com isso. Se rodar npm install typescript agora, receberá a versão

00:00:167, que é a versão com o compilador em Go. Seguindo o vídeo de anúncio da Microsoft

00:00:20de alguns dias atrás, eu queria explorar exatamente como alcançaram esses ganhos massivos

00:00:25de desempenho. Os resultados foram realmente impressionantes. O novo compilador constrói a base de código do VS Code,

00:00:31que tem 1,3 milhão de linhas de código em quase 8.000 arquivos, em apenas 10 segundos, comparado aos 125

00:00:39segundos do compilador antigo. E com o TypeScript agora ocupando orgulhosamente o posto de linguagem número um no

00:00:44GitHub, acredite ou não, o novo compilador vai mudar muitas vidas. Fico até emocionado

00:00:49só de pensar nisso. Mas em vez de olhar para os recursos quase idênticos entre as versões 6 e 7, eu queria focar

00:00:54em como exatamente esse desempenho é alcançado. Então vamos dar uma olhada no novo compilador e ver o que

00:00:59o torna tão rápido. Mas por que reescrever? Bom, o criador do C# e Technical Fellow na Microsoft,

00:01:09Anders Hejlsberg, disse de forma bem clara: o JavaScript é otimizado para UI e navegadores, não é realmente

00:01:16otimizado para fluxos de trabalho de computação intensiva e compiladores. O motivo é bem óbvio: ele roda em thread

00:01:22única, e processar algo como uma árvore de sintaxe abstrata ou verificação de tipos só consegue escalar

00:01:27até certo ponto acessando um único núcleo. Você poderia, tecnicamente, distribuir o trabalho entre workers, mas aí

00:01:32precisaria serializar e deserializar os dados, o que é lento e exige muita memória. E depois teria que

00:01:38lidar com a complexidade de gerenciar tudo isso. Então eles optaram pelo Go, que oferece melhorias dramáticas

00:01:43de desempenho usando uma linguagem ideal para esse propósito. Go é uma linguagem compilada,

00:01:48o que significa que podemos rodar código compilado diretamente na CPU em vez de ter que interpretá-lo. E o Go tem um

00:01:54modelo de concorrência excelente, permitindo rodar facilmente múltiplas threads de execução ao mesmo tempo,

00:02:00todas com memória compartilhada. Isso significa que podemos aproveitar todos os núcleos da sua máquina, em vez de apenas

00:02:06um. Há uma divisão quase igual: até metade do ganho de velocidade vem de estar em código nativo,

00:02:12e o restante de ter concorrência com memória compartilhada. O Go é basicamente a linguagem perfeita para isso.

00:02:17Não é só que o Go é mais rápido, ele literalmente tem mais recursos para dedicar ao problema, e os resultados

00:02:23falam por si sós. Se olharmos para os números, o VS Code com 1,3 milhão de linhas de código levava 125,7 segundos no antigo

00:02:32compilador e foi para 10,6 segundos, uma melhoria de 11,9x. No Bluesky, fomos de 24,3 para 2,8, uma melhoria de 8,7x.

00:02:42E para o Playwright, reduzimos de 12,8 segundos para 1,5, outra melhoria de 8,7x. E, por incrível que pareça, leva

00:02:49apenas um segundo para se inscrever no Better Stack. Essa diferença só tende a aumentar, porque os núcleos não

00:02:54estão ficando mais rápidos no mesmo ritmo de antes, mas o que temos agora são mais núcleos. Estou em um M3 Max, por

00:03:00exemplo, que tem 14 núcleos, o que é insano. Lembro de montar um PC gamer na faculdade que tinha um

00:03:06Intel i7 de quatro núcleos, e eu achava aquilo uma fera absoluta. O compilador JavaScript usava apenas

00:03:11um desses núcleos, mas com o Go eu desbloqueio todos eles. E claro, quanto mais núcleos você tem, mais

00:03:17desempenho você obtém. Se eu compilar um projeto grande nesta máquina na versão 6, você verá que leva 45

00:03:24segundos, e com a versão 7 conseguimos reduzir isso para apenas três segundos. Existem múltiplas

00:03:29fases no processo de compilação, e a fase de checagem de tipos é apenas uma delas. Para isso, o Go

00:03:34inicializa quatro verificadores de tipo e faz cada um checar um quarto do código-fonte. Mas você pode

00:03:39melhorar isso ainda mais. Durante a compilação, você pode definir os checkers para 12 e ter um desempenho ainda mais rápido.

00:03:45Baixei o repositório do VS Code na minha máquina para vermos a diferença entre o TypeScript 7 e o 6.

00:03:51Por padrão, o tsc na minha máquina agora aponta para o TypeScript 7, então vamos rodar o diagnóstico

00:03:57nisso, e você pode ver que levou 5,4 segundos. A maior parte do tempo foi gasta no tempo de

00:04:02checagem: 4,7 desses segundos. Nós podemos acelerar isso também. Se adicionarmos outra flag,

00:04:08checkers 12, você verá que o tempo total caiu de 5,4 para 3,5 segundos, e tudo isso reduz

00:04:15o tempo de checagem. Tínhamos 4,7 aqui e agora caiu para 2,9. Agora vamos rodar o mesmo

00:04:20comando de novo, mas dessa vez usando o TypeScript 6. Isso vai levar um pouco

00:04:23mais de tempo, então vamos acelerar. Depois de esperar por isso, você pode ver que o TypeScript 6 terminou em

00:04:2845,3 segundos, comparado aos 3,5 que temos ao rodar em todos os núcleos. Isso é, na prática,

00:04:36uma melhoria de 15x no meu chip M3 Max. Para mim, é daí que vêm os 3,5 segundos. Fazer

00:04:43isso, claro, vai roubar desempenho de outros processos, mas se você não estiver fazendo nada,

00:04:47pode muito bem usar todos os recursos da sua máquina. Vamos dar uma olhada no código real

00:04:52do novo compilador para entender como o Go alcança esse desempenho. Aqui temos a função bind source

00:04:57files, cujo trabalho é mapear cada declaração em um arquivo e descobrir a qual escopo ela pertence.

00:05:03Estamos processando possivelmente milhares de arquivos. Iteramos por cada arquivo, enfileiramos uma função para vinculá-lo

00:05:09e esperamos que todas terminem. A parte incrível é que não precisamos pensar em como esse

00:05:14trabalho é distribuído entre os núcleos. O runtime do Go cuida de tudo isso sozinho. Não criamos threads nem

00:05:20gerenciamos comunicação complexa entre núcleos, apenas dizemos “aqui está o trabalho” e ele descobre como fazer o

00:05:26resto. Em JavaScript poderíamos escrever um código quase idêntico, mas é inútil para tarefas focadas em CPU. Tudo

00:05:32ainda rodaria em uma única thread sequencialmente, mesmo que Promise.all dê a ilusão de paralelismo.

00:05:38Workers são tecnicamente uma alternativa, mas você não pode compartilhar objetos entre eles, apenas bytes puros com

00:05:43SharedArrayBuffer. Passar uma árvore sintática processada para um worker exige serializar tudo,

00:05:48copiar e reconstruir do outro lado. Para um arquivo grande, isso custa mais do que o próprio trabalho.

00:05:53Basicamente, coisas como essa tornam o Go inerentemente melhor para tarefas intensivas em CPU. Ele tem um

00:05:58runtime capaz de gerenciar toda essa concorrência por você e tem memória compartilhada, permitindo passar objetos

00:06:03sem precisar copiá-los. Além do tempo de compilação, o que você mais vai notar

00:06:07é a velocidade do seu servidor de linguagem. Qualquer um que já trabalhou em uma base de código grande em TypeScript conhece

00:06:13a dor de esperar pela checagem de tipos. E meu Deus, esses Macs com Intel sofreram com isso. Lembro de trabalhar em

00:06:20projetos há alguns anos e você abria o repositório e tinha que esperar literalmente

00:06:24até dois minutos só para ver os sublinhados vermelhos aparecerem. E toda vez que fazia uma alteração,

00:06:29era incrivelmente doloroso. A experiência de desenvolvimento fica péssima e ninguém quer

00:06:34trabalhar na base de código. O novo servidor de linguagem, no entanto, significa feedback instantâneo na sua IDE, para que possa

00:06:40abrir um arquivo, fazer uma alteração e ver os erros em milissegundos, mesmo que esteja trabalhando em

00:06:46bases de código potencialmente gigantescas. Além do desempenho, o novo servidor de linguagem está mais estável, então a

00:06:51necessidade de reiniciar sua IDE quando a verificação de tipos trava diminuiu drasticamente. O TypeScript 7

00:06:57reduziu as falhas em comandos do servidor em mais de 80% e reduziu os travamentos do servidor em mais de 60%,

00:07:04o que significa menos notebooks arremessados na parede — algo ótimo para o meio ambiente. Quem

00:07:08diria que a Microsoft realmente se importa com o planeta? Vale mencionar também que isso é um port,

00:07:13não uma reescrita. A equipe do TypeScript tomou muito cuidado para garantir que o novo compilador seja basicamente

00:07:19totalmente compatível com o antigo. Você provavelmente nem notará diferença, exceto pela velocidade. Mas

00:07:24embora já possa rodar o TypeScript 7 nos seus próprios projetos, ainda precisará esperar que seus pacotes

00:07:29favoritos se atualizem. A API programática ainda não está disponível, o que significa que qualquer pacote dependente

00:07:35dela terá que esperar pela versão 7.1. Pacotes como typescript-eslint, ts-jest ou ts-node vão

00:07:42ficar para trás por enquanto. O lançamento completo do TypeScript 7 já está disponível para download, mas você

00:07:47precisa instalar explicitamente a extensão do TypeScript 7 para o VS Code. O pacote padrão eventualmente será

00:07:53atualizado, mas por enquanto basta instalar a extensão. Ela se chama TypeScript 7 na loja de extensões e

00:07:58tudo funcionará como esperado. Se quiser ver mais sobre o conjunto de recursos do TypeScript 7, gravamos

00:08:03um vídeo focado exatamente nisso, que você pode ver aqui. E se gosta de análises como esta, inscreva-se

00:08:08no Better Stack para mais conteúdo. Espero que tenha aprendido algo aqui e que agora possa aproveitar

00:08:12o desenvolvimento ultra-rápido que terá com o TypeScript 7. Eu com certeza sei que vou adorar

00:08:16usar esta versão. Obrigado por assistir e, claro, vejo você no próximo vídeo!

Key Takeaway

A reescrita do compilador do TypeScript 7 em Go utiliza todos os núcleos da CPU e memória compartilhada para acelerar a compilação de projetos em até 15 vezes e fornecer diagnóstico de erros em milissegundos na IDE.

Highlights

O TypeScript 7 foi reescrito em Go, reduzindo o tempo de compilação do VS Code (1,3 milhão de linhas de código) de 125,7 para 10,6 segundos.
A mudança para Go permite executar código compilado diretamente na CPU e utilizar concorrência com memória compartilhada entre todos os núcleos do processador.
O tempo de checagem de tipos no repositório do VS Code cai de 4,7 segundos para 2,9 segundos ao ajustar a flag de verificadores paralelos para 12 no chip M3 Max.
O novo servidor de linguagem reduz as falhas em comandos em mais de 80% e diminui os travamentos do servidor em mais de 60%.
A API programática estará disponível apenas na versão 7.1, mantendo pacotes como typescript-eslint, ts-jest e ts-node temporariamente incompatíveis.

Timeline

Migração para Go e ganhos de velocidade

A instalação do TypeScript via npm já fornece a versão 7 compilada em Go.
O tempo de compilação do VS Code diminuiu de 125 para 10 segundos na nova versão.

A versão 7 do TypeScript traz uma reescrita interna focada em desempenho extremo. O projeto do VS Code possui 1,3 milhão de linhas de código espalhadas por quase 8.000 arquivos e serve de referência para a medição do ganho de velocidade. O novo compilador mantém paridade quase idêntica de recursos em relação à versão 6, focando seus ganhos na eficiência de execução.

Limitações do JavaScript e vantagens do Go

O JavaScript executa em thread única e não atende eficientemente a fluxos de computação intensiva.
O Go compila para código nativo e suporta múltiplas threads com memória compartilhada.
Metade do ganho de desempenho vem do código nativo e a outra metade da concorrência.

O processamento de árvores de sintaxe abstrata e a verificação de tipos exigem alta capacidade de processamento. A execução do JavaScript em thread única impede o uso contínuo de múltiplos núcleos da CPU. O uso de worker threads no ambiente antigo exige a serialização e deserialização contínua de dados, gerando consumo excessivo de memória e lentidão no processo.

Métricas de desempenho e paralelização no chip M3 Max

A compilação do Bluesky caiu de 24,3 para 2,8 segundos e a do Playwright de 12,8 para 1,5 segundo.
A flag checkers 12 divide o trabalho de checagem de tipos entre 12 verificadores simultâneos.
A execução no processador M3 Max registrou uma aceleração total de 15 vezes em comparação ao TypeScript 6.

O aumento no número de núcleos nos processadores modernos beneficia diretamente o compilador em Go. Durante a checagem do código do VS Code em um chip M3 Max de 14 núcleos, o tempo total cai de 5,4 para 3,5 segundos ao elevar o número de checkers para 12. O mesmo diagnóstico rodando no TypeScript 6 exigia 45,3 segundos na mesma máquina.

Gerenciamento de concorrência e limitações técnica de threads

O runtime do Go distribui as funções entre os núcleos automaticamente sem gerenciamento manual de threads.
Instruções paralela em JavaScript com Promise.all mantêm a execução sequencial em tarefas de CPU.
A memória compartilhada do Go evita a cópia e reconstrução da árvore sintática.

A função bind source files faz o mapeamento de declarações para escopos processando milhares de arquivos em fila. No Go, os objetos são acessados de forma concorrente diretamente na memória comum. Em contrapartida, estruturas como SharedArrayBuffer no JavaScript só permitem transferir bytes puros, o que torna a transferência de objetos complexos mais custosa do que a própria análise sintática.

Estabilidade da IDE e compatibilidade de pacotes

O novo servidor de linguagem fornece feedback de erros em milissegundos dentro do editor.
As falhas e travamentos no servidor da IDE caíram 80% e 60%, respectivamente.
Ferramentas como typescript-eslint e ts-jest dependem da API programática que chegará na versão 7.1.

A resposta do Language Server Protocol torna-se instantânea mesmo em bases de código de grande porte, eliminando esperas prolongadas por diagnósticos visuais. Por se tratar de um port direto e não de uma reescrita do zero, a compatibilidade de código com a versão 6 foi mantida. A integração completa com o ecossistema de ferramentas externas aguarda a liberação das APIs programáticas na versão 7.1, exigindo por enquanto a instalação manual da extensão do TypeScript 7 no VS Code.

Community Posts

Write about this video