Por que eu criei a Ori — e como estou criando

Capítulos

De onde eu vim

Minha formação é em Marketing e Design. Passei por pré-impressão, endomarketing e suporte em TI, e o código que eu escrevia se resumia a CRUDs em PHP e Ruby. Nada que sugerisse “um dia esse cara vai desenhar uma linguagem de programação”.

O que eu tinha — e continuo tendo — é uma curiosidade que não desliga. Eu gosto de entender como as coisas funcionam por baixo, e tenho aquele hiperfoco clássico de quem aprende coisas completamente fora da própria área só porque ficou intrigado. Quando comecei a construir software junto com IA, o teto do “só sei o básico” rachou: de repente eu conseguia levar ideias muito maiores até o fim, desde que eu soubesse fazer as perguntas certas e julgar as respostas.

A Ori nasceu desse lugar. Não de um laboratório de linguagens, mas de alguém que lia muito mais código do que escrevia — e se incomodava com isso.

Antes da Ori: Zenith, C e Auk9

A Ori não foi a primeira tentativa — foi a terceira que sobreviveu. Quando comecei, a linguagem se chamava Zenith Language, e a primeira versão foi escrita em C. Na época fazia sentido: linguagem de sistemas se escreve em C, certo? Errado para o meu caso. Eu passei mais tempo caçando bugs de memória — ponteiros pendurados, frees duplos, corrupção silenciosa — do que desenhando a linguagem em si. As particularidades de memória do C cobravam um preço que eu não tinha como pagar: cada ideia nova vinha acompanhada de uma semana de debugging que não ensinava nada sobre linguagens, só sobre sobrevivência em C.

Depois veio a Auk9, já em Rust — e essa também foi descartada como produto. Mas descartar não foi perder: vários conceitos da Auk9 sobreviveram e vivem hoje na Ori. Foi ali que eu entendi uma coisa importante: jogar fora uma versão pode ser progresso, desde que os conceitos aprendidos viajem junto.

O ponto mais honesto: eu comecei sem entender quase nada de como uma linguagem funciona por debaixo do capô — de maneira explícita, quero dizer. Eu usava linguagens, não entendia linguagens. Foi fazendo perguntas, uma atrás da outra, que o caminho apareceu: ler sobre compiladores, gerenciamento e arquitetura de memória, runtime, lexer, parser. Cada pergunta puxava outra. Até hoje posso não saber 100% de cada linha do código desenvolvido, mas entendo grande parte do mecanismo — o suficiente para acompanhar conversas sobre como linguagens funcionam e até “arranhar um pouco” nelas. Para alguém que veio de CRUD em PHP, isso já é uma viagem e tanto.

Por que criar uma linguagem

A pergunta que me persegue há anos é simples: por que quase toda linguagem otimiza para quem escreve, se a gente passa muito mais tempo lendo? Cada atalho sintático parece inofensivo sozinho. Mas some centenas deles num projeto real e a leitura vira decodificação. Para quem está chegando, para quem tem TDAH e precisa de estrutura explícita, para um code agent que precisa entender um módulo sem carregar o repositório inteiro — a conta chega.

No começo eu achava que era só uma questão de estilo. Quanto mais eu olhava, mais me parecia um problema de arquitetura da própria linguagem: legibilidade não é cosmético, é a interface mais usada do sistema. E quase ninguém desenha linguagem começando por ela.

Eu também queria responder uma segunda pergunta: até onde uma pessoa fora da área — com IA como parceira — consegue levar o design de uma linguagem séria? A Ori é, além de tudo, esse experimento.

O que a Ori é — e o que ela não é

A Ori é uma linguagem reading-first, de tipos explícitos, compilada para código nativo (AOT), com compilador escrito em Rust. Ler um programa Ori deveria parecer ler uma especificação: nomes que dizem o que fazem, pouca magia, fluxo visível.

O que ela não é: ela não é uma tentativa de substituir Rust, Go ou qualquer linguagem estabelecida. Não é produto para competir no mercado. Ela existe para estudo de compiladores, para programação assistida por IA e para legibilidade — inclusive para cérebros que funcionam como o meu. Essa honestidade sobre o escopo me liberta para tomar decisões impopulares quando elas servem à leitura.

