;; W1 pure representative: ordinary Clojure-shaped values/functions only.
(ns examples.w1-pure)

(defn double [n]
  (+ n n))

(defn main []
  (double 21))

CID de origem bafkreiaeohkv2zu… IPFS CIDv1 · raw · sha2-256 de hello.kotoba
fonte SHA-256 0471d55d668ed5f9… sha-256 do arquivo exato mostrado aqui
KIR verificado SHA-256 92635333e1e0da86… a representação tipada e verificada por efeito que o compilador admitiu
identidade do artefato SHA-256 cfea3b89cc022a6b… vincula fonte, política, contrato do compilador e ABI do destino

O CID fonte abre hello.kotoba. Os digests SHA-256 identificam bytes fonte, KIR verificado e identidade do artefato; não são endereços IPFS.

SEGURO + RÁPIDO · CONSTRUÍDO PARA SOFTWARE GERADO POR IA

Código seguro. Construído para velocidade de máquina.

Kotoba é uma linguagem em forma de Lisp projetada para software gerado por IA seguro e ultra-rápido. Programas inspecionáveis, capacidades explícitas e artefatos endereçados por conteúdo conectam verificações do compilador à execução controlada.

BUILD FRIO MAIS RÁPIDO · 4 DE 4 ORDENAÇÕES QUALIFICADAS

Construção fria mais rápida de qualquer cadeia de ferramentas neste host.

11.75ms

Kotoba fonte para um artefato WebAssembly, processo frio — então executado, e a resposta verificada após o relógio ter parado.

KotobaCLI lançado · WebAssembly 11.75 msmais rápido aqui
C / ClangHost nativo 29.08 ms2.5× Kotoba
Rust / rustcWebAssembly 38.99 ms3.3× Kotoba
Rust / rustcHost nativo 56.02 ms4.8× Kotoba
JVM / javacclasse JVM 171.53 ms14.6× Kotoba

Tempo de parede de construção a frio do processo em milissegundos; menor é mais rápido. K=1 fonte, pistas intercaladas em um host, 7 amostras cada.

Todas as ordenações 4 passam perfgate em sua política padrão não relaxada — pelo menos 5% e separado do propagação própria dos braços — assim a ordenação se mantém mesmo que o host estivesse ocupado. Limitado a este host, este tamanho de fonte e esta execução: o tempo de construção não é velocidade de execução, a vantagem diminui à medida que a fonte cresce, e o lançado binário tem um teto rígido de correção. Todos os cinco benchmarks, incluindo os que vão contra Kotoba, estão abaixo. Medidos 2026-08-31 ligado Apple M4.

Veja os cinco benchmarks Inspecionar as amostras

Quando IA gera, constrói, testa e regenera código continuamente, a latência de construção se torna a vazão da infraestrutura.

Instalar e executar Veja como funciona Configuração do agente de IA

NEGAR POR PADRÃO

Sem autoridade ambiente

Sem sistema de arquivos, rede, processo, relógio, modelo ou segredos implícitos.

KIR VERIFICADO

Autoridade sobrevive à compilação

Tipos, efeitos, recursos e suporte ao alvo são admitidos antes da emissão.

IMPOSTO PELO HOST

Apenas a concessão está vinculada

O host e o provedor aplicam escopo concreto e registram a decisão.

PISO PÓS-QUÂNTICO

Sem rebaixamento apenas clássico

Novos limites de criptografia e publicação requerem evidência ML-KEM ou ML-DSA e rejeitam material PQ removido.

01 O problema

IA pode escrever mais rápido do que humanos podem revisar

Código gerado pode ser útil e ainda alcançar um arquivo, rede, segredo, processo, modelo ou superfície de pagamento que a requisição nunca pretendia expor.

O VELHO PADRÃO

Construa amplamente, restrinja depois

Um programa de uso geral começa com semântica ambiente. Sandboxes, IAM, containers, política e assinatura são adicionados ao redor para recuperar o limite pretendido.

O PADRÃO KOTOBA

Conceder restritamente, depois compilar

Efeitos e capacidades fazem parte do cálculo admitido. Se o destino não puder provar e vincular a concessão, ele não emite nem executa o artefato.

Kotoba complementa isolamento de runtime e SO; não torna essas camadas desnecessárias.

Onde a mente do Lisp e a reescrita de grafo do GP 2 encontram a disciplina do Rust

Kotoba é uma linguagem pequena, orientada a dados, com formato Clojure. Seu design se baseia na tradição Lisp de código como dados e Reescrita de grafo baseada em regras do GP 2, com disciplina estática em torno de autoridade, efeitos, recursos, pacotes e identidade de artefatos.

INTUITIVO

Código como dados legíveis

Valores imutáveis, funções comuns, dados explícitos e sintaxe composicional são fáceis para humanos e modelos produzirem e inspecionarem.

DECLARATIVO

Dizer o que pode acontecer

Efeitos, capacidades, recursos, dependências e alvos são entradas visíveis para admissão — não surpresas descobertas após a implantação.

SEGURANÇA-PRIMEIRO

Menos linguagem, limite mais difícil

Sem interoperabilidade ambiente, carregamento de código em tempo de execução, mutação irrestrita, macros definidas pelo convidado ou concorrência ilimitada na superfície do componente admitido.

SEGURO + RÁPIDO · CONSTRUÍDO PARA SOFTWARE GERADO POR IA.
Esta é uma direção de confinamento, não uma afirmação 'inviolável'. O compilador, verificador, tempo de execução, provedores, raízes de política, custódia de chaves e isolamento do SO permanecem na base de computação confiável.

02 Como o limite funciona

Segurança em toda a computação

O limite é transportado da intenção à execução. Cada estágio restringe ou verifica a autoridade; nenhum estágio posterior pode inventar uma concessão.

1 · FONTE

Intenção declarativa

Uma pequena superfície em forma de Clojure mantém programas legíveis e exclui rotas de escape ambientais.

2 · VERIFICAR

KIR verificado

Tipos e efeitos transitivos tornam-se uma representação independente do alvo e inspecionável.

3 · ADMITIR

Autoridade de interseção

Concessões solicitadas, delegadas, de política local, de recurso e de destino só podem restringir.

4 · IDENTIFICAR

Endereçar o artefato

Código, dependências, política, contrato do compilador e ABI do alvo vinculam a identidade da computação.

5 · APLICAR

Vincular no host

O runtime e o provedor vinculam apenas capacidades admitidas, aplicam orçamentos finitos e emitem recibos.

Identidade de conteúdo não é autoridade.
Verificação CID, assinaturas, revogação, política do host, verificações de recursos e isolamento do SO permanecem limites separados.

Avaliação Lisp, sem avaliação de host ambiente

Kotoba avalia código verificado como dados endereçados por conteúdo. O familiar (eval request) a superfície diminui para o tipado :code/eval capacidade; nunca recebe texto-fonte, um formulário de leitor, um namespace ou um objeto host.

CID DE DEFINIÇÃO

Qual código?

O CID seleciona uma definição KIR verificada por hash e sua clausura de dependência somente CID.

CID DE ADMISSÃO

Pode rodar aqui?

A interface exata, linha completa de efeitos, permissão atual, combustível e profundidade de avaliação decrescente são vinculados antes da execução.

CID DE VALOR

O que voltou?

O resultado tipado é persistido como evidência endereçada por conteúdo. Seu hash não pode autorizar retroativamente um efeito.

Identidade, autoridade e evidência de resultado são três fatos diferentes.

Contrato da máquina: lang/typed-eval.edn. Capacidade do fio do compilador: 30. Aplicação limitada permanece aplicação ordinária de clausura de módulo fechado.

Padrões para uma pilha de computação com foco em IA

