A melhor runtime WebAssembly talvez seja nenhuma runtime

Artigo original ↗ Discussão no Hacker News ↗

Compilar módulos WebAssembly de volta para C é apresentado como uma forma de executar código nativo portátil e isolado sem uma runtime pesada, habilitando coisas como sistemas de plugins mais seguros e binários multiplataforma. Comentadores comparam essa abordagem a tecnologias anteriores como o Google Native Client, discutem como o modelo restrito e bem especificado do WASM e seu ecossistema de ferramentas o tornam atraente como uma camada intermediária universal, e observam o uso já existente dessa técnica no Firefox. Eles também destacam limitações e trade-offs: bugs de memória internos em C continuam existindo, verificações de limites e determinismo podem adicionar overhead, a integração com linguagens de mais alto nível e com o DOM ainda é complicada, e alguns veem o hype mais amplo em torno do WASM como superando seu suporte real a linguagens e plataformas.

Wasm→C como sandboxing “sem VM”

  • Ideia: compilar C (ou outras linguagens) para WebAssembly, depois transpilá-lo para C e compilar nativamente, herdando as garantias de segurança do wasm sem uma runtime pesada.
  • O Firefox já faz uma variante disso (RLBox): wasm como fronteira de isolamento e, depois, recompilado para obter desempenho.
  • O w2c2 hoje foca em portabilidade, não em sandboxing; o wasm2c busca segurança conforme a especificação (verificações de limites, chamadas indiretas tipadas com segurança).

Segurança, verificação de limites e isolamento do SO

  • Alguns argumentam que isso é redundante: processos já recebem isolamento baseado em MMU; sandboxes clássicas no estilo seccomp e containers podem ser tão seguros ou mais, com superfícies de syscall mais restritas.
  • Outros dizem que o wasm embutido é atraente onde não dá para criar processos/containers, e para casos de uso como plugins.
  • O wasm depende de memória linear com limites impostos; motores de produção usam páginas de guarda + mprotect/tratadores de falha para verificações de custo quase zero.
  • Limitação importante: o wasm não corrige bugs de lógica nem corrupção de memória dentro do módulo; módulos não confiáveis ficam isolados do host, mas C inseguro interno continua inseguro.

NaCl, PNaCl e como chegamos ao wasm

  • O Native Client resolveu problemas semelhantes, mas era específico de CPU; o formato de bits de LLVM do PNaCl e o entrelaçamento com glibc eram complicados.
  • O asm.js surgiu como uma alternativa mais simples; o wasm foi uma padronização multi-fornecedor dessas lições.
  • Alguns veem o fracasso do NaCl principalmente como técnico; outros enfatizam razões políticas / de ecossistema.

C vs LLVM IR vs outros IRs

  • Pró-C: C é estável, amplamente suportado e funciona como uma IR portátil, inclusive em sistemas operacionais obscuros (por exemplo, Mac OS 9, CPUs estranhas).
  • Anti-C: C não consegue expressar aliasing mais rico, tipos soma ou um tratamento detalhado de UB; LLVM IR seria mais expressivo, mas é um alvo em movimento e preso a versões.
  • Visão: wasm como uma camada intermediária universal (<any language>→wasm→C/anything) em vez de acoplar verificações de limites em cada compilador C.

Debates sobre design de bytecode e desempenho

  • Alguns criticam o design baseado em pilha do wasm por adicionar complexidade em relação a IRs baseados em registradores; outros o defendem como suficiente e testado em batalha.
  • Há discordância sobre quão “universal” o wasm continuará sendo à medida que cresce (GC, threads, recursos mais ricos) versus tornar-se opinativo como JVM/CLR.

Casos de uso, hype e ceticismo

  • Entusiastas: wasm é uma ISA portátil para plugins isolados, serverless, embarcados, bibliotecas multi-linguagem e preservação de software; efeitos de rede superam falhas técnicas.
  • Céticos: o hype exagera novidade e segurança; bytecodes e VMs existentes já atendiam a objetivos semelhantes há décadas; o wasm não resolve inerentemente as dores da UI web (complexidade de HTML/CSS/JS).
  • Alguns veem o wasm fora do navegador (WASI, sistemas de plugins, empacotamento estilo Cosmopolitan) como mais impactante do que apps no navegador.

GC, linguagens de alto nível e DOM

  • Espera-se que o GC do wasm ajude linguagens gerenciadas, mas há preocupações sobre incompatibilidade com runtimes como Go/Java e a falta de coisas como troca eficiente de stack.
  • O wasm não consegue tocar diretamente no DOM/WebGPU; shims em JS são necessários. Alguns querem apps web totalmente sem JS; outros argumentam que DOM/Web APIs são inerentemente moldadas por JS e que a sobrecarga é negligenciável em relação aos custos do DOM.