E tem o motivo que está acima de todos os técnicos: eu não quero criar um produto, nem nada para o mercado. Quero fazer algo que me deixe feliz — criar meus experimentos, brincar com as ferramentas e, ao longo de toda essa jornada, aprender e me divertir. Se a Ori virar algo útil para mais gente, ótimo. Mas o objetivo principal já está sendo cumprido toda vez que eu me divirto desenhando ela.

Como eu criei: as decisões

Nada aqui nasceu pronto. O processo foi mais ou menos assim: ideia inicial, primeira possibilidade, consequência inesperada, comparação com alternativas, refinamento. Algumas decisões importantes e seus trade-offs:

Compilador em Rust, alvo nativo (AOT). O caminho óbvio seria algo interpretado primeiro — mais rápido de prototipar. Mas AOT me obriga a levar cada feature até o codegen, o que funciona como teste de sanidade do design: se uma ideia não sobrevive à compilação nativa, talvez ela não fosse tão boa assim. O custo é velocidade de iteração, e eu pago esse custo de olhos abertos. Para experimentos rápidos existe o modo ori run, com JIT opcional.

Tipos explícitos, sem adivinhação. Inferência agressiva economiza digitação e cobra leitura: você nunca sabe ao certo qual tipo está fluindo ali sem perguntar à ferramenta. Como a proposta é reading-first, a explicitude venceu. É mais verboso, portanto — e eu prefiro verbosidade honesta a concisão misteriosa.

Sintaxe legível por padrão. Qualquer açúcar sintático precisa justificar a existência provando que não prejudica a leitura. Essa regra já matou várias ideias que eu gostei no primeiro dia e odiei na primeira releitura. Releitura, aliás, virou método: se eu não entendo meu próprio código uma semana depois sem esforço, a sintaxe falhou.

Tooling desde o dia um. LSP, diagnósticos claros, exemplos que rodam. Documentação e erros amigáveis dão tanto trabalho quanto o compilador — e numa linguagem reading-first, um erro críptico trai a proposta inteira. Então erro bom não é polish, é requisito.

Especificação aberta. Tudo — manifesto, spec, planejamento, changelog — vive no repositório. Isso não é só transparência: é o que permite que agentes (e pessoas) trabalhem no projeto com contexto real, em vez de adivinhar intenções.

Construindo junto com IA

Preciso ser honesto sobre um ponto: eu não teria chegado até aqui sozinho, e não finjo o contrário. A IA escreve rascunhos, explora alternativas, aponta furos no meu raciocínio. O meu trabalho é outro: decidir. Julgar trade-offs, manter a visão coerente, dizer não para ideias boas que não servem a este projeto.

Funciona porque eu trato a IA como parceira de investigação, não como oráculo. Eu pergunto “quais são as alternativas?”, “o que quebra se eu fizer assim?”, “me mostra onde isso já foi tentado?”. E desconfio de respostas muito confiantes — inclusive das minhas.

Existe um efeito colateral interessante: projetar uma linguagem sendo assistido por IA me ensinou muito sobre o que torna código legível para IAs. Fronteiras explícitas, decisões documentadas, exemplos pequenos e completos. No fundo, o que ajuda um agente a entender o código ajuda uma pessoa também — especialmente uma pessoa com memória de trabalho limitada, como eu.

Estado atual e próximos passos

A Ori está pré-1.0: a superfície atual é a S3, sintaxe anterior é rejeitada, e mudanças ainda são permitidas antes de um contrato estável. Eu colocaria o projeto em 7/10 hoje — a base (parser, tipos, codegen, spec) existe e compila programas reais, mas faltam diagnósticos melhores, mais exemplos, profiling e validação com gente de verdade usando.

O próximo passo que pode confirmar ou derrubar as escolhas é sempre o mesmo: colocar exemplos não-triviais para compilar, medir, e observar onde dói. Se a dor se repete no mesmo lugar, ali mora a próxima decisão.

Tudo aberto no repositório: manifesto, especificação, exemplos e changelog. Se você também lê mais do que escreve, talvez essa linguagem seja para você.