Estas são reivindicações de engenharia com sua qualificação anexada. Padrão, pronto para limite, parcial e direção são estados diferentes; nenhum é promovido silenciosamente a universal.

DIREÇÃO MEDIDA

Compile mais rápido. Execute mais rápido. Mantenha a fronteira.

Kotoba publica medições de inicialização do compilador, ciclo do desenvolvedor, runtime nativo e domínio de carga com verificações de resultado exato. Rankings atuais de velocidade permanecem retidos até que seus portões de host silencioso passem; admissão de segurança nunca é removida para vencer um tempo.

PRONTO LIMITADO

Armazenamento sem limite de linguagem.

Kotobase usa identidade de conteúdo, leituras de intervalo, histórico imutável e armazenamento neutro ao provedor. Capacidade física, locação, retenção, custo, replicação e orçamentos de execução permanecem explícitos; isto não é uma reivindicação de disco infinito.

PADRÃO

Criptografia pós-quântica por padrão.

Cada nova fronteira criptográfica Kotoba deve nomear evidência ML-KEM ou ML-DSA e rejeitar um downgrade apenas clássico. Passkeys existentes, transporte, implementações e custódia de chaves permanecem fronteiras qualificadas separadamente.

PADRÃO

Autenticação presente. Autoridade negada por padrão.

Identidade Passkey pertence à fronteira de controle. Uma identidade verificada ainda não recebe autoridade de sistema de arquivos, rede, armazenamento, modelo, segredo, pagamento ou GPU até que uma concessão explícita e escopada sobreviva a políticas locais e verificações do host.

PRONTO LIMITADO

Delegação flexível que só pode restringir.

Escopos solicitados, delegados, de política local, recurso e alvo se intersectam. A delegação pode ser composta e atenuada, mas não pode criar autoridade ambiente nem ampliar a concessão de seu emissor.

PRONTO LIMITADO

Pronto para Web3, neutro em relação à cadeia na raiz.

Um Principal Kotoba estável e controlador Passkey são primários. Contas CAIP-10, ERC-1271 e ERC-6492 são provas explícitas de contas vinculadas; um endereço de carteira nunca se torna silenciosamente autoridade de armazenamento ou execução.

PARCIAL IMPLEMENTADO

Cópia zero onde a propriedade permite; uma cópia onde um limite exige.

Visualizações de bytes em colunas mantêm vetor, ByteBuffer direto e suporte Uint8Array. A projeção Arrow pode manter buffers não comprimidos em colunas através do caminho autorizado do lago Kotobase. Entrada de rede, descompressão, upload GPU e atualizações persistentes imutáveis permanecem limites nomeados de cópia.

PARCIAL IMPLEMENTADO

Dados em forma de seta. SIMD explícito da CPU e kernels nativos de GPU do dispositivo.

No Apple M4, uma coluna Arrow float32 não nula e não comprimida reteve um suporte linear de memória WebAssembly enquanto Num executou um kernel explícito v128 f32x4 sobre seu slice de valores emprestados com zero cópias Arrow-para-SIMD; uma cauda escalar cobriu as linhas restantes. Em três execuções qualificadas da mesma carga de trabalho e artefato em escala 262,147-elementos, esse kernel SIMD completou 3.66-3.72x mais rápido que Wasm escalar. Este é um resultado de kernel e host, não uma reivindicação geral de runtime. O mesmo caminho limitado da coluna também retém um ArrayBuffer através de suas visualizações de CPU, cruza o limite de propriedade da GPU com um upload WebGPU medido, executa no Metal e retorna um escalar de quatro bytes. Colunas anuláveis, outros tipos Arrow, remoção de upload de memória unificada, kernels mais amplos e qualificação universal CPU/GPU permanecem pendentes.

PADRÃO

IA primeiro. Seguro para agentes por padrão.

Kotoba é projetado para programas escritos ou operados por agentes e bots de IA. Quanto mais forte o modelo, mais importantes se tornam efeitos explícitos, recursos finitos, confinamento de capacidade, recibos e aplicação pelo host.

DIREÇÃO

Limites prontos para AGI, não uma reivindicação AGI.

A arquitetura pretende manter a autoridade explícita à medida que os modelos se tornam mais capazes. Kotoba não afirma que AGI existe aqui, que os programas gerados são confiáveis, ou que o confinamento remove o compilador, tempo de execução, provedor, custódia de chaves e base de computação confiável do SO.

Autoridade da máquina: lang/product-defaults.edn. Armazenamento físico ilimitado, zero cópias em todos os lugares, classificação universal de velocidade, AGI alcançada e inquebrável permanecem reivindicações absolutas proibidas.

O que Kotoba escrito por IA não pode pedir

Superfície de linguagem deliberadamente ausente
Limite	Por que está ausente
`compile, load, load-file, load-string, ns-resolve, read-string, require, resolve, use`	Componentes não podem fabricar código ou autoridade a partir do estado ambiente do processo. Strings de fonte, formas de leitor, namespaces carregados e objetos do host compilados nunca foram inferidos por efeito e não fazem parte de um CID de definição. A operação `(eval request)` admitida é portanto separada: ela seleciona KIR já verificado por CID através de :code/eval e é readmitida pelo host.
`., .., import, new`	Acesso arbitrário a objeto e método JVM/JS contorna admissão de capacidade. Não relaxável por despacho de concessão: interop nunca alcança guard-component-ability-call, então interseção de concessão, recibos e revogação não podem ver a chamada. Vazio na ABI wasm32 (não existe tal caminho); suporte em portátil/confiável, onde o portão de subconjunto é o único limite (nenhuma sandbox VM separada é reivindicada lá).
`alter-var-root, atom, binding, deref, dosync, ref, reset!, set!, swap!, var, volatile!`	Estado mutável externo é propriedade do provedor e mediado por capacidade/política; estado local do componente deve usar um modelo explicitamente limitado. O invariante é AMBIENTE, não a mutação em si. Desde 2026-09-02 essa leitura tem duas consequências em vez de uma. Uma célula que escapa, persiste ou atravessa uma função é propriedade do provedor e permanece no caminho :state-kit-desugar (a linha de efeito mostra :state, uma concessão é necessária na instanciação, manipuladores de capacidade são rejeitados como valores armazenados). Uma célula que não faz nenhuma dessas coisas -- (let [a (atom 0)] (swap! a + 1) @a) -- não precisa de host algum: o slice de estado local 1 a elabora em reatribuições let ordinárias, então nada a observa além do código linear que a possui e nenhuma célula existe em tempo de execução. atom / swap! / reset! / deref são portanto admitidos via elaboração, e recusados no momento em que a célula escaparia. ref / dosync / volatile! / binding / var / alter-var-root / set! não têm modelo de capacidade decidido e permanecem rejeitados com falha fechada.
`agent, future, locking, pmap, send, send-off`	O agendamento de componentes e recursos deve permanecer controlado e limitado pelo fornecedor. Nem CIDs de definição nem concessões delegadas medem CPU ou agendamento; combustível é por instância e threads ambiente escapariam dele. Uma capacidade de spawn estruturado com combustível sub-orçado é projetável mas indecisa; nenhum caminho de ampliação ainda.
`defmacro`	A superfície do componente seguro deve ser inspecionável estaticamente antes da execução. Inflexível: expansão executa código dentro do compilador (tempo de compilação), e os hashes CID da definição pós-desugar KIR tipado, então macros ilimitadas executam cedo e tornam a identidade da fonte não revisável. defdesugar (desugar puro limitado) permanece a alternativa admitida.
`catch, throw, try`	Throw/try/catch ambiente é fluxo de controle não local não rastreado: ele sai de escopos que a linha de efeito inferida nunca menciona e pula obrigações de unwind (a retração da faceta do espaço de dados ainda não tem unwind verificado). A proibição é sobre a forma ambiente. Desde 2026-09-02 a capacidade de abortar tipada admite as cabeças por elaboração: o efeito aparece na linha inferida como :abort e a função reduz para [:result T E], então a forma ambiente nunca existe pós-elaboração. O Slice 2 (2026-09-02) fez :abort propagar através de chamadas e normalizou A um operando ou teste abortante em uma ligação let; nenhum amplia o invariante, porque um abort propagado está na linha do chamador e um normalizado A é a mesma elaboração em posição diferente. Onde a pré-condição de unwind importaria, o abort permanece recusado -- para uma CALL agora assim como para um throw.

