Eu comecei a Ori pensando em um problema relativamente pequeno: eu queria uma linguagem onde ler o código fosse tão natural quanto ler uma especificação. Só que, conforme fui desenhando as primeiras partes, ficou claro que a decisão mexia com algo bem maior — sintaxe, sistema de tipos, tooling e até a forma como agentes de IA leem o código.

A pergunta que me incomoda há um tempo é simples: por que a maioria das linguagens otimiza para quem escreve, se passamos muito mais tempo lendo? Individualmente, cada atalho sintático parece inofensivo. Mas quando um projeto acumula centenas desses atalhos, a leitura vira decodificação — principalmente para quem está chegando agora, seja uma pessoa ou um code agent.

O que eu estava tentando resolver

Quero uma linguagem de sistemas mais simples que Rust na superfície, sem abrir mão de tipos explícitos nem de compilação nativa (AOT). “Simples” aqui não significa limitada: significa que o básico precisa ser óbvio, e a complexidade aparece progressivamente, só onde faz sentido.

Onde a solução óbvia começa a falhar

O caminho mais óbvio seria pegar uma sintaxe existente e ir ajustando. Rust tem o ecossistema, Go tem a simplicidade, Python tem a legibilidade. Mas cada uma carrega uma filosofia que não é a que eu quero: Rust exige muito de quem está começando, Go esconde poder demais em nome da simplicidade, Python empurra erros para runtime. Nenhuma delas foi desenhada pensando em “como um agente entende este módulo sem carregar o repositório inteiro?”.

As alternativas que fazem sentido

No desenho atual, três forças puxam para lados diferentes:

• Ergonomia de leitura: sintaxe explícita, pouca magia, nomes que dizem o que fazem. Custa verbosidade.
• Performance nativa: AOT com um backend sério. Custa tempo de implementação — cada feature precisa sobreviver ao codegen.
• Tooling desde o dia um: LSP, diagnósticos bons, exemplos rodando. Custa velocidade, porque documentação e erros amigáveis dão tanto trabalho quanto o compilador.

A opção que mais me interessa hoje

Neste momento, manter o compilador em Rust com AOT me parece a combinação mais coerente: controle de baixo nível, ecossistema de tooling e um core independente da interface. A sintaxe segue legível por padrão, e o que for açúcar sintático precisa justificar a existência mostrando que não prejudica a leitura.

Isso não significa que a decisão está encerrada. Significa apenas que, hoje, ela paga o próprio custo.

O que ainda me preocupa

Duas coisas. Primeiro: até onde dá para simplificar sem transformar a linguagem em um brinquedo? Segundo: diagnósticos. Uma linguagem reading-first que devolve erros crípticos trai a própria proposta — e erro bom é caro de construir.

Próximos passos

O teste real é colocar exemplos não-triviais para compilar, medir, e ver onde a sintaxe começa a doer. Se a dor aparecer sempre no mesmo lugar, é ali que mora a próxima decisão. O estado atual está no repositório — especificação, exemplos e changelog abertos.