Cloudflare Workers agora pode ser escrito em Python

• O Cloudflare Workers passa a oferecer suporte à escrita em Python em beta aberto, expandindo o modelo centrado em JavaScript ao integrar diretamente o Pyodide ao workerd, runtime open source do Workers
• Python Workers oferece suporte desde o primeiro dia a bindings já existentes, como Vectorize, Workers AI, R2 e Durable Objects, e pode importar alguns pacotes Python, como FastAPI, Langchain e Numpy
• A base da implementação é o Pyodide, porta do CPython para WebAssembly, e usa FFI entre JavaScript e Python para lidar com Request, Response, Fetch API e bindings de recursos do Cloudflare a partir de código Python
• No momento do deploy, a Cloudflare executa os imports e cria um snapshot da memória linear do WebAssembly para reduzir o custo de inicialização do Pyodide e dos pacotes, baixando o cold start de um Python Worker básico para menos de 1 segundo
• A versão do Python e as atualizações do Pyodide e dos pacotes são gerenciadas com Compatibility Dates e Compatibility Flags, e Workers que permanecerem em uma release do Python cujo período de suporte de 5 anos tenha terminado serão movidos automaticamente para a próxima release de Python mais antiga

---

Python Workers em beta aberto

• Python Workers já pode ser usado em beta aberto no Cloudflare Workers
• Diferentemente do suporte existente a linguagens além de JavaScript, a implementação de Python é integrada diretamente ao runtime workerd
• Os bindings da Cloudflare com suporte desde o primeiro dia incluem:
  • Vectorize
  • Workers AI
  • R2
  • Durable Objects
• Python Workers pode importar alguns pacotes Python populares, como FastAPI, Langchain e Numpy
• Não é necessário build step separado nem toolchain externa

O que não bastava apenas com compilação para WebAssembly

• O Workers oferece suporte a WebAssembly desde 2018, e cada Worker é executado em um isolate do V8, o mesmo motor JavaScript do Chrome
• Em princípio, várias linguagens, incluindo Python, já podiam rodar no Workers se fossem primeiro compiladas para WebAssembly ou JavaScript
• Aplicações reais exigem mais do que executar um “hello world”, e é importante dar suporte ao ecossistema de pacotes que os desenvolvedores usam no dia a dia
• Python Workers é uma forma inicial de dar suporte de primeira classe a linguagens além de JavaScript no Workers

Fluxo de execução de um Python Worker

• Com o Pyodide embutido no workerd, um Python Worker pode processar requisições com o handler on_fetch
• Em wrangler.toml, define-se um arquivo .py como main e configura-se compatibility_flags = ["python_workers"]
• Ao executar npx wrangler@latest dev, o runtime do Workers faz o seguinte:
  • determina a versão necessária do Pyodide com base na compatibility date
  • cria um isolate para o Worker e injeta o Pyodide automaticamente
  • fornece o código Python ao Pyodide
• O ambiente de execução Python é tratado internamente e fornecido pela plataforma, de forma semelhante ao JavaScript Workers

Por que o Pyodide combina com o Workers

• Pyodide é uma implementação que porta o CPython para WebAssembly e interpreta código Python sem pré-compilá-lo para outro formato
• Ele fornece a maior parte da biblioteca padrão do Python e uma interface de função externa (FFI) para chamar APIs JavaScript a partir de Python
• O interpretador principal e cada módulo Python nativo são compilados como módulos WebAssembly separados, projetados para permitir linkagem dinâmica em tempo de execução
• Vários Workers executados na mesma máquina podem compartilhar o code footprint desses módulos, algo importante no ambiente da Cloudflare, que executa milhares de Workers por máquina
• A maioria das linguagens com alvo em WebAssembly ainda não oferece suporte a linkagem dinâmica, então muitas aplicações acabam incluindo sua própria cópia do runtime da linguagem

Pyodide e linkagem dinâmica em WebAssembly

• Como o WebAssembly é um ambiente sandbox isolado do runtime hospedeiro, tarefas além de computação pura, como leitura de arquivos, precisam ser fornecidas pelo ambiente de runtime e importadas pelo módulo
• O alvo WebAssembly do LLVM se divide em três tipos:
  • wasm32-unknown-unknown: não fornece biblioteca padrão de C nem interface de chamadas de sistema
  • wasm32-wasi: usa a interface padrão de sistema implementada por runtimes WASI
  • wasm32-unknown-emscripten: gera junto uma biblioteca JavaScript que define os imports necessários e os implementa