Estas são restrições de segurança nomeadas em lang/surface-status.edn, não recursos ausentes de um roteiro.

03 A evidência

Prova, com o limite anexado

Kotoba separa evidência de implementação da tração de mercado e mantém risco residual próximo a cada reivindicação de segurança.

núcleos 33

Uso interno de produção

A pilha Kotoba mais ampla executa 33 núcleos de inferência internamente. Isso prova que a equipe opera sua própria pilha; não é tração de cliente, adoção paga ou receita.

Reivindicações 8

Limites são legíveis por máquina

Reivindicações de segurança nomeiam sua base de computação confiável, evidências negativas e risco residual em vez de colapsar em um slogan 'inviolável'.

negar por padrão

Sem concessão, sem efeito do host

Uma política vazia não concede autoridade de sistema de arquivos, rede, processo, relógio, modelo ou segredo. Os provedores também devem validar o escopo concreto do recurso.

Uso interno em produção é apenas evidência de dogfooding. Não implica clientes externos, pilotos pagos ou receita.

Cinco benchmarks. Cinco perguntas diferentes.

A inicialização do compilador pergunta quão rápido uma fonte minúscula se torna um artefato. A escala de construção pergunta o que acontece com esse número quando a fonte deixa de ser minúscula — e se o artefato ainda responde. O loop do desenvolvedor separa resolução, verificação, construções e primeiro resultado. O tempo de execução nativo pergunta quão rápido o código já construído roda. O conjunto de domínio de carga de trabalho pergunta como strings, coleções, alocação, E/S, concorrência e uma pequena aplicação real se comportam. Os resultados mantêm as cinco perguntas — e seu status de evidência — separadas.

INÍCIO DE CONSTRUÇÃO · RANQUEAMENTO NÃO QUALIFICADO

toolchains 4, 21 execuções cada

Kotoba 40.998 ms · Rust 126.422 ms · C 146.324 ms · JVM 961.248 ms mediana.

21 amostras rotativas em processo frio · carga1 30.79 → 39.79 · requerido ≤ 1 · 2026-08-29 · Apple M4

TEMPO DE EXECUÇÃO · COBERTURA COMPLETA

Cargas de trabalho 6 × comparadores 5

Amu nativo é testado contra Rust, Clang / C11, Zig, Go c-shared, Swift através de um limite comum de chamada nativa.

pares comparador/carga 30/30 · respostas exatas verificadas

VELOCIDADE DE EXECUÇÃO · 19/30 QUALIFICADO

19 de 30 pares

Amu nativo vence 19 dos 30 pares comparador/carga de trabalho por pelo menos 5%, separado da propagação própria dos braços. A reivindicação de mais rápido limitado precisa de todos os pares, então permanece não qualificada — a contagem é a metade informativa.

Pelo menos 2 desses pares não podem ser vencidos de forma alguma. Em aritmética estreita, amu, Apple clang -O3 e rustc -O3 compilam o kernel para a mesma sequência de instruções 61 — clang e rustc idênticos em bytes, amu diferindo apenas nos números de registradores. Uma margem 5% sobre código idêntico não existe, então a reivindicação limitada é inatingível em vez de meramente não atendida.

Mediana de 5 execuções qualificadas pelo host; a pontuação variou de 19 a 20 e 19 dos 30 pares qualificaram em cada uma. Uma única amostra ruidosa pode desqualificar vários pares de uma vez, então uma pontuação de uma execução não é precisa para um par.

CPU ocupada 0.090 → 0.069 → 0.076 · requerido ≤ 0.10 · 2026-09-07

LOOP DO DESENVOLVEDOR · RANK NÃO QUALIFICADO

Caminhos da cadeia de ferramentas 11

Resolução de dependências, verificação, builds limpos e sem alterações, e o primeiro resultado com processo frio são registrados separadamente.

Amostras 7 por estágio medido · load1 20.84 → 24.49 · requerido ≤ 1

ESCALONAMENTO DE CONSTRUÇÃO · TETO ENCONTRADO

tamanhos de fonte 8

O mesmo programa de uma função para 2048, construído por todas as toolchains no host e então executado. O binário lançado tem o menor custo de inicialização fria aqui e uma correção teto acima das funções 128.

artefatos verificados após o relógio parar · carga1 2.73 → 2.73 · requerido ≤ 1 · 2026-08-31

DOMÍNIOS DE CARGA DE TRABALHO · RANK NÃO QUALIFICADO

domínios 6 × caminhos de tempo de execução 6

Strings, coleções, alocação, E/S de arquivos, concorrência com quatro trabalhadores e um kernel de aplicação de política de admissão de requisições são verificados quanto à correção.

Amostras 7 em faixas process-cold e amortizadas · load1 13.87 → 12.38 · ranking retido

Tempo de build conforme a fonte cresce

Os benchmarks acima constroem um programa pequeno o suficiente para caber em uma tela, que mede quão rápido uma cadeia de ferramentas inicia. Diz pouco sobre o número que um desenvolvedor realmente espera, que é a inclinação. Este quinto benchmark gera o mesmo programa em tamanhos crescentes — K funções independentes de quatro operações e um ponto de entrada que chama todos eles — e constrói através de toda cadeia de ferramentas no host, em ordem rotativa.

Então executa o que cada cadeia de ferramentas produziu, após o relógio ter parado. Essa verificação não é decoração. A maneira mais rápida de emitir um artefato é emitir um quebrado, para que uma lane que parou de funcionar postaria de outra forma seus melhores números exatamente onde parou de funcionar.

Ambos os eixos são logarítmicos: as fontes abrangem três ordens de magnitude e os tempos também. Uma linha termina em um ponto onde a execução terminou, em um xis onde aquela faixa emitiu um artefato que não é o programa, e em uma barra onde a cadeia de ferramentas recusou a compilação. Esses três não são o mesmo evento e as duas falhas abaixo não são a mesma falha.

Tempo de parede de construção a frio por tamanho da fonte; medianas, um host, faixas intercaladas
Cadeia de ferramentas / alvo	K=1	K=32	K=128	K=129	K=512	K=1023	K=1024	K=2048
Kotoba · CLI lançado · WebAssembly	11.753 ms	35.84 ms	111.538 ms	artefato inválido	artefato inválido	artefato inválido	compilação falhou	compilação falhou
Kotoba / Amu · WebAssembly	733.255 ms	825.418 ms	1123.04 ms	1123.847 ms	3380.63 ms	9242.463 ms	compilação falhou	compilação falhou
Kotoba / Amu · nativo aarch64-macos	962.198 ms	1509.84 ms	2973.249 ms	3000.243 ms	10601.87 ms	23725.327 ms	compilação falhou	compilação falhou
Rust / rustc · WebAssembly	38.992 ms	45.622 ms	66.066 ms	65.56 ms	151.592 ms	277.88 ms	280.867 ms	595.812 ms
Rust / rustc · Host nativo	56.023 ms	62.849 ms	82.107 ms	82.277 ms	159.519 ms	261.586 ms	260.934 ms	469.277 ms
C / Clang · WebAssembly	sem cadeia de ferramentas	sem cadeia de ferramentas	sem cadeia de ferramentas	sem cadeia de ferramentas	sem cadeia de ferramentas	sem cadeia de ferramentas	sem cadeia de ferramentas	sem cadeia de ferramentas
C / Clang · Host nativo	29.078 ms	30.442 ms	35.765 ms	36.581 ms	60.594 ms	104.992 ms	101.728 ms	223.232 ms
JVM / javac · classe JVM	171.53 ms	197.998 ms	237.582 ms	238.611 ms	316.795 ms	378.252 ms	377.591 ms	454.632 ms

