;; W1 pure representative: ordinary Clojure-shaped values/functions only.
(ns examples.w1-pure)
(defn double [n]
(+ n n))
(defn main []
(double 21))
-
CID de origen
bafkreiaeohkv2zu…IPFS CIDv1 · raw · sha2-256 de hello.kotoba -
fuente SHA-256
0471d55d668ed5f9…sha-256 del archivo exacto mostrado aquí -
KIR verificado SHA-256
92635333e1e0da86…la representación tipada y verificada por efectos que admitió el compilador -
identidad del artefacto SHA-256
cfea3b89cc022a6b…vincula fuente, política, contrato del compilador y ABI objetivo
El CID fuente abre hello.kotoba. Los digests SHA-256 identifican bytes fuente, KIR verificado e identidad del artefacto; no son direcciones IPFS.
SEGURO + RÁPIDO · DISEÑADO PARA SOFTWARE GENERADO POR IA
Código seguro. Construido para velocidad de máquina.
Kotoba es un lenguaje con forma Lisp diseñado para software generado por IA seguro y ultrarrápido. Programas inspeccionables, capacidades explícitas y artefactos direccionados por contenido conectan las verificaciones del compilador con la ejecución controlada.
Construcción en frío más rápida de cualquier cadena de herramientas en este host.
11.75ms
Kotoba fuente a un artefacto WebAssembly, en frío — luego ejecutado, y la respuesta verificada después de que el reloj se detuvo.
Tiempo de pared de construcción en frío del proceso en milisegundos; menor es más rápido. K=1 fuente, carriles entrelazados en un host, 7 muestras cada uno.
Todos los 4 ordenamientos pasan perfgate en su política predeterminada no relajada — al menos 5% y separado de propagación propia de los brazos — por lo que el orden se mantiene aunque el host estuviera ocupado. Limitado a este host, este tamaño de fuente y esta ejecución: el tiempo de construcción no es velocidad de ejecución, la ventaja se reduce a medida que crece la fuente, y el lanzado el binario tiene un límite estricto de corrección. Los cinco puntos de referencia, incluidos los que que van contra Kotoba, están abajo. Medido 2026-08-31 activado Apple M4.
Cuando la IA genera, construye, prueba y regenera código continuamente, la latencia de construcción se convierte en rendimiento de infraestructura.
Sin autoridad ambiental
Sin sistema de archivos, red, proceso, reloj, modelo o secretos implícitos.
La autoridad sobrevive a la compilación
Tipos, efectos, recursos y soporte de destino son admitidos antes de la emisión.
Solo la concesión está limitada
El host y el proveedor hacen cumplir el alcance concreto y registran la decisión.
Sin degradación solo clásica
Nuevos límites de cifrado y publicación requieren evidencia ML-KEM o ML-DSA y rechazan material PQ despojado.
La IA puede escribir más rápido de lo que los humanos pueden revisar
El código generado puede ser útil y aun así alcanzar un archivo, red, secreto, proceso, modelo o superficie de pago que la solicitud nunca pretendió exponer.
Construir ampliamente, restringir después
Un programa de propósito general comienza con semánticas ambientales. Se añaden sandboxes, IAM, contenedores, políticas y firmas para recuperar el límite previsto.
Conceder de forma limitada, luego compilar
Los efectos y capacidades son parte del cálculo admitido. Si el objetivo no puede probar y vincular la concesión, no emite ni ejecuta el artefacto.
Kotoba complementa el aislamiento en tiempo de ejecución y SO; no hace innecesarias esas capas.
Donde la mente de Lisp y la reescritura de grafos de GP 2 se encuentran con la disciplina de Rust
Kotoba es un lenguaje pequeño, orientado a datos, con forma de Clojure. Su diseño se basa en la tradición de Lisp de código-como-datos y Reescritura de gráficos basada en reglas de GP 2, con disciplina estática alrededor de autoridad, efectos, recursos, paquetes e identidad de artefactos.
Código como datos legibles
Valores inmutables, funciones ordinarias, datos explícitos y una sintaxis componible son fáciles de producir e inspeccionar para humanos y modelos.
Decir lo que puede suceder
Efectos, capacidades, recursos, dependencias y objetivos son entradas visibles para la admisión—no sorpresas descubiertas después del despliegue.
Menos lenguaje, límite más difícil
No hay interoperabilidad ambiental, carga de código en tiempo de ejecución, mutación sin restricciones, macros definidas por el invitado ni concurrencia ilimitada en la superficie admitida del componente.
SEGURO + RÁPIDO · DISEÑADO PARA SOFTWARE GENERADO POR IA.Esta es una directriz de confinamiento, no una afirmación de 'inhackeable'. El compilador, verificador, tiempo de ejecución, proveedores, raíces de política, custodia de claves y aislamiento del SO permanecen en la base de confianza computacional.
Seguridad en toda la computación
El límite se lleva desde la intención hasta la ejecución. Cada etapa estrecha o verifica la autoridad; no se permite que una etapa posterior invente una concesión.
Intención declarativa
Una pequeña superficie con forma de Clojure mantiene los programas legibles y excluye salidas de escape ambientales.
KIR verificado
Los tipos y efectos transitivos se convierten en una representación independiente del objetivo e inspeccionable.
Autoridad de intersección
Las concesiones solicitadas, delegadas, de política local, de recursos y de destino solo pueden restringirse.
Abordar el artefacto
Código, dependencias, política, contrato del compilador y ABI objetivo vinculan la identidad de la computación.
Vincular en el host
El tiempo de ejecución y el proveedor solo enlazan capacidades admitidas, hacen cumplir presupuestos finitos y emiten recibos.
La identidad del contenido no es autoridad.Verificación CID, firmas, revocación, política de host, comprobaciones de recursos y aislamiento OS permanecen como límites separados.
Evaluación Lisp, sin evaluación de host ambiental
Kotoba evalúa código verificado como datos direccionados por contenido. El familiar (eval request) la superficie baja al tipado :code/eval capacidad; nunca recibe texto fuente, una forma de lector, un espacio de nombres o un objeto host.
¿Qué código?
El CID selecciona una definición KIR verificada por hash y su cierre de dependencia solo CID.
¿Puede ejecutarse aquí?
La interfaz exacta, fila completa de efectos, asignación actual, combustible y profundidad de evaluación decreciente están fijados antes de la ejecución.
¿Qué regresó?
El resultado tipado se persiste como evidencia direccionada por contenido. Su hash no puede autorizar retroactivamente un efecto.
Identidad, autoridad y evidencia de resultado son tres hechos diferentes.
Contrato de máquina: lang/typed-eval.edn. Capacidad de cable del compilador: 30. La aplicación acotada sigue siendo una aplicación ordinaria de cierre de módulo cerrado.
Valores predeterminados para una pila informática orientada a IA
Estas son afirmaciones de ingeniería con su calificación adjunta. Por defecto, listo para límites, parcial y dirección son estados diferentes; ninguno se promueve silenciosamente a universal.
Compilar más rápido. Ejecutar más rápido. Mantener el límite.
Kotoba publica mediciones de inicio de compilador, ciclo de desarrollador, tiempo de ejecución nativo y dominio de carga con verificaciones de resultados exactos. Las clasificaciones de velocidad actuales permanecen retenidas hasta que sus puertas de host silencioso pasen; la admisión de seguridad nunca se elimina para ganar un tiempo.
Almacenamiento sin límite de lenguaje.
Kotobase usa identidad de contenido, lecturas de rango, historial inmutable y almacenamiento neutral al proveedor. La capacidad física, tenencia, retención, costo, replicación y presupuestos de ejecución permanecen explícitos; esto no es una afirmación de disco infinito.
Criptografía post-cuántica por defecto.
Cada nuevo límite criptográfico Kotoba debe nombrar evidencia ML-KEM o ML-DSA y rechazar una degradación solo clásica. Los Passkey existentes, transporte, implementaciones y custodia de claves permanecen como límites calificados por separado.
Autenticación presente. Autoridad denegada por defecto.
La identidad Passkey pertenece al límite de control. Una identidad verificada aún no recibe autoridad de sistema de archivos, red, almacenamiento, modelo, secreto, pago o GPU hasta que una concesión explícita y con alcance sobreviva a la política local y verificaciones del host.
Delegación flexible que solo puede estrechar.
Los ámbitos solicitados, delegados, de política local, recurso y objetivo se intersectan. La delegación puede componerse y atenuarse, pero no puede crear autoridad ambiental ni ampliar la concesión de su emisor.
Listo para Web3, neutral en cadena desde la raíz.
Un Kotoba Principal estable y un controlador Passkey son primarios. Las cuentas CAIP-10, ERC-1271 y ERC-6492 son pruebas explícitas de cuentas vinculadas; una dirección de billetera nunca se convierte silenciosamente en autoridad de almacenamiento o ejecución.
Copia cero donde el propietario lo permite; una copia donde un límite lo requiere.
Las vistas de bytes columnares mantienen vector, ByteBuffer directo y respaldo Uint8Array. La proyección Arrow puede mantener buffers sin comprimir columnares a través de la ruta autorizada del lago Kotobase. El ingreso de red, descompresión, carga GPU y actualizaciones persistentes inmutables permanecen como límites de copia nombrados.
Datos en forma de flecha. Núcleos SIMD explícitos de CPU y GPU nativos del dispositivo.
En Apple M4, una columna Arrow float32 no comprimida y no anulable retuvo un respaldo de memoria lineal WebAssembly mientras Num ejecutaba un kernel explícito v128 f32x4 sobre su segmento de valores prestados sin copias Arrow-a-SIMD; una cola escalar cubrió las filas restantes. En tres ejecuciones calificadas de la misma carga de trabajo y artefacto de escala 262,147 elementos, ese kernel SIMD completó 3.66-3.72x más rápido que Wasm escalar. Este es un resultado de kernel y host, no una afirmación general de tiempo de ejecución. La misma ruta de columna acotada también retiene un ArrayBuffer a través de sus vistas CPU, cruza el límite de propiedad GPU con una carga WebGPU medida, ejecuta en Metal y devuelve un escalar de cuatro bytes. Columnas anulables, otros tipos Arrow, eliminación de carga de memoria unificada, kernels más amplios y calificación universal CPU/GPU permanecen pendientes.
IA primero. Seguro para agentes por defecto.
Kotoba está diseñado para programas escritos u operados por agentes y bots de IA. Cuanto más fuerte es el modelo, más importantes son los efectos explícitos, recursos finitos, confinamiento de capacidades, recibos y la aplicación por parte del host.
Límites listos para AGI, no una afirmación AGI.
La arquitectura está diseñada para mantener la autoridad explícita a medida que los modelos se vuelven más capaces. Kotoba no afirma que exista AGI aquí, que los programas generados sean confiables, ni que el confinamiento elimine el compilador, tiempo de ejecución, proveedor, custodia de claves y la base de confianza del sistema operativo.
Autoridad de la máquina: lang/product-defaults.edn. Almacenamiento físico ilimitado, cero copias en todas partes, rango de velocidad universal, AGI logrado y a prueba de hackeos siguen siendo afirmaciones absolutas prohibidas.
Lo que Kotoba escrito por IA no puede pedir
| Límite | Por qué está ausente |
|---|---|
compile, load, load-file, load-string, ns-resolve, read-string, require, resolve, use
|
Los componentes no pueden fabricar código o autoridad desde el estado ambiental del proceso. Las cadenas fuente, formas lectoras, espacios de nombres cargados y objetos host compilados nunca fueron inferidos por efecto y no son parte de una definición CID. La operación admitida `(eval request)` es por lo tanto separada: selecciona KIR ya verificado por CID mediante :code/eval y es readmitida por el host. |
., .., import, new
|
El acceso arbitrario a objetos y métodos JVM/JS omite la admisión de capacidades. No relajable por despacho de concesión: la interoperabilidad nunca alcanza guard-component-ability-call, por lo que la intersección de concesiones, recibos y revocación no pueden ver la llamada. Vacío en el ABI wasm32 (no existe tal ruta); soportado en portable/trusted, donde la puerta de subconjunto es el único límite (no se reclama un sandbox VM separado allí). |
alter-var-root, atom, binding, deref, dosync, ref, reset!, set!, swap!, var, volatile!
|
El estado mutable externo es propiedad del proveedor y está mediado por capacidad/política; el estado local del componente debe usar un modelo explícitamente limitado. El invariante es AMBIENTAL, no la mutación en sí. Desde 2026-09-02 esa lectura tiene dos consecuencias en lugar de una. Una celda que escapa, persiste o cruza una función es propiedad del proveedor y permanece en la ruta :state-kit-desugar (la fila de efectos muestra :state, se requiere una concesión en la instanciación, los manejadores de capacidad son rechazados como valores almacenados). Una celda que no hace ninguna de esas cosas -- (let [a (atom 0)] (swap! a + 1) @a) -- no necesita host en absoluto: el segmento de estado local 1 la elabora en rebindings ordinarios let, por lo que nada la observa excepto el código lineal que la posee y no existe celda en tiempo de ejecución. atom / swap! / reset! / deref son por lo tanto admitidos mediante elaboración, y rechazados en el momento en que la celda escaparía. ref / dosync / volatile! / binding / var / alter-var-root / set! no tienen modelo de capacidad decidido y permanecen rechazados con fallo cerrado. |
agent, future, locking, pmap, send, send-off
|
La programación de componentes y los recursos deben permanecer controlados y limitados por el oferente. Ni los CIDs de definición ni las concesiones delegadas miden CPU o programación; el combustible es por instancia y los hilos ambientales lo evadirían. Una capacidad de generación estructurada con combustible subpresupuestado es diseñable pero no decidida; aún no hay camino de ampliación. |
defmacro
|
La superficie del componente seguro debe ser inspeccionable estáticamente antes de la ejecución. Inrelajable: la expansión ejecuta código dentro del compilador (tiempo de compilación), y los hashes CID de definición post-desugar KIR tipado, por lo que macros sin límite se ejecutan temprano y hacen que la identidad de la fuente no sea revisable. defdesugar (desazucar puro acotado) sigue siendo la alternativa admitida. |
catch, throw, try
|
El throw/try/catch ambiental es un flujo de control no local no rastreado: sale de ámbitos que la fila de efectos inferida nunca menciona y omite obligaciones de deshacer (la retracción de facetas del espacio de datos no tiene deshacer verificado aún). La prohibición es sobre la forma ambiental. Desde 2026-09-02 la capacidad de abortar tipada admite las cabezas por elaboración: el efecto aparece en la fila inferida como :abort y la función se reduce a [:result T E], así que la forma ambiental nunca existe después de la elaboración. El corte 2 (2026-09-02) hizo que :abort se propague a través de llamadas y normalizó A un operando o prueba abortante en una vinculación let; ninguno amplía el invariante, porque un aborto propagado está en la fila del llamador y uno normalizado A es la misma elaboración en una posición diferente. Donde la precondición de deshacer importaría, el aborto sigue rechazado -- para una LLAMADA ahora así como para un throw. |
Estas son restricciones de seguridad nombradas en lang/surface-status.edn, no características faltantes en una hoja de ruta.
Prueba, con el límite adjunto
Kotoba separa la evidencia de implementación de la tracción del mercado y mantiene el riesgo residual junto a cada afirmación de seguridad.
núcleos 33
Uso interno de producción
La pila más amplia Kotoba ejecuta 33 núcleos de inferencia internamente. Esto prueba que el equipo opera su propia pila; no es tracción de cliente, adopción pagada o ingresos.
reclamaciones 8
Los límites son legibles por máquina
Las afirmaciones de seguridad nombran su base de computación confiable, evidencia negativa y riesgo residual en lugar de colapsar en un eslogan de 'inhackeable'.
denegar por defecto
Sin concesión, sin efecto del host
Una política vacía no concede autoridad de sistema de archivos, red, proceso, reloj, modelo o secreto. Los proveedores también deben validar el alcance concreto de recursos.
El uso interno en producción es solo evidencia de dogfooding. No implica clientes externos, pilotos pagados o ingresos.
Cinco benchmarks. Cinco preguntas diferentes.
El inicio del compilador pregunta qué tan rápido una fuente diminuta se convierte en un artefacto. La escala de construcción pregunta qué sucede con ese número cuando la fuente deja de ser diminuta—y si el artefacto aún responde. El bucle de desarrollador separa resolución, verificación, compilaciones y primer resultado. El tiempo de ejecución nativo pregunta qué tan rápido corre el código ya construido. El conjunto de dominio de carga de trabajo pregunta cómo se comportan cadenas, colecciones, asignación, E/S, concurrencia y una pequeña aplicación real. Los resultados mantienen las cinco preguntas—y su estado de evidencia—separados.
cadenas de herramientas 4, 21 ejecuciones cada una
Kotoba 40.998 ms · Rust 126.422 ms · C 146.324 ms · JVM 961.248 ms mediana.
21 muestras rotativas en frío del proceso · carga1 30.79 → 39.79 · requerido ≤ 1 · 2026-08-29 · Apple M4
Cargas de trabajo 6 × comparadores 5
Amu nativo se prueba contra Rust, Clang / C11, Zig, Go c-shared, Swift a través de un límite común de llamada nativa.
pares comparador/carga 30/30 · respuestas exactas verificadas
19 de 30 pares
Amu nativo gana 19 de los 30 pares comparador/carga de trabajo por al menos 5%, separado de la propagación propia de los brazos. La afirmación de más rápido acotado necesita cada par, por lo que permanece sin calificar — el conteo es la mitad informativa.
Al menos 2 de esos pares no pueden ganarse en absoluto. En aritmética estrecha, amu, Apple clang -O3 y rustc -O3 compilan el kernel a la misma secuencia de instrucciones 61 — clang y rustc idénticos en bytes, amu difiere solo en números de registro. No existe un margen 5% sobre código idéntico, por lo que la afirmación acotada es inalcanzable en lugar de simplemente incumplida.
Mediana de 5 ejecuciones calificadas por host; la puntuación varió 19–20 y 19 de los 30 pares calificaron en cada una. Una sola muestra ruidosa puede descalificar varios pares a la vez, por lo que una puntuación de una ejecución no es precisa para un par.
CPU ocupada 0.090 → 0.069 → 0.076 · requerido ≤ 0.10 · 2026-09-07
Rutas de cadena de herramientas 11
La resolución de dependencias, verificación, compilaciones limpias y sin cambios, y el primer resultado en frío del proceso se registran por separado.
muestras 7 por etapa medida · carga1 20.84 → 24.49 · requerido ≤ 1
tamaños de fuente 8
El mismo programa de una función a 2048, construido por cada cadena de herramientas en el host y luego ejecutado. El binario liberado tiene el costo de inicio en frío más bajo aquí y una corrección límite superior sobre funciones 128.
artefactos verificados después de que el reloj se detiene · carga1 2.73 → 2.73 · requerido ≤ 1 · 2026-08-31
dominios 6 × rutas de tiempo de ejecución 6
Cadenas, colecciones, asignación, E/S de archivos, concurrencia de cuatro trabajadores y un núcleo de aplicación de política de admisión de solicitudes son verificados en cuanto a corrección.
muestras 7 en carriles tanto de proceso en frío como amortizados · carga1 13.87 → 12.38 · ranking retenido
Tiempo de compilación a medida que la fuente crece
Los benchmarks anteriores construyen un programa lo suficientemente pequeño para caber en una pantalla, que mide qué tan rápido inicia una cadena de herramientas. Dice poco sobre el número que un desarrollador realmente espera, que es la pendiente. Este quinto el benchmark genera el mismo programa en tamaños crecientes — K funciones independientes de cuatro operaciones y un punto de entrada que los llama a todos — y lo construye a través de cada cadena de herramientas en el host, en orden rotativo.
Luego ejecuta lo que produjo cada cadena de herramientas, después de que el reloj se detuvo. Esa verificación no es decoración. La forma más rápida de emitir un artefacto es emitir uno roto, así que un carril que dejó de funcionar de otro modo publicaría sus mejores números exactamente donde dejó de funcionar.
Ambos ejes son logarítmicos: las fuentes abarcan tres órdenes de magnitud y también los tiempos. Una línea termina en un punto donde terminó la ejecución, en una cruz donde ese carril emitió un artefacto que no es el programa, y en una barra donde la cadena de herramientas se negó a compilar. Esos tres no son el mismo evento y las dos fallas a continuación no son la misma falla.
| Cadena de herramientas / objetivo | K=1 | K=32 | K=128 | K=129 | K=512 | K=1023 | K=1024 | K=2048 |
|---|---|---|---|---|---|---|---|---|
| Kotoba · CLI lanzado · WebAssembly | 11.753 ms | 35.84 ms | 111.538 ms | artefacto inválido | artefacto inválido | artefacto inválido | compilación fallida | compilación fallida |
| Kotoba / Amu · WebAssembly | 733.255 ms | 825.418 ms | 1123.04 ms | 1123.847 ms | 3380.63 ms | 9242.463 ms | compilación fallida | compilación fallida |
| Kotoba / Amu · Nativo aarch64-macos | 962.198 ms | 1509.84 ms | 2973.249 ms | 3000.243 ms | 10601.87 ms | 23725.327 ms | compilación fallida | compilación fallida |
| 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 | sin cadena de herramientas | sin cadena de herramientas | sin cadena de herramientas | sin cadena de herramientas | sin cadena de herramientas | sin cadena de herramientas | sin cadena de herramientas | sin cadena de herramientas |
| 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 · clase 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 en judahnoMac-mini.local (Apple M4). K es el número de funciones generadas; la fuente Kotoba va de 9 a 14338 líneas. Los objetivos, ABIs, niveles de optimización y contratos de tiempo de ejecución difieren entre carriles, así que esto pregunta sobre latencia de retroalimentación del desarrollador, no trabajo equivalente. La puerta de carga del host falló (load1 2.73–2.73, requerido ≤ 1), por lo que estas son observaciones de esta ejecución y no cifras portables. Debido a que los carriles están entrelazados, el orden se califica por separado.
Qué ordenamientos sobreviven la prueba de ruido
Una proporción no es una clasificación. perfgate rechaza cualquier orden cuyo intervalo caiga dentro de la propia extensión de los dos brazos, por grande que parezca la proporción, y rechaza un brazo con muy pocas muestras o demasiado ruido. Se ejecuta aquí con su propia política predeterminada, sin relajación — un umbral relajado para permitir que esto se ejecute sería un benchmark que mide sus propios umbrales. Debido a que los carriles están entrelazados en un host, un hueco que sobrevive esta prueba sobrevive a que el host esté ocupado.
| Tamaño | Comparado con | ¿Kotoba más rápido? | Brecha vs dispersión combinada | ¿Por qué no, si no |
|---|---|---|---|---|
| K=1 | C / Clang · Host nativo | sí, calificado | 17.1 ms vs 1.0 ms | — |
| K=1 | JVM / javac · clase JVM | sí, calificado | 160.8 ms vs 5.4 ms | — |
| K=1 | Rust / rustc · Host nativo | sí, calificado | 44.2 ms vs 0.6 ms | — |
| K=1 | Rust / rustc · WebAssembly | sí, calificado | 27.1 ms vs 0.5 ms | — |
| K=32 | C / Clang · Host nativo | no | 5.3 ms vs 1.0 ms | mejora-por-debajo-del-umbral |
| K=32 | JVM / javac · clase JVM | sí, calificado | 161.9 ms vs 1.2 ms | — |
| K=32 | Rust / rustc · Host nativo | sí, calificado | 26.7 ms vs 0.7 ms | — |
| K=32 | Rust / rustc · WebAssembly | sí, calificado | 9.8 ms vs 0.6 ms | — |
| K=128 | C / Clang · Host nativo | no | 75.8 ms vs 1.2 ms | mejora-por-debajo-del-umbral |
| K=128 | JVM / javac · clase JVM | sí, calificado | 126.2 ms vs 2.2 ms | — |
| K=128 | Rust / rustc · Host nativo | no | 29.3 ms vs 1.4 ms | mejora-por-debajo-del-umbral |
| K=128 | Rust / rustc · WebAssembly | no | 45.8 ms vs 1.1 ms | mejora-por-debajo-del-umbral |
mejora-por-debajo-del-umbral significa que el carril Kotoba no fue más rápido en ese tamaño en absoluto. La ventaja es real y calificada en inicio en frío, y desaparece frente a C por K=32 y frente a Rust por K=128. Ese cruce es el resultado, por lo que se muestra en lugar de resumirse.
Dos fallos que no son el mismo fallo
Tres carriles Kotoba dejaron de funcionar en esta ejecución, y publicarlos como uno la fila habría estado equivocada. Una es un defecto. Las otras dos están declaradas límites aplicados exactamente como se especifica, y reportando esos como defectos significaría medir los límites en lugar del compilador.
| Observación | Leyendo |
|---|---|
| El CLI kotoba lanzado emite un módulo que no compilará más de 128 funciones | Un defecto, y la razón para validar dentro de un arnés. En K=129 una llamada debe llevar el índice de función 128, el primer valor que necesita dos bytes LEB128, y el emisor escribe uno. Los bytes indican que no es un codificador faltante sino uno no usado: local.set 128 se escribe 80 01, y call 128 una instrucción después se escribe 80. El conteo de operandos truncados es exactamente K menos 128. El compilador actual no lo tiene — Amu construye K=129 correctamente, y la corrección ha estado en la rama predeterminada de su emisor desde antes de que esta versión fuera etiquetada. |
| Cada carril Kotoba atrapa en K=512 cuando se construye con configuraciones predeterminadas | No es un defecto. Un módulo Kotoba lleva un presupuesto declarado de combustible de llamadas y el valor predeterminado del compilador es 512 llamadas, que esta carga de trabajo supera en K=512 donde el punto de entrada llama 512 hojas. El arnés declara 1,048,576 unidades explícitamente y registra que lo hizo. C, Rust y Java no tienen un límite equivalente para elevar. |
| Amu rechaza el módulo de plano una vez que tendría más de 1,024 funciones | Tampoco es un defecto, y es lo opuesto a la primera fila. max-functions es un límite de admisión declarado, por lo que el compilador se detiene con kotoba.error/subset-reject y nombra lo que rechazó, en lugar de emitir algo que no se cargará. Un techo ruidoso y uno silencioso son resultados muy diferentes, y solo un arnés que ejecuta el artefacto los distingue. Medido 2026-09-07: este es el techo de todo el programa, no de un módulo — max-project-functions también es 1,024 y se verifica contra el proyecto enlazado, por lo que ninguna disposición de módulos compila un programa de 2,048 funciones hoy. |
Lo que esto establece
| Pregunta | Respuesta de esta ejecución |
|---|---|
| ¿Qué tan rápido es una compilación fría Kotoba de un módulo pequeño? | El CLI liberado construye K=1 en 11.753 ms en proceso frío, artefacto ejecutado y respuesta verificada — el primer resultado más rápido de cualquier carril medido aquí. |
| ¿Qué tan grande puede ser un módulo que el binario liberado puede construir? | Hasta 128 funciones. Más allá no es más lento, es incorrecto, y este arnés reporta eso como un carril fallido en lugar de uno rápido. |
| ¿El tiempo de compilación se mantiene competitivo a medida que crece la fuente? | A través de K=128 el CLI liberado se mide contra Rust y C en la tabla anterior. Más allá de ese punto, el único compilador Kotoba que aún emite un módulo correcto es Amu, que se ejecuta en nbb en lugar de como un binario liberado, y es aproximadamente un orden de magnitud más lento en cada tamaño medido — por lo que a tamaños grandes la velocidad de compilación no es actualmente una fortaleza Kotoba, y esta página no va a afirmar lo contrario. |
| ¿Qué tan grande se ha construido una fuente de extremo a extremo? | K=1023 a través de Amu — 7163 líneas de Kotoba, artefacto ejecutado y respuesta verificada. Eso es una función menos que el techo declarado 1,024, y el siguiente tamaño es rechazado en lugar de mal construido. |
| ¿Es rápido el código emitido? | Fuera de alcance aquí — esto mide la construcción, no la ejecución. La suite de tiempo de ejecución nativo arriba responde esa pregunta. |
Conclusión: En el tamaño más pequeño, el binario lanzado es más rápido que todos los comparadores aquí por un margen que sobrevive la prueba de ruido, y tiene un techo duro de corrección en 128 funciones. El compilador sin ese techo es aproximadamente un orden de magnitud más lento en todos los tamaños medido. Ambos hechos provienen de la misma ejecución, y el arnés que los encontró es público, para que la ejecución pueda ser cuestionada.
Cuánto tarda realmente cada carga de trabajo nativa
La cuadrícula a continuación informa el margen entre dos brazos. Ese es el número reglas perfgate activadas, pero un porcentaje por sí solo no dice si un la carga de trabajo se ejecuta en cinco milisegundos o quinientos, y oculta el diferencia entre un par disputado y uno irrelevante. Estos paneles son las medianas de las que se calculan esos márgenes. Amu nativo es el carril coloreado en cada panel — incluyendo los paneles donde no es primero. Cada panel es escalado a su brazo más lento, porque la pregunta que responde un panel es quién es más rápido en esa carga de trabajo.
Aritmética estrecha
Presión amplia de registros
Presión profunda de derrame
Preservación de llamadas
Flujo de control de rama + llamada
Bucle de llamada de retroceso
Mediana de milisegundos sobre 5 ejecuciones calificadas por host; menor es más rápido. Cada brazo devolvió la misma respuesta verificada independientemente, y la mediana candidata es un valor por carga de trabajo — la suite rota cada par de motores en orden ABBA/BAAB, así que el mismo artefacto Amu se mide una vez por carga de trabajo y luego se compara con cada brazo a su turno. A diferencia de los otros cuatro benchmarks en esta página, la puerta de host silencioso de este PASÓ (carga-calificada del host), por lo que estas son cifras para este host y no solo observaciones. La afirmación de más rápido acotado aún necesita todos los 30 pares, que es para lo que sirve la cuadrícula abajo.
Cada par en tiempo de ejecución, victoria o derrota
La reclamación acotada es todo o nada, por lo que un solo par no calificado la hace falsa. Publicar solo ese veredicto ocultaría qué pares están en disputa, así que todo el la cuadrícula está aquí. Una celda es la mejora media de Amu nativo sobre ese comparador en esa carga de trabajo; positivo significa que Amu es más rápido, y una marca de verificación señala los pares que perfgate claro — al menos 5% y separado de la propia dispersión de los brazos.
| Carga de trabajo | Rust | Clang / C11 | Zig | Go c-shared | Swift |
|---|---|---|---|---|---|
| Aritmética estrecha | +0.4% | -0.6% | +20.1% | +84.7% | -0.6% |
| Presión amplia de registros | +6.5% | +10.9% | +16.9% | +86.0% | +87.1% |
| Presión profunda de derrame | +4.2% | +9.3% | +5.1% | +82.2% | +92.6% |
| Preservación de llamadas | -1.0% | -0.3% | +42.9% | +85.2% | +29.6% |
| Flujo de control de rama + llamada | -2.6% | -7.1% | +43.8% | +85.2% | +25.1% |
| Bucle de llamada de retroceso | +0.8% | -0.1% | +32.4% | +17.2% | +24.8% |
Cada celda es una barra que crece desde una línea central: a la derecha de ella Amu nativo es más rápido, a la izquierda más lento. Las dos direcciones están escaladas por separado — las victorias llegan a +93% y las pérdidas solo a −7%, por lo que una escala compartida aplanaría cada par disputado en la misma franja invisible. El signo también se lleva por el lado de la línea y por el número con signo, por lo que ninguna lectura de esta cuadrícula depende de distinguir dos colores.
19 de 30 pares calificados (mediana de 5; 19 en cada ejecución) · candidato 42f092ea5b61 · Apple M4, 10 CPUs lógicos, 16 GiB
Entrega de optimización después de la ejecución publicada
El punto de referencia fechado arriba permanece inmutable. Las nuevas implementaciones se listan por separado hasta que la suite de artefactos iguales se ejecute de nuevo y pase sus puertas de calificación.
| Superficie | Entregado | Límite de evidencia |
|---|---|---|
| Vectores nativos / asignación | Los literales vectoriales acotados no escapantes están probados para no escapar y reemplazados por escalares en x86-64 y AArch64. | Pruebas de backend 211 / 2,442 aserciones; los vectores que escapan retienen la ABI del host verificado. Aún no hay temporización clasificada nueva. |
| SIMD de cadenas | La igualdad verificada POSIX usa comparación explícita NEON o SSE2 de 16 bytes después de la validación de manejador y UTF-8 canónica. | Ensamblado optimizado y ambos vectores semánticos ISA nativos verificados. Windows permanece fijado por separado; clasificación de latencia pendiente. |
| Capacidad de E/S asíncrona | El uso eventual confinado a raíz de lectura/escritura/listado/existencia/eliminación usa CompletableFuture en JVM y fs.promises en Node. | Las pruebas reales de sistema de archivos JVM y Node pasan. El benchmark público independiente Wasm aún no tiene enlace de host admitido, por lo que su celda de E/S sigue siendo N/A. |
| Concurrencia estructurada | Un ámbito hijo 32 acotado con fallo rápido une, cancela hermanos y previene la fuga de vida del hijo como estado canónico Kotoba. | Aserciones de paridad 996 a través de la autoridad .kotoba y la ruta de carga CLJC. Esto es semántica estructurada de tiempo de vida, no un resultado de rendimiento de hilo de SO. |
| CLI Kotoba | kotoba test/build consume el nuevo pin del compilador; kotoba compile emite x86-64 sellado y KEXE AArch64 directamente. | Ciclo de vida CLI público y artefacto vectorial AArch64 verificado. Native --run sigue rechazado hasta que se conecte un recibo medido del cargador. |
Inicio del compilador, cuatro cadenas de herramientas
Tiempo en pared en frío del proceso para una fuente diminuta, en milisegundos; menor es más rápido. 21 muestras rotativas por cadena de herramientas en Apple M4. La puerta de carga del host FALLÓ en esta ejecución, por lo que estas son observaciones de una máquina, no un ranking.
| Cadena de herramientas | Salida | Mediana | p95 | Tiempo transcurrido 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 | clase JVM | 961.248 ms | 2223.49 ms | 23.446× Kotoba |
KOTOBA 0.7.3 · RUSTC 1.97.1 · versión Homebrew clang 22.1.7 · javac 24.0.2. Kotoba, Rust y C emiten Wasm; javac emite un archivo de clase. Diferentes objetivos y trabajo del compilador hacen de esta una observación inicial, no un ranking universal. La puerta de carga del host registrada falló, por lo que la tabla no es un ranking de velocidad calificado.
| Cadena de herramientas / objetivo | Resolver | Verificar | Compilación limpia | Compilación sin cambios | Iniciar + ejecutar | Compilación limpia + primer resultado |
|---|---|---|---|---|---|---|
| Kotoba · WebAssembly | N/A | 231.75 ms | 62.906 ms | 42.332 ms | 57.253 ms | 142.644 ms |
| Rust / Cargo · macOS arm64 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 · clase 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 artefacto emitido produjo 42 en un proceso nuevo. Los contratos de destino y tiempo de ejecución difieren; N/A nunca es cero. La puerta de carga del host falló, por lo que estas son observaciones reproducibles en lugar de una clasificación de velocidad entre lenguajes.
Seis dominios, lado a lado
Cada panel se escala a su propio carril más lento, porque la pregunta de un panel respuestas es quién es más rápido en ese dominio, no cómo se comparan los dominios entre sí otro. El carril de Kotoba es el coloreado en cada panel — incluyendo el paneles donde es el último. Su artefacto Wasm independiente se ejecuta a través de un Node host y paga ese inicio en cada muestra en frío de proceso, mientras que Rust, C y Go ejecutar como binarios nativos; donde el objetivo no tiene sistema de archivos ambiental ni hilo contrato en absoluto, el carril está ausente en lugar de cero.
Cadena
Colección
Asignación
E/S
Concurrencia
Aplicación real
Medianas en proceso frío en milisegundos; menor es más rápido. La puerta de carga del host falló en esta ejecución, por lo que estos paneles son observaciones y no un ranking, y el carril amortizado abajo cuenta otra historia diferente.
| Ruta de ejecución | Cadena | Colección | Asignación | E/S de archivos | Concurrencia | Aplicación 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 muestra devolvió la suma de verificación de referencia exacta. Kotoba usa su Wasm emitido y ABI tipado declarado; su objetivo independiente no tiene sistema de archivos ambiental ni contrato de hilo, por lo que esas celdas se consideran N/A. La puerta de carga del host registrada falló, por lo que las medianas son observaciones, no una clasificación.
| Ruta de ejecución | Cadena | Colección | Asignación | E/S de archivos | Concurrencia | Aplicación 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 más grande en proceso se divide por su multiplicador de carga de trabajo declarado. Esto amortigua el inicio pero no elimina completamente el costo de proceso, VM o instanciación Wasm, por lo que no se etiqueta como un resultado perfectamente calentado en estado estable. Las cadenas puras de mapa inc/dec de Kotoba se fusionan en reduce sin vectores intermedios; las devoluciones de llamada fuera de ese subconjunto probado mantienen la materialización ansiosa.
| Pregunta | Implementaciones comparadas | Conclusión actual |
|---|---|---|
| Compilación + ejecución Tiny Wasm | Kotoba, Rust, C y cadenas de herramientas JVM | Cuatro medianas en frío de proceso publicadas arriba; solo Kotoba/Rust/C comparten el objetivo Wasm, y no se reclama un rango general de velocidad de compilación |
| Bucle de desarrollo de proyecto pequeño | Kotoba, Rust, C, Zig, TinyGo, Go, Swift, JVM, AssemblyScript, .NET IL y .NET Native AOT | Se publican siete muestras por etapa disponible; las diferencias de objetivo y una puerta de carga del host fallida prohíben un ranking universal |
| Ejecución nativa en estado estable | Amu nativo vs Rust, Clang / C11, Zig, Go c-shared, Swift | Todas las celdas de comparación semántica 30 están completas; ranking de velocidad retenido porque la puerta de host silencioso falló |
| Cadenas, colecciones, asignación, E/S, concurrencia y aplicación real | Rutas de tiempo de ejecución Kotoba, Rust, C, Go, JVM y JavaScript | Se publican sumas de verificación exactas y muestras amortizadas en frío del proceso; la E/S y los hilos Kotoba independientes no aplican, mientras que su aplicación pura de admisión de solicitudes está medida; la puerta de carga fallida retiene la clasificación |
Lo que cubre la suite nativa
Cada implementación devuelve una respuesta conocida verificada de forma independiente. La suite rota cada par de motores en orden ABBA/BAAB y mide después de cargar, mapear y buscar símbolos.
| Carga de trabajo | Lo que enfatiza | Estado de la evidencia |
|---|---|---|
| Aritmética estrecha | Resultado exacto verificado; tiempo no calificado | |
| Presión amplia de registros | Resultado exacto verificado; tiempo no calificado | |
| Presión profunda de derrame | Resultado exacto verificado; tiempo no calificado | |
| Preservación de llamadas | Resultado exacto verificado; tiempo no calificado | |
| Flujo de control de rama + llamada | Resultado exacto verificado; tiempo no calificado | |
| Bucle de llamada de retroceso | Resultado exacto verificado; tiempo no calificado |
Dónde vive cada benchmark
Cada número arriba proviene de un arnés público y un informe comprometido, así que un la ejecución puede repetirse y se puede discrepar con una afirmación. Las rutas en el repositorio en esta tabla se verifica contra el árbol de trabajo cuando se genera esta página: un arnés que falla la compilación en lugar de enviar un enlace muerto.
La puerta por la que pasa cada orden en esta página es kotoba-lang/perfgate, ejecutado con su propia política predeterminada no relajada. Un umbral aflojado para permitir un ejecutar sería un punto de referencia que mide sus propios umbrales.
Conclusión: Los artefactos, resultados exactos y muestras son reales en los cinco benchmarks. Tres de ellos — inicio del compilador, el ciclo del desarrollador y los dominios de carga de trabajo — fallaron su puerta de host silencioso, por lo que no clasifican y se publican como observaciones. La suite de tiempo de ejecución nativo pasó su puerta y gana 19 de sus 30 pares, lejos de la reclamación de cada par que necesitaría. El escalado de construcción califica su orden de inicio en frío contra cada comparador en el host y encuentra un techo de corrección en la misma ejecución. No se reclama ningún rango universal de velocidad en esta página, y ninguna de estas ejecuciones lo autoriza.
Afirmaciones con sus límites adjuntos
Estas afirmaciones se generan a partir de lang/safety-claims.edn. Cada uno mantiene visible su base de computación confiable y riesgo residual, porque un lema de seguridad sin un límite es solo marketing.
Los componentes admitidos no pueden acceder a memoria en tiempo de ejecución/nativa y las operaciones de memoria de componentes están acotadas o atrapan.
Base de computación confiable
lector acotado · admisión frontend · verificador de artefactos · tiempo de ejecución Wasm/nativo
Riesgo residual
- las vulnerabilidades del motor de ejecución permanecen en el TCB
- los cargadores nativos requieren un segundo límite de aislamiento del SO
Cada efecto de componente transitivo se declara y admite antes de la emisión, incluidos los efectos usados por proveedores escritos en Kotoba.
Base de computación confiable
inferencia de efectos · catálogo de capacidades · gráfico de llamadas frontend
Riesgo residual
- kotoba y la paridad de gramática/efecto del compilador deben compararse continuamente
Una capacidad no concedida está ausente o no vinculada y no puede alcanzar un proveedor o manejador nativo.
Base de computación confiable
intersección de políticas · emisión de importación de compilador · vinculación de importación de licitación · guardia del host
Riesgo residual
- el proveedor y las implementaciones nativas deben validar independientemente el alcance de recursos
- las concesiones efectivas de producción deben prohibir el alcance comodín
La misma fuente admitida, objetivo, política y bloqueo producen el mismo resultado puro observable y bytes de artefacto.
Base de computación confiable
lector canónico · reducción determinista · cadena de herramientas fijada
Riesgo residual
- los efectos del host son deterministas solo donde su contrato de capacidad lo indica
Fuente, admisión, ejecución, memoria y salida usan límites finitos explícitos.
Base de computación confiable
límites de admisión · medidor de combustible · cuota de tiempo de ejecución · tiempo de espera del supervisor
Riesgo residual
- los supervisores de plataforma aún no tienen evidencia igual de aislamiento en producción
La admisión de lanzamiento vincula la identidad del artefacto, firmante confiable, validez y evidencia reproducible.
Base de computación confiable
verificador de firmas · configuración de firmante confiable · reloj · conjunto de revocación
Riesgo residual
- custodia de claves y distribución externa de revocación permanecen como TCB operativo
Un componente portátil compartido tiene aceptación, resultado y traza de efecto iguales en backends calificados.
Base de computación confiable
manifiesto de conformidad compartido · adaptadores de backend · corredor de comparación
Riesgo residual
- las características solo para compilador no son portables y deben ser rechazadas por perfiles portables
Una importación de componente alcanza a su proveedor o manejador nativo solo con un alcance concreto de recursos post-intersección y emite un recibo.
Base de computación confiable
intersección de capacidades · guardia de host · manejador de proveedor · sumidero de recibos
Riesgo residual
- Las verificaciones específicas de proveedor para ruta, redirección, enlace simbólico y inquilino requieren kits Q5
Calificación P1, a partir de 2026-07-18.
Vinculación de versión
Un perfil de idioma y una versión de implementación son separados hasta que un sobre firmado los vincula.
Perfil 6
contrato de paquete 1
v0.7.0
vinculación de perfil: verificado
LANZADO
:docs/release-bound-profile
Kotoba v0.7.0 para darwin-arm64 es la implementación pública vinculada al perfil de idioma 6 y al contrato de paquete 1. Su sobre firmado verifica el árbol fuente, el resumen del artefacto y el resultado de conformidad de prueba 536 / afirmación 8,580. Otras plataformas permanecen sin vincular.
Leer la evidencia de lanzamiento generadaComenzar en sesenta segundos
Instalar y auto-verificar
brew tap kotoba-lang/kotoba
brew trust kotoba-lang/kotoba
brew install kotoba
kotoba selfhost check --jsonAceptar una respuesta válida con una lista de problemas vacía.
Un primer programa
(defn main []
(+ 40 2))Este programa no solicita importaciones del host; el módulo emitido no tiene importaciones.
Aprender, probar, luego profundizar
Un camino conectado desde el primer programa hasta contratos de lenguaje, bibliotecas, evidencia y superficies de despliegue.
Documentos por intención
Comience con la instalación, aprenda el lenguaje admitido o inspeccione la semántica normativa y los datos de conformidad.
Mapa de documentación abiertoUna fuente, una respuesta
El ejemplo a continuación es la fuente exacta compilada en la demostración del navegador, no una reimplementación en JavaScript.
Leer el ejemploEjecutar en esta página
Cargar un artefacto WebAssembly de mismo origen y ligado a digest y llamar a su función principal exportada Kotoba.
Juego abiertoBibliotecas y contratos
Explore nombres centrales limitados, bibliotecas fundamentales, reglas de paquetes y su límite actual de madurez.
Explorar bibliotecasUn pequeño programa Kotoba, ejecutándose realmente
Amu compila esta fuente pura Kotoba al perfil wasm32-browser. El artefacto registrado no tiene importaciones y devuelve 42.
;; W1 pure representative: ordinary Clojure-shaped values/functions only.
(ns examples.w1-pure)
(defn double [n]
(+ n n))
(defn main []
(double 21))
Autoridad destacada: kotoba-lang/gramática → kotoba.grammar.highlight/tokenize → HTML en tiempo de compilación. Contrato de alcance del editor: source.kotoba. Dependencia del resaltador del navegador: ninguna. Inspeccionar dependencias
Compilar localmente: kotoba compile double-21.kotoba --target wasm32-browser --output double-21.wasm
Ejecutar el artefacto verificado
El navegador descarga 344 bytes, verifica SHA-256, rechaza todas las importaciones, instancia el módulo y llama a main().
Resultado esperado:
42
Listo. No se ha ejecutado código aún.
Esto ejecuta un ejemplo precompilado e inmutable. Editar código arbitrario en el navegador aún no es una superficie de compilador enviada.
Demos interactivas: solar-helix (renderizado WebGPU impulsado por invitado) · kami-survivors (un juego .kotoba) · gpu-clear (humo WebGPU). Hospedado en la superficie wasm-webcomponent GitHub Pages; la disponibilidad depende del soporte WebGPU/WebAssembly del navegador.
Bibliotecas, sin ocultar el límite del paquete
Las bibliotecas Kotoba son grafos direccionados por contenido. Los nombres y los repositorios GitHub ayudan a las personas a descubrirlas; las definiciones y los CIDs de lanzamiento firmados dicen exactamente qué son.
Referencia de símbolo generada
Busque los nombres admitidos por el contrato de biblioteca estándar limitado actual.
Explorar símbolos centralesDatos, efectos, E/S, herramientas
Comenzar con coll, spec, json, text, wit, async, time, fs, http, test, fmt, lint y contratos LSP.
Explorar el mapa de la bibliotecaDependencias direccionadas por contenido
Inspeccionar CIDs de dependencia exactos, capas de identidad, procedencia GitHub y el límite actual de publicación.
Abrir el catálogo de bibliotecas y flujo de publicaciónExplorar toda la organización por etiqueta
Hay 2,215 repositorios públicos en el kotoba-lang organización. Cada etiqueta abajo es el tema GitHub de el mismo nombre, así que el filtro del sitio y los temas de la organización son un vocabulario en lugar de dos que se desvían. Elige uno para abrir el catálogo ya filtrado.
Navegar y filtrar todos los repositorios 2,215
Un repositorio no es un paquete publicado. Exactamente 1 biblioteca se publica a través del registro direccionado por contenido; el resto de esta lista es descubrimiento. Las etiquetas de madurez del repositorio no implican estabilidad de API 1.0, adopción amplia o SLOs de producción, y 255 repositorios no coinciden con ninguna regla de dominio y se muestran sin etiqueta en lugar de asignar la etiqueta más cercana.
Buscar en la referencia verificada
Buscar comandos, nombres de biblioteca estándar, diagnósticos y estado de lanzamiento. El índice se genera a partir de autoridades de máquina y permanece en esta página.
Intentar: compilar, opción-alguna, docs/enlace-faltante
Vinculación de versión
Kotoba v0.7.0 para darwin-arm64 es la implementación pública vinculada al perfil de idioma 6 y al contrato de paquete 1. Su sobre firmado verifica el árbol fuente, el resumen del artefacto y el resultado de conformidad de prueba 536 / afirmación 8,580. Otras plataformas permanecen sin vincular.
Referencia abierta
kotoba id
Crear un plan de inscripción principal Kotoba neutral a cadena controlado por una clave de acceso. Las cuentas inteligentes son enlaces explícitos CAIP-10; ninguna cadena o proveedor es la raíz de identidad.
Referencia abierta
kotoba compile
Compilar fuente de la familia Kotoba a un artefacto objetivo. Web .kotoba usa KIR verificado y el backend restringido kotoba-script; .cljs sigue siendo ClojureScript.
Referencia abierta
kotoba check
Valida fuente Kotoba, contratos o metadatos del paquete sin ejecutarlo. Adaptador del compilador: admisión frontend + --profile pure-product (T9.2).
Referencia abierta
kotoba graph
Consultar y transaccionar la tienda gráfica del lenguaje (kgraph) con operaciones en forma Datomic.
Referencia abierta
kotoba git
Exponga las operaciones del repositorio Kotoba como datos, no como comportamiento específico de shell.
Referencia abierta
kotoba rad
Ejecute flujos de trabajo de desarrollo rápido de aplicaciones sobre paquetes Kotoba.
Referencia abierta
kotoba build
Construya un proyecto Kotoba en su artefacto objetivo verificado. Este es el comando directo del ciclo de vida del proyecto; rad build sigue siendo una ortografía compatible.
Referencia abierta
kotoba test
Verifique y ejecute las pruebas admitidas para un proyecto Kotoba. Este es el comando directo del ciclo de vida del proyecto; rad test sigue siendo una ortografía de compatibilidad.
Referencia abierta
kotoba deploy
Planificar y aplicar el estado deseado del paquete a un recibo local o a un objetivo residente de flota murakumo.
Referencia abierta
kotoba library
Inspeccionar y publicar un espacio de nombres de biblioteca direccionado por contenido a través de la base de código Kotoba existente y la ruta de publicación IPNS.
Referencia abierta
kotoba hinshitsu
Ejecutar verificaciones de calidad de software (evidencia, puertas, cobertura, regresión visual) como datos.
Referencia abiertaseleccionar-claves
Nombre público acotado de la biblioteca estándar central.
Referencia abiertaancla de cierre binario stdlib
Nombre público acotado de la biblioteca estándar central.
Referencia abiertadesenvolver-error
Nombre público acotado de la biblioteca estándar central.
Referencia abierta:comando/desconocido
El comando solicitado no está en el contrato público de CLI. Use un comando generado desde lang/cli.edn.
Referencia abierta:contract/invalid
El contrato CLI falló la validación estructural. Inspeccione la colección estructurada :errors; no despache el comando.
Referencia abierta:versión/no soportado
La versión solicitada del idioma o contrato de paquete es desconocida. Seleccione una versión listada bajo :supported en lang/version-policy.edn.
Referencia abierta:versión/eliminado
La versión de contrato solicitada ha sido eliminada. Migre a la versión activa antes de compilar o ejecutar.
Referencia abierta:versión/obsolescencia-expirada
La ventana de compatibilidad para una versión obsoleta ha expirado. Aplica la migración nombrada por la política de versiones.
Referencia abierta:release/invalid-semver
Un identificador de versión no es SemVer estricto. Use MAYOR.MENOR.PARCHE con un sufijo opcional válido de pre-lanzamiento o compilación.
Referencia abierta:docs/no-release-bound-profile
No hay evidencia de implementación publicada que vincule el perfil de lenguaje activo. Mantenga el valor predeterminado público bloqueado hasta que un sobre de lanzamiento firmado vincule la implementación y el perfil.
Referencia abierta:docs/link-missing
Un documento verificado apunta a un objetivo local faltante. Restaure el objetivo o actualice el mapa de autoridad y regenere la referencia.
Referencia abierta:docs/profile-version-drift
Autoridades de gramática, superficie y elaboración no coinciden en el perfil del lenguaje. Reconciliar las autoridades antes de publicar documentación.
Referencia abierta:docs/generated-drift
Una referencia generada comprometida no coincide con su autoridad de máquina. Ejecute nbb scripts/generate-docs-reference.cljs y comprometa el resultado.
Referencia abierta:docs/validation-result-invalid
Una observación de validación de usuario está incompleta o sobreafirma un resultado externo. Registrar clase de participante, tarea, resultado, evidencia y tiempo observado.
Referencia abiertaNinguna consulta sale del navegador.
Hoja de ruta: ampliar solo después de que el límite se mantenga
Un contrato versionado
Mantener alineados gramática, efectos, KIR verificado, adaptadores de destino, calificación y documentación de primera ejecución.
Cerrar brechas del proveedor
Expandir conformidad tipada de solicitud/resultado, pruebas adversariales, recibos, revocación y operaciones reproducibles de versión.
Ganar despliegue más amplio
Ampliar el uso en producción después del proveedor, aislamiento del host, reversión y evidencia de remojo—y crecer bibliotecas declarativas inspeccionables.
Leer la hoja de ruta mantenida y los no objetivos
Los elementos de la hoja de ruta son dirección, no promesas de capacidad entregada o fechas de entrega.
Construir la comunidad en público
Kotoba aún no reclama una gran comunidad. Hoy los puntos de encuentro públicos honestos son los repositorios de código fuente, rastreadores de problemas, historial de versiones y canal de seguridad.
Problemas de lenguaje
Haz una pregunta de diseño, propone una mejora de documentación o reporta un problema reproducible de contrato de lenguaje.
Problemas abiertos del lenguajeProblemas del compilador y CLI
Sigue el trabajo de implementación, lanzamientos, soporte de objetivos e integración en tiempo de ejecución en la implementación instalable.
Problemas abiertos de implementaciónReportar en privado
Use la política de seguridad publicada para vulnerabilidades; no divulgue detalles explotables en un problema público.
Leer política de seguridadFinanciar el límite público, sin comprar autoridad
El perfil de patrocinadores Kotoba GitHub está en preparación. La página del proyecto ya está lista y expondrá una acción de pago solo después de que GitHub apruebe el perfil de la organización.
Patrocinadores GitHub
No se puede realizar ningún pago de patrocinio a través de kotoba-lang.org mientras el perfil GitHub no esté activo.
Soporte no es autoridad
El patrocinio no compra una función, prioridad en la hoja de ruta, SLA de soporte, acceso privado ni una excepción de seguridad.
Estado de patrocinio: PREPARANDO. Verificado 2026-09-01.
Código seguro. Estado confiable. Ejecución controlada.
Evidencia antes que eslóganes
Leer notas breves de ingeniería que conectan las afirmaciones del producto con mediciones, archivos de autoridad y puertas restantes.
Leer el blog KotobaEjecución controlada
Kotoba Cloud conecta identidad y control de despliegue al entorno de ejecución. El descubrimiento está en vivo; la aplicación alojada aún no se ofrece. El cómputo sigue siendo proporcionado por servicios gobernados por separado.
Abrir Kotoba CloudEstado del grafo confiable
Kotobase es la base de datos gráfica direccionada por contenido para estado y conocimiento de IA: relaciones explícitas, historial identificable y acceso con alcance.
Abrir KotobasePlano de cómputo e inferencia
Infraestructura de cómputo y servicio de modelos de flota. La disponibilidad y calificación de ruta siguen siendo específicas del servicio.
Abrir MurakumoPlano de trabajo del agente
Continuar trabajo de agentes a través de espacios de trabajo, objetivos, evidencias, herramientas, aprobaciones y efectos gobernados.
Abrir ItonamiEstos servicios mantienen límites separados de autoridad, disponibilidad y calificación. Su conexión no prueba que cada capacidad Kotoba esté disponible como un servicio alojado generalmente vendido.
Lea el contrato o ejecute la implementación
kotoba-lang/kotoba-lang
Gramática, semántica, contratos de capacidad, afirmaciones de seguridad, contrato CLI, documentación y fijaciones de conformidad.
Lea la autoridad del lenguajekotoba-lang/kotoba
CLI, integraciones de host, proveedores, adaptadores de tiempo de ejecución, pruebas de integración y evidencia de calificación específica de destino.
Abrir la implementaciónAprender, construir o evaluar
Rutas separadas para primer uso, referencia de lenguaje, implementación de backend, límites de seguridad y evidencia de madurez.
Elegir una ruta de documentaciónPerfil de lenguaje 6; estado de lanzamiento por defecto público: LANZADO.
La plataforma portátil principal es WebAssembly Componentes con WASI 0.3.0. La canalización de elaboración tiene 11 etapas nombradas, cerradas por fallo.