• O Pyodide usa Emscripten para fornecer o interpretador CPython, a FFI entre Python e JavaScript e pacotes Python de terceiros compilados para WebAssembly
• Entre esses alvos, atualmente só o Emscripten oferece suporte a linkagem dinâmica
• O WASI ainda não oferece suporte às abstrações de linkagem dinâmica dlopen/dlsym usadas pelo CPython

FFI conectando Python e JavaScript

• Um exemplo de Python Worker importa o Response do JavaScript com from js import Response
• A FFI do Pyodide permite acessar todos os recursos do JavaScript a partir do Python, reduzindo a desvantagem funcional dos Python Workers em relação aos JavaScript Workers
• Tipos imutáveis como strings e números são convertidos de forma transparente entre as duas linguagens, e objetos mutáveis são encapsulados em proxies apropriados
• Quando um objeto JavaScript é passado para Python, o Pyodide verifica quais protocolos JavaScript esse objeto suporta e compõe dinamicamente uma classe que implementa os protocolos Python correspondentes
  • Se ele suporta o protocolo de iteração do JavaScript, também passa a suportar o protocolo de iteração do Python
  • Se for um Promise ou thenable, em Python ele se torna um objeto awaitable
• No fluxo de tratamento de requisições, o objeto JavaScript Request recebido é encapsulado em um JsProxy acessível pelo código Python, e o valor retornado pelo handler Python é convertido em um objeto JavaScript Response

Linkagem dinâmica e pacotes Python

• Muitos pacotes Python trazem bibliotecas nativas via FFI em C e, para funcionar no runtime do Workers, essas bibliotecas precisam ser compiladas para WebAssembly
• O Pyodide é construído com Emscripten, sobrescreve a FFI em C do Python e, quando um pacote tenta carregar uma biblioteca nativa, carrega um módulo WebAssembly fornecido pelo runtime do Workers
• A linkagem dinâmica permite que o Pyodide ofereça suporte a vários pacotes Python com dependências de bibliotecas nativas
• A linkagem estática precisa carregar todo o código necessário antes da execução do binário, enquanto a linkagem dinâmica paga esse custo apenas quando necessário
• O Workers cria em runtime, para cada Worker, um sistema de arquivos que se parece com uma distribuição Python, mas os arquivos-base são compartilhados entre Workers
• Atualmente, os arquivos são compartilhados entre Workers, mas copiados para cada novo isolate; no futuro, a expectativa é compartilhar ainda mais recursos subjacentes com técnicas de copy-on-write

Suporte a bibliotecas clientes e servidor HTTP

• O Python tem muitas bibliotecas cliente HTTP, como httpx, urllib3 e requests, mas elas não funcionam por padrão no Pyodide
• Essas bibliotecas usam sockets brutos, e como o modelo de segurança do navegador e o CORS não permitem isso, o runtime do Workers precisa de uma abordagem diferente

• Clientes assíncronos

  • Bibliotecas que permitem requisições assíncronas, como aiohttp e httpx, podem usar a Fetch API do Workers
  • A Cloudflare corrige essas bibliotecas com o FFI do Pyodide para que usem a Fetch API do JavaScript
  • O patch do httpx tem menos de 100 linhas de código

• Clientes síncronos e limitações

  • Muitas APIs Python são síncronas e, nesse caso, não dá para usar diretamente a Fetch API assíncrona
  • O urllib3 recebeu contribuições para suporte a navegador no Pyodide usando Atomics.wait() e uma fetch worker thread, ou XMLHttpRequest síncrono
  • O Cloudflare Workers atualmente não oferece suporte a worker threads nem a XMLHttpRequest síncrono, então essas duas abordagens não funcionam em Python Workers
  • No momento, requisições síncronas não são suportadas

• WebAssembly Stack Switching

  • O WebAssembly tem uma proposta stage 3 para adicionar troca de pilha, e o V8 já tem uma implementação
  • Contribuidores do Pyodide vêm adicionando suporte a stack switching desde setembro de 2022, e ele está quase pronto
  • Quando esse suporte chegar, o run_sync do Pyodide poderá bloquear enquanto espera a conclusão de um awaitable, abrindo caminho para suporte a requisições síncronas

FastAPI e ASGI