Medido 2026-08-31 em judahnoMac-mini.local (Apple M4). K é o número de funções geradas; a fonte Kotoba vai de 9 a 14338 linhas. Alvos, ABIs, níveis de otimização e contratos de tempo de execução diferem entre as lanes, então isso pergunta sobre latência de feedback do desenvolvedor, não trabalho equivalente. O gate de carga do host falhou (load1 2.73–2.73, requerido ≤ 1), então estas são observações desta execução e não números portáveis. Como as lanes são intercaladas, a ordenação é qualificada separadamente.

Quais ordenações sobrevivem ao teste de ruído

Uma razão não é uma classificação. perfgate recusa qualquer ordenação cujo intervalo caia dentro da própria dispersão dos dois braços, por maior que a razão pareça, e recusa um braço com poucas amostras ou muito ruído. Ele roda aqui com sua própria política padrão, não relaxada — um limiar afrouxado para permitir esta execução seria um benchmark medindo seus próprios limites. Porque as lanes são intercaladas em um host, uma lacuna que sobrevive a este teste sobrevive ao host estar ocupado.

Lançado Kotoba CLI contra cada comparador, em todos os tamanhos onde ainda emite um módulo válido
Tamanho	Comparado com	Kotoba mais rápido?	Lacuna vs dispersão combinada	Por que não, se não
K=1	C / Clang · Host nativo	sim, qualificado	17.1 ms vs 1.0 ms	—
K=1	JVM / javac · classe JVM	sim, qualificado	160.8 ms vs 5.4 ms	—
K=1	Rust / rustc · Host nativo	sim, qualificado	44.2 ms vs 0.6 ms	—
K=1	Rust / rustc · WebAssembly	sim, qualificado	27.1 ms vs 0.5 ms	—
K=32	C / Clang · Host nativo	não	5.3 ms vs 1.0 ms	melhoria-abaixo-do-limiar
K=32	JVM / javac · classe JVM	sim, qualificado	161.9 ms vs 1.2 ms	—
K=32	Rust / rustc · Host nativo	sim, qualificado	26.7 ms vs 0.7 ms	—
K=32	Rust / rustc · WebAssembly	sim, qualificado	9.8 ms vs 0.6 ms	—
K=128	C / Clang · Host nativo	não	75.8 ms vs 1.2 ms	melhoria-abaixo-do-limiar
K=128	JVM / javac · classe JVM	sim, qualificado	126.2 ms vs 2.2 ms	—
K=128	Rust / rustc · Host nativo	não	29.3 ms vs 1.4 ms	melhoria-abaixo-do-limiar
K=128	Rust / rustc · WebAssembly	não	45.8 ms vs 1.1 ms	melhoria-abaixo-do-limiar

melhoria abaixo do limite significa que a pista Kotoba não foi mais rápida naquele tamanho. A vantagem é real e qualificada no início frio, e desaparece contra C por K=32 e contra Rust por K=128. Essa cruzamento é o resultado, portanto é mostrado em vez de resumido.

Duas falhas que não são a mesma falha

Três pistas Kotoba pararam de funcionar nesta execução, e publicá-las como uma a linha teria sido errada. Uma é um defeito. As outras duas são declaradas limites sendo aplicados exatamente como especificado, e reportando-os como defeitos significaria medir os limites em vez do compilador.

O que parou, e o que significa
Observação	Lendo
O CLI kotoba lançado emite um módulo que não compilará acima de 128 funções	Um defeito, e a razão para validar dentro de um ambiente. Em K=129 uma chamada deve carregar o índice de função 128, o primeiro valor que precisa de dois bytes LEB128, e o emissor escreve um. Os bytes indicam que não é um codificador ausente, mas um não usado: local.set 128 é escrito 80 01, e call 128 uma instrução depois é escrito 80. A contagem de operandos truncados é exatamente K menos 128. O compilador atual não o possui — Amu constrói K=129 corretamente, e a correção está no ramo padrão do emissor desde antes deste lançamento ser marcado.
Cada pista Kotoba trava em K=512 quando construída com configurações padrão	Não é um defeito. Um módulo Kotoba carrega um orçamento declarado de combustível de chamadas e o padrão do compilador é 512 chamadas, que esta carga ultrapassa em K=512 onde o ponto de entrada chama 512 folhas. O arnês declara 1,048,576 unidades explicitamente e registra que o fez. C, Rust e Java não têm limite equivalente para aumentar.
Amu rejeita o módulo imediatamente uma vez que ele conteria mais de 1,024 funções	Também não é um defeito, e o oposto da primeira linha. max-functions é um limite de admissão declarado, então o compilador para com kotoba.error/subset-reject e nomeia o que recusou, em vez de emitir algo que não carregará. Um teto alto e um silencioso são resultados muito diferentes, e apenas um ambiente que executa o artefato os distingue. Medido 2026-09-07: este é o teto do programa inteiro, não de um módulo — max-project-functions também é 1,024 e é verificado contra o projeto vinculado, então nenhuma combinação de módulos compila um programa de 2,048 funções hoje.

O que isso estabelece

As respostas do quinto benchmark, incluindo as desfavoráveis
Pergunta	Resposta desta execução
Quão rápido é uma compilação Kotoba fria de um módulo pequeno?	O CLI lançado constrói K=1 em 11.753 ms com processo frio, artefato executado e resposta verificada — o primeiro resultado mais rápido de qualquer pista medido aqui.
Qual o tamanho máximo de módulo que o binário liberado pode construir?	Até 128 funções. Além disso, não é mais lento, é errado, e este ambiente relata isso como uma pista falhada em vez de rápida.
O tempo de build permanece competitivo conforme a fonte cresce?	Através de K=128 o CLI lançado é medido contra Rust e C na tabela acima. Após esse ponto, o único compilador Kotoba que ainda emite um módulo correto é o Amu, que roda no nbb em vez de como um binário lançado, e é aproximadamente uma ordem de magnitude mais lento em todos os tamanhos medidos — então em tamanhos grandes a velocidade de compilação não é atualmente uma força Kotoba, e esta página não vai afirmar o contrário.
Quão grande uma fonte foi construída de ponta a ponta?	K=1023 através de Amu — 7163 linhas de Kotoba, artefato executado e a resposta verificada. Isso é uma função a menos do que o teto declarado 1,024, e o próximo tamanho maior é recusado em vez de mal construído.
O código emitido é rápido?	Fora do escopo aqui — isso mede construção, não execução. A suíte de tempo de execução nativo acima responde a essa pergunta.

Resumo: No menor tamanho, o binário lançado é mais rápido que todos os comparadores aqui por uma margem que resiste ao teste de ruído, e tem um teto rígido de correção em 128 funções. O compilador sem esse teto é aproximadamente uma ordem de magnitude mais lento em todos os tamanhos medido. Ambos os fatos vêm da mesma execução, e o ambiente que os encontrou é público, para que a execução possa ser contestada.

Inspecionar amostras de escalonamento de build Execute novamente em sua máquina O defeito, com seus bytes

