Por anos, continuei construindo sistemas distribuídos cada vez mais paranoicos.
mTLS em todo lugar.
Autenticação sem senha (passwordless).
DPoP.
Chaves efêmeras.
Criptografia pós-quântica.
Arquiteturas orientadas a eventos.
Isolamento de sessão.
Zero Trust.
Sistemas baseados em capacidades (capabilities).
E, no entanto, algo sempre parecia fundamentalmente errado.
Não importava o quão segura a arquitetura se tornasse, o próprio modelo de programação ainda permitia a existência de estados impossíveis.
Tokens podiam ser duplicados.
Sessões podiam acidentalmente sobreviver mais tempo do que o pretendido.
Segredos efêmeros ainda podiam ser reutilizados.
Eventos podiam, teoricamente, ser consumidos duas vezes.
Recursos que deveriam ser de uso único eram tratados como valores comuns.
Então o VibeCoding aconteceu.
E enquanto explorava linguagens de programação obscuras por pura curiosidade, descobri a Austral.
Não é o ownership do Rust.
Não é borrow checking.
Não é validação em tempo de execução.
Tipos lineares de verdade.
No momento em que entendi o conceito, meu cérebro explodiu imediatamente com uma pergunta:
Por que isso já não está em todo lugar?
Porque as implicações são absurdas.
Algumas coisas simplesmente não deveriam ser copiáveis.
Nunca.
Um token DPoP não deveria ser clonável.
Uma chave de sessão efêmera pós-quântica não deveria ser reutilizável.
Uma prova de autorização de pagamento não deveria sobreviver após o consumo.
Uma capability de uso único não deveria permanecer viva na memória por acidente.
Uma sessão não deveria se duplicar silenciosamente através de referências.
E, ainda assim, a maioria das linguagens convencionais trata esses valores como estruturas de dados normais.
Tipos lineares mudaram completamente a maneira como penso sobre sistemas.
Não de forma incremental.
Exponencialmente.
A Percepção
O insight mais importante foi este:
Alguns recursos não são dados.
Eles são obrigações semânticas.
Um token de sessão não é "informação".
É uma capacidade consumível.
Uma chave efêmera não é "estado".
É um recurso criptográfico de uso único.
Um evento não é "apenas uma mensagem".
É uma transição em um ciclo de vida semântico.
E essas coisas deveriam ser representadas pelo próprio sistema de tipos.
Uma vez que percebi isso, comecei a enxergar categorias inteiras de vulnerabilidades como falhas de modelagem de tipos.
Ataques de replay?
Problemas de duplicação de recursos.
Vazamento de sessão?
Violação de propriedade (ownership).
Consumo duplo de eventos?
Semântica não linear.
Mau uso de DPoP?
Artefatos de prova copiáveis.
A partir desse ponto, não dava mais para voltar atrás.
Austral parece um olhar para o futuro
O que me impressionou ainda mais foi que a Austral ainda é relativamente pequena e obscura.
Escrita em OCaml.
Compilando para WASM.
Extremamente focada.
Extremamente baseada em princípios.
E, de alguma forma, carregando ideias que já deveriam existir em todas as linguagens de sistemas sérias.
A parte mais engraçada é que descobrir a linguagem me deixou feliz justamente porque ela ainda carece de muitas coisas.
Isso significava que havia espaço para construir.
E eu entrei imediatamente em um estado de obsessão técnica completa.
O que aconteceu a seguir
Em questão de dias, comecei a construir em torno do próprio ecossistema.
Eu criei:
- Uma versão de fã do site oficial;
- Um gerenciador de pacotes;
- Múltiplos pacotes;
- Utilitários de teste;
- Tipos semânticos adicionais;
- Validações de tipo mais fortes;
- APIs ergonômicas no estilo JavaScript;
- Ferramentas para desenvolvedores.
E então as coisas escalaram.
Comecei a construir um framework de API completo em torno dos princípios que venho desenhando mentalmente há anos:
- Autenticação passwordless;
- mTLS;
- Criptografia pós-quântica;
- Chaves efêmeras lineares;
- Tokens DPoP lineares;
- Segurança orientada a capacidades;
- Execução WASM;
- Semântica orientada a eventos.
O curioso é:
Os tipos lineares de repente fizeram todas essas ideias parecerem estruturalmente corretas.
Não "seguras por convenção".
Não "validadas por disciplina".
Realmente forçadas pelo sistema.
O problema da Experiência do Desenvolvedor (DX)
A maior tragédia das linguagens avançadas raramente é o seu sistema de tipos.
É a sua experiência de desenvolvedor.
A maioria dos desenvolvedores nunca descobrirá ideias como:
- Capabilities lineares;
- Propriedade afim (affine ownership);
- Consumo de recursos semânticos;
- Execução orientada a provas;
- Arquiteturas seguras por capacidade;
...porque o ferramental em torno dessas ideias costuma ser doloroso.
Então, acabei encontrando um novo hobby:
Melhorar a Experiência do Desenvolvedor para linguagens obscuras, porém revolucionárias.
Quero que os tipos lineares pareçam acessíveis.
Naturais.
Úteis.
Práticos.
Quero que as pessoas descubram acidentalmente um modelo computacional mais seguro enquanto constroem sistemas normais.
É por isso que comecei a implementar APIs intencionalmente inspiradas na ergonomia do JavaScript.
Porque se os desenvolvedores puderem usar recursos semânticos lineares com APIs que pareçam familiares, a barreira desaparece.
E uma vez que você entende as implicações, torna-se impossível ignorar.
Não acho que Tipos Lineares sejam "avançados"
Eu acho que eles são inevitáveis.
Especialmente para:
- Tokens;
- Sessões;
- Material criptográfico;
- Streams de eventos;
- Provas efêmeras;
- Capacidades de autorização;
- Recursos comportamentais distribuídos.
A ideia de que esses recursos são livremente copiáveis agora me parece fundamentalmente incorreta.
E quanto mais os sistemas distribuídos se tornam:
- Orientados a eventos;
- Baseados em provas;
- Baseados em capacidades;
- Pós-quânticos;
- Zero-trust...
...mais absurda começa a parecer a semântica de recursos não lineares.
VibeCoding mudou mais do que a produtividade
As pessoas falam de VibeCoding como:
"IA escrevendo código para você."
Essa não é a parte interessante.
A parte interessante é que a curiosidade foi subitamente amplificada de forma massiva.
Agora você pode explorar:
- Teoria de linguagens de programação obscuras;
- Métodos formais;
- Semântica distribuída;
- Sistemas de reescrita;
- Sistemas de tipos;
- Cálculos de capacidade.
...sem passar meses lutando contra boilerplate antes de chegar à experimentação.
E isso muda tudo.
Porque agora, uma curiosidade aleatória tarde da noite sobre uma linguagem obscura pode alterar completamente a arquitetura dos seus sistemas.
Foi exatamente o que aconteceu comigo e a Austral.
E, honestamente?
Acho que só vi o começo do que os sistemas semânticos lineares se tornarão.
Top comments (0)