• O FastAPI é uma biblioteca muito usada para definir servidores em Python e utiliza o protocolo ASGI
• Aplicações FastAPI não leem nem escrevem diretamente em sockets; normalmente um servidor ASGI como o uvicorn cuida do tratamento de sockets brutos
• Graças a essa estrutura, o próprio FastAPI pode rodar no Cloudflare Workers sem precisar de patch ou alteração
• Basta substituir o uvicorn por um servidor ASGI executável dentro do Workers
• A implementação inicial está em asgi.py do workerd e está incluída no fork do Pyodide mantido pela Cloudflare
• A Cloudflare pretende adicionar mais recursos e cobertura de testes antes de enviar isso para o upstream do Pyodide

Importação de pacotes Python

• Python Workers oferece suporte a alguns pacotes Python fornecidos diretamente pelo Pyodide
• Entre os pacotes compatíveis estão numpy, httpx, FastAPI e Langchain
• Para importar pacotes, adicione o nome do pacote sem número de versão ao requirements.txt
• Versões específicas de pacotes são fornecidas diretamente pelo Pyodide
• No momento, os pacotes podem ser usados no desenvolvimento local, e a implantação de Workers com dependências definidas em requirements.txt deve ficar disponível em algumas semanas
• A Cloudflare mantém seu próprio fork do Pyodide para fornecer patches específicos do runtime do Workers e diz que pretende refletir essas mudanças no upstream do Pyodide

Cold start e snapshots de memória

• O próprio Pyodide tem 6,4 MB, e os pacotes Python também podem ser grandes
• Se o Pyodide for colocado diretamente no Worker e enviado para a Cloudflare, o custo de carregar um novo isolate aumenta, deixando o cold start mais lento
• Em um computador rápido e com boa rede, o Pyodide leva cerca de 2 segundos para inicializar no navegador, sendo 1 segundo de rede e 1 segundo de CPU
• Ao executar npx wrangler@latest deploy, o processo de implantação funciona assim
  • O Wrangler envia o código Python e o requirements.txt para a Workers API
  • O runtime do Workers valida o código Python e as dependências
  • Um novo isolate é criado, e o Pyodide e os pacotes especificados são injetados automaticamente
  • As instruções de import do código do Worker são analisadas e executadas, e depois é criado um snapshot da memória linear WebAssembly do Worker
  • Esse snapshot e o código Python são distribuídos pela rede da Cloudflare
  • Assim como em JavaScript Workers, o escopo de nível superior é executado
• Quando chega uma requisição, esse snapshot é carregado para inicializar o Worker no isolate, evitando o custo alto de inicialização
• O cold start de um Python Worker básico cai para menos de 1 segundo

• Reutilização de snapshots

  • Atualmente, o snapshot de memória gerado ao enviar um Python Worker é exclusivo daquele Worker, e não pode ser compartilhado com outros Python Workers, mesmo que grande parte seja igual
  • A Cloudflare avalia que é possível criar previamente um único snapshot compartilhado e carregá-lo antecipadamente em um pool de pre-warmed isolates com o runtime do Pyodide já carregado
  • Com isso, o Python Worker ficaria mais próximo do modelo dos JavaScript Workers, em que o runtime é disponibilizado sob demanda
  • A Cloudflare vê a reutilização de snapshots como a maior forma de reduzir ainda mais o cold start no restante de 2024

Gerenciamento de versões do Python com Compatibility Dates

• O Cloudflare Workers adota um modelo em que se espera que um Worker implantado uma vez continue funcionando mesmo sem atualizações
• Essa estabilidade é fornecida por Compatibility Dates e Compatibility Flags
• No Python, tanto o Pyodide quanto o CPython têm suas próprias versões, e versões novas podem incluir breaking changes
• Novas versões do Python são lançadas todo mês de agosto, e novas versões do Pyodide são lançadas seis meses depois
• Quando uma nova versão do Pyodide é adicionada ao Workers, ela fica atrás de uma Compatibility Flag e só é ativada depois da Compatibility Date especificada
• Uma versão do Python tem 5 anos de suporte, e versões que passam desse período deixam de receber patches de segurança
• Mesmo após 5 anos, Python Workers que permanecerem em uma versão antiga do Python serão movidos automaticamente para a próxima versão mais antiga
• A Cloudflare espera que, na maioria dos casos, os Python Workers continuem funcionando sem problemas, mas recomenda atualizar regularmente a compatibility date para permanecer dentro do período de suporte
• Mesmo entre versões do Python, os pacotes também serão atualizados e adicionados por meio do mesmo modelo opt-in, com um exemplo de flag no formato python_3.17_packages_2025_03_01

Bindings do Python Workers