Quanto tempo cada carga de trabalho nativa realmente leva

A grade abaixo reporta a margem entre dois braços. Esse é o número regras perfgate ligadas, mas uma porcentagem sozinha não diz se um a carga de trabalho executa em cinco milissegundos ou quinhentos, e esconde o diferença entre um par contestado e um irrelevante. Estes painéis são as medianas das margens de onde são calculadas. Amu nativo é a faixa colorida em cada painel — incluindo os painéis onde não é o primeiro. Cada painel é escalado para seu próprio braço mais lento, porque a pergunta que um painel responde é quem é mais rápido nessa carga de trabalho.

Aritmética estreita

Clang / C11 6.41 ms
Amu nativo 6.53 ms1.02× o mais rápido aqui
Swift 6.55 ms
Rust 6.58 ms
Zig 8.24 ms
Go c-shared 42.84 ms

Alta pressão de registradores

Amu nativo 5.80 msmais rápido aqui
Rust 6.19 ms
Clang / C11 6.50 ms
Zig 6.97 ms
Go c-shared 41.07 ms
Swift 44.08 ms

Pressão profunda de spill

Amu nativo 9.23 msmais rápido aqui
Rust 9.61 ms
Zig 9.71 ms
Clang / C11 10.23 ms
Go c-shared 51.86 ms
Swift 124.27 ms

Preservação de chamada

Rust 4.77 ms
Clang / C11 4.82 ms
Amu nativo 4.85 ms1.02× o mais rápido aqui
Swift 6.77 ms
Zig 8.44 ms
Go c-shared 32.49 ms

Fluxo de controle de ramificação + chamada

Clang / C11 4.67 ms
Rust 4.90 ms
Amu nativo 4.98 ms1.07× o mais rápido aqui
Swift 6.72 ms
Zig 8.95 ms
Go c-shared 33.84 ms

Borda de retorno de chamada de loop

Clang / C11 139.84 ms
Amu nativo 140.59 ms1.01× o mais rápido aqui
Rust 141.73 ms
Go c-shared 169.38 ms
Swift 186.09 ms
Zig 207.01 ms

Mediana em milissegundos sobre 5 execuções qualificadas do host; menor é mais rápido. Cada braço retornou a mesma resposta verificada independentemente, e a mediana candidata é um valor por carga — o conjunto rotaciona cada par de motores na ordem ABBA/BAAB, então o mesmo artefato Amu é cronometrado uma vez por carga e depois comparado contra cada braço em sequência. Diferente dos outros quatro benchmarks nesta página, o gate de host silencioso deste PASSEOU (carga-host-qualificada), então estes são números para este host e não apenas observações. A reivindicação de mais rápido limitada ainda precisa de todos os 30 pares, que é para o que a grade abaixo serve.

Cada par de runtime, vitória ou derrota

A reivindicação limitada é tudo ou nada, então um único par não qualificado a torna falsa. Publicar apenas esse veredicto ocultaria quais pares são contestados, então o todo a grade está aqui. Uma célula é a melhoria média do Amu nativo sobre esse comparador nessa carga de trabalho; positivo significa que Amu é mais rápido, e um check marca os pares que perfgate claro — pelo menos 5% e separado da própria dispersão dos braços.

Amu nativo vs cada comparador, 2026-09-07, qualificado pelo host; ✓ = passa perfgate
Carga de trabalho	Rust	Clang / C11	Zig	Go c-shared	Swift
Aritmética estreita	+0.4%	-0.6%	+20.1%	+84.7%	-0.6%
Alta pressão de registradores	+6.5%	+10.9%	+16.9%	+86.0%	+87.1%
Pressão profunda de spill	+4.2%	+9.3%	+5.1%	+82.2%	+92.6%
Preservação de chamada	-1.0%	-0.3%	+42.9%	+85.2%	+29.6%
Fluxo de controle de ramificação + chamada	-2.6%	-7.1%	+43.8%	+85.2%	+25.1%
Borda de retorno de chamada de loop	+0.8%	-0.1%	+32.4%	+17.2%	+24.8%

Cada célula é uma barra que cresce a partir de uma linha central: à direita dela Amu nativo é mais rápido, à esquerda mais lento. As duas direções são escaladas separadamente — as vitórias vão até +93% e as perdas apenas até −7%, então uma escala compartilhada achataria cada par contestado em uma mesma faixa invisível. O sinal também é indicado pelo lado da linha e pelo número com sinal, então nenhuma leitura desta grade depende de distinguir duas cores.

19 de 30 pares qualificados (mediana de 5; 19 em cada execução) · candidato 42f092ea5b61 · Apple M4, 10 CPUs lógicas, 16 GiB

Entrega de otimização após a execução publicada

O benchmark datado acima permanece imutável. Novas fatias de implementação são listadas separadamente até que o conjunto de artefatos iguais seja reexecutado e passe por seus portões de qualificação.

Superfícies implementadas que ainda não são novas reivindicações de velocidade
Superfície	Entregue	Limite de evidência
Vetores nativos / alocação	Literais vetoriais limitados não escapantes são provados como não escapantes e substituídos por escalares em x86-64 e AArch64.	Testes de backend 211 / 2,442 asserções; vetores escapando mantêm o ABI do host verificado. Nenhum tempo ranqueado novo ainda.
SIMD de string	Igualdade verificada POSIX usa comparação explícita 16-byte NEON ou SSE2 após validação de handle e UTF-8 canônica.	Assembly otimizado e ambos os vetores semânticos ISA nativos verificados. Windows permanece fixado separadamente; classificação de latência pendente.
Capacidade de E/S assíncrona	Uso eventual confinado à raiz para leitura/gravação/listagem/existência/exclusão usa CompletableFuture na JVM e fs.promises no Node.	Testes reais de sistema de arquivos JVM e Node passam. O benchmark público standalone Wasm ainda não tem vinculação de host admitida, então sua célula de E/S permanece N/A.
Concorrência estruturada	Um escopo filho 32 limitado fail-fast une, cancela irmãos e previne fuga de vida útil do filho como estado canônico Kotoba.	Asserções de paridade 996 entre autoridade .kotoba e caminho de carga CLJC. Esta é semântica de tempo de vida estruturada, não um resultado de throughput de thread de SO.
CLI Kotoba	kotoba test/build consome o novo compilador fixo; kotoba compile emite x86-64 selado e KEXE AArch64 diretamente.	Ciclo de vida CLI público e artefato vetorizado AArch64 verificado. Native --run permanece recusado até que um recibo de carregador medido seja conectado.

Inicialização do compilador, quatro toolchains

KotobaWebAssembly 40.998 msa linha de base
Rust / rustcWebAssembly 126.422 ms3.084× Kotoba
C / ClangWebAssembly 146.324 ms3.569× Kotoba
JVM / javacclasse JVM 961.248 ms23.446× Kotoba

Tempo de parede com processo frio para uma fonte minúscula, em milissegundos; menor é mais rápido. 21 amostras rotativas por toolchain no Apple M4. O gate de carga do host FALHOU nesta execução, então estas são observações de uma máquina, não um ranking.

Medição pequena de compilação em processo frio de fonte para artefato
Toolchain	Saída	Mediana	p95	Tempo decorrido relativo
Kotoba	WebAssembly	40.998 ms	240.415 ms	1× Kotoba
Rust / rustc	WebAssembly	126.422 ms	770.495 ms	3.084× Kotoba
C / Clang	WebAssembly	146.324 ms	498.618 ms	3.569× Kotoba
JVM / javac	classe JVM	961.248 ms	2223.49 ms	23.446× Kotoba

KOTOBA 0.7.3 · RUSTC 1.97.1 · versão Homebrew clang 22.1.7 · javac 24.0.2. Kotoba, Rust e C emitem Wasm; javac emite um arquivo de classe. Diferentes alvos e trabalho do compilador fazem disso uma observação inicial, não um ranking universal. O portão de carga do host registrado falhou, então a tabela não é um ranking de velocidade qualificado.

Médias do ciclo de desenvolvimento de projetos pequenos sem dependências; N/A significa que nenhuma fase separada foi medida
Cadeia de ferramentas / alvo	Resolver	Verificar	Build limpo	Build sem alterações	Iniciar + executar	Build limpo + primeiro resultado
Kotoba · WebAssembly	N/A	231.75 ms	62.906 ms	42.332 ms	57.253 ms	142.644 ms
Rust / Cargo · arm64 macOS nativo	138.018 ms	71.208 ms	896.478 ms	67.764 ms	371.522 ms	1299.171 ms
C / Clang · arm64 macOS nativo	N/A	90.446 ms	121.838 ms	77.905 ms	327.741 ms	453.685 ms
Zig · WebAssembly	N/A	387.713 ms	648.665 ms	464.795 ms	67.523 ms	728.007 ms
TinyGo · arm64 macOS nativo	N/A	N/A	1059.624 ms	395.305 ms	203.169 ms	1269.918 ms
Go · arm64 macOS nativo	43.553 ms	6979.823 ms	3499.277 ms	150.902 ms	247.051 ms	3755.431 ms
Swift / SwiftPM · arm64 macOS nativo	1017.252 ms	427.372 ms	3695.557 ms	1259.829 ms	431.84 ms	4016.271 ms
JVM / javac · classe JVM	N/A	N/A	805.822 ms	739.957 ms	76.252 ms	882.074 ms
AssemblyScript · WebAssembly	N/A	1074.197 ms	895.187 ms	1090.658 ms	64.658 ms	954.878 ms
.NET IL · .NET IL	2309.472 ms	N/A	4750.407 ms	2141.103 ms	79.248 ms	4851.792 ms
.NET Native AOT · arm64 macOS Native AOT	2236.962 ms	N/A	11995.489 ms	2707.907 ms	375.7 ms	12391.54 ms

Cada artefato emitido produziu 42 em um processo novo. Alvos e contratos de runtime diferem; N/A nunca é zero. O portão de carga do host falhou, então estas são observações reproduzíveis em vez de um ranking de velocidade entre linguagens.

Seis domínios, lado a lado

Cada painel é dimensionado para sua própria pista mais lenta, porque a questão de um painel respostas indicam quem é mais rápido naquele domínio, não como os domínios se comparam entre si outro. A faixa de Kotoba é a colorida em cada painel — incluindo o painéis onde é o último. Seu artefato Wasm independente roda através de um Node host e paga essa inicialização em cada amostra de processo frio, enquanto Rust, C e Go executar como binários nativos; onde o alvo não tem sistema de arquivos ambiente ou thread contrato algum, a pista está ausente em vez de zero.

String

C / Clang 1.463 ms
Rust 1.907 ms
Ir 1.974 ms
JVM / Java 27.819 ms
Kotoba / Wasm + host JS tipado 30.539 ms20.9× o mais rápido aqui
JavaScript / Node.js 31.628 ms

Coleção

C / Clang 1.357 ms
Ir 1.852 ms
Rust 1.92 ms
Kotoba / Wasm + host JS tipado 29.98 ms22.1× o mais rápido aqui
JVM / Java 31.42 ms
JavaScript / Node.js 31.818 ms

Alocação

C / Clang 1.353 ms
Rust 1.943 ms
Ir 1.962 ms
JVM / Java 26.447 ms
Kotoba / Wasm + host JS tipado 29.567 ms21.9× o mais rápido aqui
JavaScript / Node.js 31.055 ms

E/S

C / Clang 2.539 ms
Rust 2.686 ms
Ir 6.577 ms
JVM / Java 38.685 ms
JavaScript / Node.js 94.124 ms
Kotoba / Wasm + host JS tipado N/A — não está no contrato deste alvo —

Concorrência

C / Clang 2.916 ms
Rust 3.328 ms
Ir 3.377 ms
JVM / Java 34.828 ms
JavaScript / Node.js 55.105 ms
Kotoba / Wasm + host JS tipado N/A — não está no contrato deste alvo —

Aplicação real

C / Clang 1.294 ms
Ir 1.964 ms
Rust 2.047 ms
JVM / Java 26.411 ms
JavaScript / Node.js 29.534 ms
Kotoba / Wasm + host JS tipado 29.652 ms22.9× o mais rápido aqui

Médias com processo frio em milissegundos; menor é mais rápido. O portão de carga do host falhou nesta execução, então estes painéis são observações e não um ranking, e a pista amortizada abaixo conta uma história diferente novamente.

Médias do domínio de carga de trabalho fria do processo; N/A significa que o contrato alvo não fornece essa capacidade
Caminho de execução	String	Coleção	Alocação	I/O de arquivo	Concorrência	Aplicativo real
Kotoba / Wasm + host JS tipado	30.539 ms	29.98 ms	29.567 ms	N/A	N/A	29.652 ms
Rust	1.907 ms	1.92 ms	1.943 ms	2.686 ms	3.328 ms	2.047 ms
C / Clang	1.463 ms	1.357 ms	1.353 ms	2.539 ms	2.916 ms	1.294 ms
Ir	1.974 ms	1.852 ms	1.962 ms	6.577 ms	3.377 ms	1.964 ms
JVM / Java	27.819 ms	31.42 ms	26.447 ms	38.685 ms	34.828 ms	26.411 ms
JavaScript / Node.js	31.628 ms	31.818 ms	31.055 ms	94.124 ms	55.105 ms	29.534 ms

Cada amostra retornou o checksum de referência exato. Kotoba usa seu Wasm emitido e ABI tipado declarado; seu alvo independente não tem sistema de arquivos ambiente nem contrato de thread, então essas células são consideradas N/A. O portão de carga do host registrado falhou, então medianas são observações, não uma classificação.

Médias amortizadas em lote no processo por carga base; N/D mantém o mesmo limite de capacidade
Caminho de execução	String	Coleção	Alocação	I/O de arquivo	Concorrência	Aplicativo real
Kotoba / Wasm + host JS tipado	0.351 ms	0.039 ms	0.066 ms	N/A	N/A	0.048 ms
Rust	0.028 ms	0.002 ms	0.003 ms	1.217 ms	1.456 ms	0.002 ms
C / Clang	0.02 ms	0.001 ms	0.003 ms	1.61 ms	1.558 ms	0.001 ms
Ir	0.023 ms	0.002 ms	0.004 ms	5.071 ms	1.582 ms	0.002 ms
JVM / Java	0.433 ms	0.051 ms	0.064 ms	17.175 ms	5.589 ms	0.043 ms
JavaScript / Node.js	0.336 ms	0.033 ms	0.067 ms	68.507 ms	7.771 ms	0.032 ms

Cada lote maior em processo é dividido pelo seu multiplicador de carga declarado. Isso amortiza a inicialização mas não remove totalmente o custo de processo, VM ou instanciação Wasm, então não é rotulado como resultado perfeitamente aquecido em estado estável. As cadeias puras de mapa inc/dec de Kotoba são fundidas em reduce sem vetores intermediários; callbacks fora desse subconjunto comprovado mantêm materialização ansiosa.