• Graças ao FFI do Pyodide, é possível acessar diretamente objetos, métodos e funções do JavaScript a partir do Python
• Com essa estrutura, todas as binding APIs dos recursos da Cloudflare são suportadas no Python Workers desde o primeiro dia
• O objeto env do handler em Python é um objeto JavaScript, e o Pyodide fornece uma API de proxy que lida com a conversão de tipos entre as linguagens
• Para um namespace KV, é possível usar await em env.FOO.put() e env.FOO.get() no Python para gravar e ler valores
• As Web APIs também podem ser usadas da mesma forma, e globals do JavaScript como Response podem ser importados do módulo js

Planos para uma API mais idiomática em Python

• A Cloudflare reconhece que um formato como from js import Response não é muito idiomático em Python e planeja oferecer APIs mais naturais para Python no Python Workers
• O workers-rs, lançado em 2021, forneceu bindings no estilo Rust para cada API JavaScript do Workers
• No Python Workers, o plano segue a mesma direção, começando primeiro pelos bindings do Workers AI e do Vectorize
• O workers-rs do Rust usa dependências externas e precisa ser atualizado, mas as APIs do Python Workers deverão ser incorporadas diretamente ao runtime do Workers
• Ao atualizar a compatibility date, será possível usar as APIs mais idiomáticas e recentes de Python
• Também existe a possibilidade de oferecer parte da API de sockets raw da biblioteca padrão do Python com base na API JavaScript connect() do Workers
• A Cloudflare espera dar início ao esforço de criar uma API serverless padronizada que ofereça os mesmos recursos do JavaScript, mas que seja fácil de usar para desenvolvedores Python

Próximos passos

• Para oferecer suporte adequado a uma nova linguagem de programação, é necessário um investimento muito maior do que apenas um “hello world”
• Segundo a pesquisa Stack Overflow 2023, o Python aparece como a linguagem mais usada depois do JavaScript
• A Cloudflare afirma que continuará melhorando o desempenho do Python Workers e ampliando o suporte a pacotes Python
• Os canais de feedback são o canal Python Workers no Discord da Cloudflare Developers e a discussão no GitHub do workerd

[GN⁺]

Comentários no Hacker News

• É bom ver a Cloudflare dando mais atenção a executar Python como WebAssembly na Edge
  Pelo que entendo por ter trabalhado com a execução de Python baseada em WebAssembly na Edge na Wasmer, o Cloudflare Workers habilita Python na Edge usando Pyodide, que é Python compilado para WebAssembly com Emscripten
  A estrutura parece empacotar o Pyodide dentro do Workerd e usar snapshots do V8 para reduzir o tempo de inicialização; no melhor caso, o cold start do Python fica em cerca de 1 segundo
  No entanto, o método atual fica preso à versão de Python/Pyodide embutida no Workerd, e a resolução de pacotes também é fortemente acoplada ao Workerd, então em tempo de execução provavelmente só serão permitidos pacotes nativos pré-compilados. Por exemplo, usar uma versão específica do numpy pode ser complicado
  Como a estrutura está arquitetonicamente presa ao mundo de JS/V8, parece difícil atingir tempo de inicialização abaixo de 100 ms com a arquitetura atual
  Ainda assim, este lançamento é bem-vindo, e espero que as pessoas criem aplicativos incríveis com isso
  https://pyodide.org/
  https://github.com/cloudflare/workerd/blob/main/docs/pyodide...
  https://github.com/cloudflare/workerd/pull/1875
  Edit: refletindo a explicação da equipe da Cloudflare, troquei “prova de conceito” por “lançamento”

  • Parece haver um mal-entendido no resumo sobre como o versionamento funciona. As versões do Pyodide/pacotes são controladas por datas de compatibilidade, e é possível oferecer suporte a várias versões ao mesmo tempo em produção
    Planejamos atualizar com bastante frequência pacotes como langchain e o numpy mencionado
    Seria bom explicar melhor por que o V8 seria o fator limitante. O V8 é um runtime de WebAssembly poderoso, e a maioria das otimizações planejadas não depende muito do motor subjacente
    Além disso, isso não é uma prova de conceito, mas uma beta que seguirá sendo aprimorada até chegar ao GA
  • Só para constar, a Wasmer oferece um produto de Edge com cold starts muito rápidos e sem as desvantagens mencionadas ao executar Python no Cloudflare Workers
    https://wasmer.io/templates?language=python
  • Você disse que “com a arquitetura atual será difícil ter tempo de inicialização abaixo de 100 ms”, mas fico curioso sobre quem estaria executando workloads em Python que exigem latência abaixo de 100 ms
  • Fico curioso se essa arquitetura oferece suporte a uvloop