O que cada benchmark público estabelece — e não estabelece
Pergunta	Implementações comparadas	Conclusão atual
Compilação + execução Tiny Wasm	Kotoba, Rust, C e toolchains JVM	Quatro medianas de processo frio publicadas acima; apenas Kotoba/Rust/C compartilham o alvo Wasm, e nenhuma classificação geral de velocidade de build é reivindicada
Loop de desenvolvedor de projeto pequeno	Kotoba, Rust, C, Zig, TinyGo, Go, Swift, JVM, AssemblyScript, .NET IL e .NET Native AOT	Sete amostras por estágio disponível são publicadas; diferenças de alvo e um gate de carga do host falhado proíbem um ranking universal
Execução nativa em estado estável	Amu nativo vs Rust, Clang / C11, Zig, Go c-shared, Swift	Todas as células de comparação semântica 30 estão completas; ranking de velocidade retido porque o portão de host silencioso falhou
Strings, coleções, alocação, E/S, concorrência e aplicativo real	Caminhos de tempo de execução Kotoba, Rust, C, Go, JVM e JavaScript	Checksums exatos e amostras amortizadas e a frio do processo são publicados; I/O e threads Kotoba independentes são N/A, enquanto sua aplicação pura de admissão de requisição é medida; o portão de carga falhado retém o ranking

O que a suíte nativa cobre

Cada implementação retorna uma resposta conhecida verificada independentemente. O conjunto rotaciona cada par de motores na ordem ABBA/BAAB e mede após carregamento, mapeamento e busca de símbolos.

Seis cargas de trabalho nativas necessárias em runtime
Carga de trabalho	O que enfatiza	Status da evidência
Aritmética estreita		Resultado exato verificado; tempo não qualificado
Alta pressão de registradores		Resultado exato verificado; tempo não qualificado
Pressão profunda de spill		Resultado exato verificado; tempo não qualificado
Preservação de chamada		Resultado exato verificado; tempo não qualificado
Fluxo de controle de ramificação + chamada		Resultado exato verificado; tempo não qualificado
Borda de retorno de chamada de loop		Resultado exato verificado; tempo não qualificado

Onde cada benchmark vive

Cada número acima vem de uma armadura pública e um relatório comprometido, então um a execução pode ser repetida e uma reivindicação pode ser contestada. Os caminhos no repositório em esta tabela é verificada contra a árvore de trabalho quando esta página é gerada: um ambiente de teste que falha a compilação em vez de enviar um link morto.

Ferramenta, método e relatório para cada benchmark publicado
Benchmark	Repositório	Armadura e método	Relatório
Inicialização do compilador	kotoba-lang/kotoba-lang	scripts/benchmark-public-compile.mjs · bench/public-compile-comparison/README.md · bench/public-compile-comparison/main.kotoba	JSON publicado · bench/public-compile-comparison/latest.json
Loop do desenvolvedor	kotoba-lang/kotoba-lang	scripts/benchmark-public-end-to-end.mjs · bench/public-end-to-end-comparison/README.md	JSON publicado · bench/public-end-to-end-comparison/latest.json
Tempo de execução nativo	kotoba-lang/amu	runtime-multidomain-suite.mjs · multidomain-suite.json · performance.md · scripts/project-runtime-comparison.cljs	JSON publicado · bench/public-runtime-comparison/latest.json
Construir escalabilidade	kotoba-lang/buildbench	buildbench	JSON publicado · bench/public-build-scaling/latest.json
Domínios de carga de trabalho	kotoba-lang/kotoba-lang	scripts/benchmark-public-domains.mjs · bench/public-domain-comparison/README.md · bench/comparação-domínio-público/sondas	JSON publicado · bench/public-domain-comparison/latest.json

O portão pelo qual toda ordenação nesta página passa é kotoba-lang/perfgate, executado em sua própria política padrão não relaxada. Um limite afrouxado para permitir um executar seria um benchmark medindo seus próprios limites.

Resumo: Os artefatos, resultados exatos e amostras são reais em todos os cinco benchmarks. Três deles — inicialização do compilador, o ciclo do desenvolvedor e os domínios de carga — falharam no seu portão de host silencioso, então não pontuam e são publicados como observações. A suíte de tempo de execução nativo passou no seu portão e vence 19 de seus 30 pares, aquém da reivindicação de todos os pares que precisaria. O escalonamento de construção qualifica sua ordenação de inicialização a frio contra todos os comparadores no host e encontra um teto de correção na mesma execução. Nenhuma classificação universal de velocidade é reivindicada em qualquer lugar nesta página, e nenhuma dessas execuções licencia uma.

Inspecionar amostras de compilação Inspecionar evidência de runtime Inspecionar exemplos do ciclo do desenvolvedor Inspecionar amostras do domínio de carga Revise o método de tempo de execução Reexecutar ambiente de compilação

Reivindicações com seus limites anexados

Estas reivindicações são geradas a partir de lang/safety-claims.edn. Cada um mantém sua base de computação confiável e risco residual visíveis, porque um slogan de segurança sem um limite é apenas marketing.

T1-MEMÓRIA

Componentes admitidos não podem acessar memória em tempo de execução/nativa e operações de memória do componente são limitadas ou travam.

Base de computação confiável

leitor limitado · admissão frontend · verificador de artefatos · tempo de execução Wasm/nativo

Risco residual

vulnerabilidades do motor de execução permanecem no TCB
carregadores nativos requerem uma segunda fronteira de isolamento do SO

T2-EFEITO

Todo efeito de componente transitivo é declarado e admitido antes da emissão, incluindo efeitos usados por provedores escritos em Kotoba.

Base de computação confiável

inferência de efeito · catálogo de capacidade · gráfico de chamadas frontend

Risco residual

kotoba e gramática/efeito do compilador devem ser continuamente comparados

T3-CONFINAMENTO

Uma capacidade não concedida está ausente ou desvinculada e não pode alcançar um provedor ou manipulador nativo.

Base de computação confiável

interseção de política · emissão de importação do compilador · vinculação de importação de licitação · guarda do host

Risco residual

provedor e implementações nativas devem validar independentemente o escopo de recursos
concessões efetivas de produção devem proibir escopo curinga

T4-DETERMINISMO

A mesma fonte admitida, destino, política e bloqueio produzem o mesmo resultado puro observável e bytes de artefato.

Base de computação confiável

leitor canônico · redução determinística · toolchain fixado

Risco residual

efeitos do host são determinísticos apenas onde seu contrato de capacidade assim o determina

LIMITES-DE-RECURSOS-T5

Fonte, admissão, execução, memória e saída usam limites finitos explícitos.

Base de computação confiável

limites de admissão · medidor de combustível · cota de runtime · tempo limite do supervisor

Risco residual

supervisores de plataforma ainda não possuem evidência igual de isolamento de produção

T6-CADEIA-DE-SUPRIMENTOS

A admissão de lançamento vincula identidade do artefato, assinante confiável, validade e evidência reprodutível.

Base de computação confiável

verificador de assinatura · configuração de assinante confiável · relógio · conjunto de revogação

Risco residual

custódia de chave e distribuição externa de revogação permanecem TCB operacional

T7-BACKEND-PARITY

Um componente portátil compartilhado tem aceitação, resultado e rastreamento de efeito iguais em backends qualificados.

Base de computação confiável

manifesto de conformidade compartilhado · adaptadores de backend · executor de comparação

Risco residual

recursos apenas para compilador não são portáveis e devem ser rejeitados por perfis portáveis

ESCOPO-RECURSO-HOST-T8

Uma importação de componente alcança seu provedor ou manipulador nativo apenas com um escopo concreto de recurso pós-interseção e emite um recibo.

Base de computação confiável

interseção de capacidade · guarda do host · manipulador do provedor · sumidouro de recibo

Risco residual

verificações específicas de caminho, redirecionamento, link simbólico e locatário do provedor requerem kits Q5