• A Cloudflare tem muita coisa boa em hospedagem e banco de dados, mas parece não fazer um bom trabalho de marketing como plataforma para desenvolvedores, então Vercel e Netlify acabaram ficando com uma fatia considerável da atenção do mercado
  Separadamente, fico curioso se a Cloudflare oferece um serviço de hospedagem de contêineres agnóstico à linguagem, como o Google Cloud Run

  • Concordo que há algum problema com o marketing. No começo fui atraído por Vercel e Netlify, mas depois de usar os dois por bastante tempo e não ficar satisfeito, resolvi experimentar a Cloudflare e acabei gostando
    O preço e os produtos são excelentes
  • Não é só um problema de marketing. No começo eu estava otimista com o portfólio de produtos da Cloudflare, mas enfrentei grandes problemas de compatibilidade com geradores de sites como Next.js e Astro
    Alguns recursos simplesmente não funcionavam, e outros eram só parcialmente suportados
    Quando você precisa gastar um tempo valioso de desenvolvimento resolvendo esse tipo de problema, plataformas alternativas como Vercel, Netlify e Deno Deploy atenderam melhor às necessidades da equipe e facilitaram focar no desenvolvimento, em vez de em problemas de infraestrutura
  • Vercel e Netlify não parecem ser voltados para desenvolvedores. Se você é desenvolvedor, usar Vercel e Netlify é praticamente aceitar pagar caro à toa
    Os custos de largura de banda na Vercel e na Netlify são 40 a 50 vezes mais altos do que na maioria dos provedores de nuvem, e na Cloudflare largura de banda praticamente não custa nada
    Chamadas de funções de Edge também custam 6 vezes mais na Vercel e na Netlify do que na Cloudflare. Esses números nem incluem o custo de tempo de computação, que é gratuito na Cloudflare
    O quase único motivo de a Vercel ser popular é ser o melhor lugar para hospedar NextJS, e talvez por isso tornem difícil implantar NextJS em outros lugares
  • Pelo que sei, até recentemente o free tier da CloudFlare era bem limitado. O D1, implementação de SQLite, entrou em disponibilidade geral ontem, e réplicas de leitura também foram anunciadas
  • Não existe nada como o Google Cloud Run, mas eu adoraria que existisse
    Uso Workers em produção há uns 4 anos e gosto, mas a maioria dos aplicativos ainda roda em contêineres

• Já usei JS Workers em um site atrás da Cloudflare, e foi fácil de usar e muito rápido. Quero migrar o aplicativo Django inteiro por trás do site, usando até o banco de dados D1

  • O mesmo aqui. Tenho alguns apps móveis usando Cloudflare Workers e KV/D1, e a experiência foi ótima
    O tráfego é baixo e continuo no free tier, mas é tão fácil construir com isso que eu pagaria sem problemas
  • Concordo, parece muito legal. No momento ainda não há suporte para Django/DRF, mas dizem que vão ampliar a quantidade de pacotes no futuro
  • Será mesmo sensato migrar o aplicativo Django inteiro por trás do site para usar D1? Um único ataque DDoS pode estourar o orçamento

• Seria útil ter uma comparação de desempenho com Workers em JS. É interessante, mas, com várias camadas envolvidas, parece que pode ser potencialmente mais lento
  Não espero desempenho equivalente, mas seria bom entender mais ou menos os trade-offs

  • Há três aspectos de desempenho: desempenho de cold start, desempenho após o cold start, custo da ponte entre JS e WebAssembly, e a velocidade do interpretador Python executando em WebAssembly
    Atualmente, o cold start de Python é mais lento que o de um JavaScript Worker do mesmo tamanho. Um Worker básico “Hello World” escrito em JavaScript tem tempo de cold start quase zero, enquanto um Worker em Python fica abaixo de 1 segundo
    Isso acontece porque é preciso carregar o Pyodide sob demanda no Worker quando chega uma requisição, e o post do blog explica o trabalho para reduzir isso deixando o Pyodide previamente disponível
    Ainda assim, depois que o Python Worker termina o cold start, a diferença passa a ser quase marginal e, dependendo do que acontece durante a requisição, pode ficar na casa de alguns milissegundos
    Ao atravessar a “ponte” entre JavaScript e WebAssembly, por exemplo ao fazer entrada/saída ou trabalho assíncrono, há um pequeno custo. Mas estamos falando de microssegundos, não milissegundos, e no geral é muito pequeno
    Quem usa Workers sensíveis a desempenho já chega a escrever em Rust: https://github.com/cloudflare/workers-rs e isso também depende da ponte entre JavaScript e WebAssembly
    O interpretador Python baseado em WebAssembly fornecido pelo Pyodide não é tão rápido quanto os muitos anos de otimizações acumuladas para tornar o JavaScript rápido no V8. Mesmo assim, o Pyodide ainda está no começo em comparação com a engine de JS do V8, e parece haver áreas com potencial para grandes melhorias de desempenho. Eles querem levar essas melhorias de performance para upstream, e também existem propostas de WebAssembly que podem ajudar
  • Pela sensação de uso, parece bem rápido

• Fico curioso se escolheram lzma para demonstrar isolamento de propósito, ou se foi coincidência por causa das notícias técnicas da semana passada
  https://news.ycombinator.com/item?id=39865810

  • Só incluímos porque está na biblioteca padrão. O timing foi coincidência total, mas é bom que usar Wasm traga uma garantia de isolamento :-)

• Isso parece que pode mudar bastante o jogo para rodar cargas de trabalho de IA na Cloudflare. Já faz tempo que eu esperava por isso

  • Com certeza parece que essa era a intenção
    Se ainda não viu, vale a pena conferir também os outros dois anúncios de hoje
    “Leveling up Workers AI: General Availability and more new capabilities”
    https://blog.cloudflare.com/workers-ai-ga-huggingface-loras-...
    “Running fine-tuned models on Workers AI with LoRAs”
    https://blog.cloudflare.com/fine-tuned-inference-with-loras
  • Fico curioso qual é o tempo máximo que um Worker pode executar. Queria saber como isso se compara ao AWS Lambda, ou se é algo totalmente diferente

• Testei hoje e gostei, e consegui colocar para rodar muito rápido
  Só queria saber como fazer o ambiente de desenvolvimento local entender as bibliotecas embutidas na implementação de Python da CFW
  Por exemplo, existe a biblioteca asgi, e eu queria que o linter não a marcasse como desconhecida. Mas ela só existe no runtime do handler on_fetch e não está de fato presente na máquina local de desenvolvimento, então não consegui achar uma solução

• Tive bons resultados usando CF Pages para sites estáticos, e os produtos da Cloudflare para servir LLMs open source como serviço também são interessantes
  O principal motivo que me impedia de criar mais coisas na Cloudflare era a falta de suporte a Python, e estou animado para testar esse recurso

  • Eu também uso CF Pages e algumas funções de Worker, e o ecossistema da Cloudflare é realmente muito bom
    É fácil colocar algo no ar rapidamente, sem precisar se preocupar tanto com infraestrutura
    A adição de Python é muito bem-vinda, e seria ótimo se Go também ganhasse suporte de primeira classe

• Fico curioso como a limitação de usar apenas pacotes do Pyodide vai funcionar em builds que não sejam triviais
  Há muito código que não é Python puro, então parece que para dar suporte a apps de produção de verdade seria preciso reconstruir manualmente muita coisa
  A adoção pela Cloudflare talvez ajude a atrair mais pacotes, e, se a regra 80/20 se aplicar aqui, talvez isso já seja bom o suficiente

  • Com certeza existe uma regra 80/20 aqui. A maioria dos pacotes não é tão difícil de portar, e os que são difíceis de compilar em geral usam recursos sem equivalente claro no runtime WebAssembly, como threads e multiprocessamento, placas gráficas, sockets brutos e green threads
    Como o post do blog também menciona, o maior problema é o suporte a pacotes ligados a servidor e requisições. Eles são claramente úteis no Cloudflare Workers, mas são difíceis de portar porque costumam usar sockets brutos e alguma forma de concorrência

• Seria bom se a CloudFlare implementasse Workers com WASM como alvo de primeira classe, junto com APIs genéricas não presas aos JS Workers
  Hoje já dá para implantar código WASM e, na prática, usar qualquer linguagem, mas ele não roda de forma nativa: roda dentro de um contexto JS
  Há um pouco de overhead e estranheza no deployment
  No fim, acho que todos os serviços vão ser implantados diretamente em runtimes WASM seguros, e não em contêineres. Algo parecido com a transição que houve de imagens para contêineres
  No momento, a vantagem de tentar usar Rust ou algo semelhante no Edge da Cloudflare não é tão grande. Boa parte do ganho de desempenho é compensada pelo overhead e pelo tempo de inicialização
  Ex.: https://github.com/WasmEdge/WasmEdge