Qualificação P1, a partir de 2026-07-18.

Vinculação de lançamento

Um perfil de linguagem e uma versão de implementação são separados até que um envelope assinado os vincule.

LINGUAGEM

Perfil 6

contrato de pacote 1

IMPLEMENTAÇÃO

v0.7.0

vinculação de perfil: verificado

PADRÃO PÚBLICO

LANÇADO

:docs/release-bound-profile

Kotoba v0.7.0 para darwin-arm64 é a implementação pública vinculada ao perfil de linguagem 6 e ao contrato de pacote 1. Seu envelope assinado verifica a árvore de origem, o resumo do artefato e o resultado de conformidade do teste 536 / asserção 8,580. Outras plataformas permanecem desvinculadas.

Ler a evidência de lançamento gerada

04 Comece a usar

Comece em sessenta segundos

Instalar e auto-verificar

brew tap kotoba-lang/kotoba
brew trust kotoba-lang/kotoba
brew install kotoba
kotoba selfhost check --json

Aceitar uma resposta válida com uma lista de problemas vazia.

Um primeiro programa

(defn main []
  (+ 40 2))

Este programa não solicita importações do host; o módulo emitido não tem importações.

Agente de IA: início rápido executável Abrir o guia de introdução Leia a referência CLI

Aprenda, tente, depois aprofunde

Um caminho conectado do primeiro programa até contratos de linguagem, bibliotecas, evidências e superfícies de implantação.

APRENDER

Documentação por intenção

Comece com a instalação, aprenda a linguagem admitida ou inspecione a semântica normativa e dados de conformidade.

Mapa de documentação aberto

LER CÓDIGO

Uma fonte, uma resposta

O exemplo abaixo é a fonte exata compilada na demonstração do navegador—não uma reimplementação em JavaScript.

Leia o exemplo

EXECUTAR

Executar nesta página

Carregue um artefato WebAssembly de mesma origem e digest vinculado e chame sua função principal Kotoba exportada.

Jogo Aberto

COMPILAR

Bibliotecas e contratos

Navegue por nomes principais limitados, bibliotecas fundamentais, regras de pacotes e seu limite atual de maturidade.

Navegar bibliotecas

Um pequeno programa Kotoba, rodando de verdade

Amu compila essa fonte pura Kotoba para o perfil wasm32-browser. O artefato registrado não tem importações e retorna 42.

FONTE KOTOBA

;; W1 pure representative: ordinary Clojure-shaped values/functions only.
(ns examples.w1-pure)

(defn double [n]
  (+ n n))

(defn main []
  (double 21))

Autoridade destacada: kotoba-lang/grammar → kotoba.grammar.highlight/tokenize → HTML em tempo de compilação. Contrato de escopo do editor: source.kotoba. Dependência do realçador do navegador: nenhuma. Inspecionar dependências

Compile localmente: kotoba compile double-21.kotoba --target wasm32-browser --output double-21.wasm

JOGAR · WEBASSEMBLY

Execute o artefato verificado

O navegador busca 344 bytes, verifica SHA-256, rejeita toda importação, instancia o módulo e chama main().

Resultado esperado: 42

Pronto. Nenhum código foi executado ainda.

Isto executa um exemplo pré-compilado e imutável. Editar código arbitrário no navegador ainda não é uma superfície de compilador lançada.

Demonstrações interativas: solar-helix (renderização WebGPU guiada pelo convidado) · kami-survivors (um jogo .kotoba) · gpu-clear (fumaça WebGPU). Hospedado na superfície wasm-webcomponent GitHub Pages; disponibilidade depende do suporte WebGPU/WebAssembly do navegador.

Bibliotecas, sem ocultar o limite do pacote

Bibliotecas Kotoba são grafos endereçados por conteúdo. Nomes e repositórios GitHub ajudam as pessoas a descobri-las; definições e CIDs de lançamento assinados dizem exatamente o que são.

NÚCLEO LIMITADO

Referência de símbolo gerada

Pesquise os nomes admitidos pelo contrato da biblioteca padrão limitada atual.

Navegar símbolos principais

FUNDAMENTAL

Dados, efeitos, I/O, ferramentas

Comece com coll, spec, json, texto, wit, async, tempo, fs, http, teste, fmt, lint e contratos LSP.

Navegar pelo mapa da biblioteca

CONTRATO DE PACOTE

Dependências endereçadas por conteúdo

Inspecionar CIDs exatos de dependência, camadas de identidade, proveniência GitHub e o limite atual de publicação.

Abra o catálogo de bibliotecas e publique o fluxo

Navegar toda a organização por tag

Existem 2,215 repositórios públicos em kotoba-lang organização. Cada tag abaixo é o tópico GitHub de o mesmo nome, então o filtro do site e os tópicos da organização são um vocabulário em vez de dois que derivam. Escolha um para abrir o catálogo já filtrado.

Navegue e filtre todos os repositórios 2,215

Um repositório não é um pacote publicado. Exatamente 1 biblioteca é publicada através do registro endereçado por conteúdo; o resto desta lista é descoberta. Rótulos de maturidade do repositório não implicam estabilidade da API 1.0, ampla adoção ou SLOs de produção, e 255 repositórios não correspondem a nenhuma regra de domínio e são mostrados sem etiqueta em vez de receber o rótulo mais próximo.

Pesquisar a referência verificada

Pesquise comandos, nomes da biblioteca padrão, diagnósticos e status de lançamento. O índice é gerado a partir de autoridades de máquina e permanece nesta página.

Pesquisar documentação Kotoba

Tente: compilar, opção-alguma, docs/link-faltando

lançamento

Vinculação de lançamento

Referência aberta

cli

`kotoba id`

Crie um plano de inscrição de principal Kotoba neutro à cadeia controlado por uma chave de acesso. Contas inteligentes são links explícitos CAIP-10; nenhuma cadeia ou provedor é a raiz da identidade.

Referência aberta

cli

`kotoba run`

Compile e execute um ponto de entrada Kotoba.

Referência aberta

cli

`kotoba compile`

Compile código-fonte da família Kotoba para um artefato alvo. Web .kotoba usa KIR verificado e o backend restrito kotoba-script; .cljs permanece ClojureScript.

Referência aberta

cli

`kotoba check`

Valide fonte Kotoba, contratos ou metadados de pacote sem executá-los. Adaptador do compilador: frontend admit + --profile pure-product (T9.2).

Referência aberta

cli

`kotoba graph`

Consultar e transacionar a loja de gráficos da linguagem (kgraph) com operações no formato Datomic.

Referência aberta

cli

`kotoba git`

Exponha operações do repositório Kotoba como dados, não comportamento específico do shell.

Referência aberta

cli

`kotoba rad`

Execute fluxos de trabalho de desenvolvimento rápido de aplicações sobre pacotes Kotoba.

Referência aberta

cli

`kotoba build`

Construa um projeto Kotoba em seu artefato alvo verificado. Este é o comando direto do ciclo de vida do projeto; rad build permanece uma grafia compatível.

Referência aberta

cli

`kotoba test`

Verifique e execute os testes admitidos para um projeto Kotoba. Este é o comando direto do ciclo de vida do projeto; rad test permanece uma grafia compatível.

Referência aberta

cli

`kotoba deploy`

Planeje e aplique o estado desejado do pacote para um recibo local ou um alvo residente da frota murakumo.

Referência aberta

cli

`kotoba library`

Inspecione e publique um namespace de biblioteca endereçada por conteúdo através da base de código Kotoba existente e caminho de publicação IPNS.

Referência aberta

cli

`kotoba hinshitsu`

Execute verificações de qualidade de software (evidência, portões, cobertura, regressão visual) como dados.

Referência aberta

stdlib