;; W1 pure representative: ordinary Clojure-shaped values/functions only.
(ns examples.w1-pure)
(defn double [n]
(+ n n))
(defn main []
(double 21))
-
CID source
bafkreiaeohkv2zu…IPFS CIDv1 · brut · sha2-256 de hello.kotoba -
source SHA-256
0471d55d668ed5f9…sha-256 du fichier exact montré ici -
KIR vérifié SHA-256
92635333e1e0da86…la représentation typée, vérifiée par effet, admise par le compilateur -
identité d'artéfact SHA-256
cfea3b89cc022a6b…lie source, politique, contrat du compilateur et ABI cible
Le CID source ouvre hello.kotoba. Les digests SHA-256 identifient les octets source, KIR vérifié et identité d'artéfact ; ce ne sont pas des adresses IPFS.
SÛR + RAPIDE · CONÇU POUR LOGICIELS GÉNÉRÉS PAR IA
Code sûr. Construit pour la vitesse machine.
Kotoba est un langage en forme de Lisp conçu pour un logiciel généré par IA sûr et ultra-rapide. Programmes inspectables, capacités explicites, et artéfacts adressés par contenu connectent les vérifications du compilateur à l'exécution contrôlée.
Construction à froid la plus rapide de toute chaîne d’outils sur cet hôte.
11.75ms
Kotoba source vers un artéfact WebAssembly, compilation à froid — puis exécuté, et la réponse vérifiée après l’arrêt de l’horloge.
Temps mur de construction à froid du processus en millisecondes ; plus court est plus rapide. K=1 source, voies entrelacées sur un hôte, 7 échantillons chacun.
Tous les ordres 4 passent perfgate à sa politique par défaut non relâchée — au moins 5% et séparé de propagation propre aux bras — donc l'ordre est maintenu même si l'hôte était occupé. Limité à cet hôte, cette taille de source et cette exécution : le temps de construction n'est pas vitesse d'exécution, l'avantage se réduit à mesure que la source grandit, et le publié le binaire a un plafond strict de correction. Les cinq benchmarks, y compris ceux qui vont à l'encontre de Kotoba, sont ci-dessous. Mesuré 2026-08-31 activé Apple M4.
Quand l’IA génère, construit, teste et régénère le code en continu, la latence de construction devient le débit de l’infrastructure.
Pas d'autorité ambiante
Pas de système de fichiers, réseau, processus, horloge, modèle ou secrets implicites.
L'autorité survit à la compilation
Types, effets, ressources et support cible sont admis avant émission.
Seule la subvention est liée
L'hôte et le fournisseur appliquent un périmètre concret et enregistrent la décision.
Pas de rétrogradation classique uniquement
Les nouvelles limites de chiffrement et de publication nécessitent des preuves ML-KEM ou ML-DSA et rejettent le matériel PQ dépouillé.
L'IA peut écrire plus vite que les humains ne peuvent réviser
Le code généré peut être utile et atteindre malgré tout un fichier, un réseau, un secret, un processus, un modèle ou une surface de paiement que la requête ne voulait pas exposer.
Construire largement, contraindre plus tard
Un programme à usage général commence avec une sémantique ambiante. Des sandbox, IAM, conteneurs, politiques et signatures sont ajoutés autour pour récupérer la limite prévue.
Accorder étroitement, puis compiler
Les effets et capacités font partie du calcul admis. Si la cible ne peut pas prouver et lier la subvention, elle n'émet ni n'exécute l'artéfact.
Kotoba complète l'isolation du runtime et de l'OS ; il ne rend pas ces couches inutiles.
Là où l'esprit de Lisp et la réécriture de graphe GP 2 rencontrent la discipline de Rust
Kotoba est un petit langage orienté données, en forme de Clojure. Sa conception s’appuie sur la tradition Lisp du code-comme-données et Réécriture de graphe basée sur règles de GP 2, avec une discipline statique autour de l'autorité, des effets, des ressources, des paquets et de l'identité des artefacts.
Code comme données lisibles
Valeurs immuables, fonctions ordinaires, données explicites et syntaxe composable sont faciles à produire et inspecter pour humains et modèles.
Dire ce qui peut arriver
Effets, capacités, ressources, dépendances, et cibles sont des entrées visibles à l'admission — pas des surprises découvertes après déploiement.
Moins de langage, frontière plus dure
Pas d'interopérabilité ambiante, de chargement de code à l'exécution, de mutation illimitée, de macros définies par l'invité ou de concurrence non bornée dans la surface du composant admis.
SÛR + RAPIDE · CONÇU POUR LES LOGICIELS GÉNÉRÉS PAR IA.Ceci est une direction de confinement, pas une revendication « inviolable ». Le compilateur, le vérificateur, l'exécution, les fournisseurs, les racines de politique, la garde des clés et l'isolation OS restent dans la base de confiance informatique.
Sécurité sur l'ensemble du calcul
La frontière est portée de l'intention à l'exécution. Chaque étape restreint ou vérifie l'autorité ; aucune étape ultérieure n'est autorisée à inventer une autorisation.
Intention déclarative
Une petite surface en forme de Clojure garde les programmes lisibles et exclut les issues de secours ambiantes.
KIR vérifié
Les types et les effets transitifs deviennent une représentation indépendante de la cible et inspectable.
Intersection d’autorité
Les concessions demandées, déléguées, de politique locale, de ressources et de cible ne peuvent que se restreindre.
Adresser l'artéfact
Code, dépendances, politique, contrat du compilateur et ABI cible lient l'identité du calcul.
Lier à l'hôte
Le runtime et le fournisseur lient uniquement les capacités admises, appliquent des budgets finis et émettent des reçus.
L'identité du contenu n'est pas une autorité.Vérification CID, signatures, révocation, politique hôte, contrôles de ressources et isolation OS restent des frontières séparées.
Évaluation Lisp, sans évaluation hôte ambiante
Kotoba évalue le code vérifié comme des données adressées par contenu. Le familier (eval request) la surface descend vers le typé :code/eval capacité ; il ne reçoit jamais de texte source, de forme de lecteur, d'espace de noms ou d'objet hôte.
Quel code ?
Le CID sélectionne une définition KIR vérifiée par hachage et sa fermeture de dépendance uniquement CID.
Peut-il s'exécuter ici ?
L'interface exacte, la ligne d'effet complète, l'allocation actuelle, le carburant, et la profondeur d'évaluation décroissante sont fixés avant l'exécution.
Qu’est-ce qui est revenu ?
Le résultat typé est conservé comme preuve adressée par contenu. Son hash ne peut pas autoriser rétroactivement un effet.
Identité, autorité et preuve de résultat sont trois faits différents.
Contrat machine : lang/typed-eval.edn. Capacité du fil du compilateur : 30. L'application bornée reste une application ordinaire de fermeture de module fermé.
Paramètres par défaut pour une pile informatique axée sur l'IA
Ce sont des revendications techniques avec leur qualification attachée. Par défaut, prêt limité, partiel et direction sont des états différents ; aucun n'est promu silencieusement à universel.
Compiler plus vite. Exécuter plus vite. Garder la frontière.
Kotoba publie des mesures de démarrage du compilateur, boucle développeur, exécution native et domaine de charge avec vérifications de résultats exacts. Les classements de vitesse actuels restent retenus jusqu’à ce que leurs portes d’hôte silencieux passent ; l’admission de sécurité n’est jamais retirée pour gagner un timing.
Stockage sans plafond linguistique.
Kotobase utilise l'identité du contenu, lectures de plage, historique immuable et stockage neutre fournisseur. Capacité physique, location, rétention, coût, réplication et budgets d'exécution restent explicites ; ce n'est pas une revendication de disque infini.
Cryptographie post-quantique par défaut.
Chaque nouvelle frontière cryptographique Kotoba doit nommer une preuve ML-KEM ou ML-DSA et rejeter une rétrogradation classique uniquement. Les Passkey existants, transport, implémentations et garde des clés restent des frontières qualifiées séparément.
Authentification présente. Autorité refusée par défaut.
L’identité Passkey appartient à la frontière de contrôle. Une identité vérifiée ne reçoit toujours aucune autorité système de fichiers, réseau, stockage, modèle, secret, paiement ou GPU tant qu’une concession explicite et limitée ne survit pas aux politiques locales et vérifications hôtes.
Délégation flexible qui ne peut que restreindre.
Les portées demandées, déléguées, de politique locale, de ressource et de cible se croisent. La délégation peut être composée et atténuée, mais ne peut pas créer une autorité ambiante ni élargir la concession de son émetteur.
Prêt pour Web3, neutre en chaîne à la racine.
Un Principal Kotoba stable et un contrôleur Passkey sont primaires. Les comptes CAIP-10, ERC-1271 et ERC-6492 sont des preuves explicites de comptes liés ; une adresse de portefeuille ne devient jamais silencieusement une autorité de stockage ou d’exécution.
Zéro copie lorsque la propriété le permet ; une copie lorsqu'une frontière l'exige.
Les vues octet colonaires conservent le vecteur, ByteBuffer direct et Uint8Array en support. La projection Arrow peut garder les tampons non compressés colonaires via le chemin lacustre autorisé Kotobase. L'entrée réseau, la décompression, le téléchargement GPU et les mises à jour persistantes immuables restent des frontières de copie nommées.
Données en forme de flèche. Noyaux SIMD CPU explicites et GPU natifs de l'appareil.
Sur Apple M4, une colonne Arrow float32 non compressée et non nullable a conservé un seul support mémoire linéaire WebAssembly tandis que Num exécutait un noyau explicite v128 f32x4 SIMD sur sa tranche de valeurs empruntées sans copies Arrow-vers-SIMD ; une queue scalaire couvrait les lignes restantes. En trois exécutions qualifiées de la même charge de travail à échelle 262,147 éléments et artéfact, ce noyau SIMD a terminé 3.66-3.72x plus vite que Wasm scalaire. C'est un résultat noyau-et-hôte, pas une revendication générale de runtime. Le même chemin de colonne borné conserve aussi un ArrayBuffer via ses vues CPU, traverse la limite de propriété GPU avec un upload WebGPU mesuré, s'exécute sur Metal, et retourne un scalaire de quatre octets. Colonnes nullables, autres types Arrow, suppression d'upload mémoire unifiée, noyaux plus larges, et qualification universelle CPU/GPU restent en attente.
IA d'abord. Agent-sûr par défaut.
Kotoba est conçu pour les programmes écrits ou opérés par des agents et bots IA. Plus le modèle est fort, plus les effets explicites, ressources finies, confinement des capacités, reçus et application hôte sont importants.
Frontières prêtes pour AGI, pas une revendication AGI.
L'architecture vise à maintenir l'autorité explicite à mesure que les modèles deviennent plus performants. Kotoba ne prétend pas que l'AGI existe ici, que les programmes générés sont fiables, ou que le confinement supprime le compilateur, le runtime, le fournisseur, la garde des clés et la base de confiance du système d'exploitation.
Autorité machine : lang/product-defaults.edn. Stockage physique illimité, zéro copie partout, classement universel de vitesse, AGI atteint, et inviolable restent des revendications absolues interdites.
Ce que Kotoba écrit par IA ne peut pas demander
| Frontière | Pourquoi il est absent |
|---|---|
compile, load, load-file, load-string, ns-resolve, read-string, require, resolve, use
|
Les composants ne peuvent pas fabriquer du code ou de l'autorité à partir de l'état ambiant du processus. Les chaînes source, formes de lecteur, espaces de noms chargés et objets hôtes compilés n'ont jamais été inférés par effet et ne font pas partie d'un CID de définition. L'opération `(eval request)` admise est donc séparée : elle sélectionne KIR déjà vérifié par CID via :code/eval et est réadmise par l'hôte. |
., .., import, new
|
L'accès arbitraire aux objets et méthodes JVM/JS contourne l'admission de capacité. Non relaxable par dispatch de subvention : l'interop n'atteint jamais guard-component-ability-call, donc l'intersection de subvention, les reçus et la révocation ne peuvent pas voir l'appel. Vacant sur l'ABI wasm32 (aucun chemin n'existe) ; porteur à portable/trusté, où la porte du sous-ensemble est la seule frontière (aucun bac à sable VM séparé n'est revendiqué là). |
alter-var-root, atom, binding, deref, dosync, ref, reset!, set!, swap!, var, volatile!
|
L'état mutable externe est détenu par le fournisseur et médié par capacité/politique ; l'état local au composant doit utiliser un modèle explicitement borné. L'invariant est AMBIANT, pas la mutation elle-même. Depuis 2026-09-02 cette lecture a deux conséquences au lieu d'une. Une cellule qui s'échappe, persiste ou traverse une fonction est détenue par le fournisseur et reste sur le chemin :state-kit-desugar (la ligne d'effet montre :state, une subvention est requise à l'instanciation, les poignées de capacité sont rejetées comme valeurs stockées). Une cellule qui ne fait aucune de ces choses -- (let [a (atom 0)] (swap! a + 1) @a) -- n'a pas besoin d'hôte du tout : la tranche d'état local 1 la transforme en liaisons let ordinaires, donc rien ne l'observe sauf le code en ligne droite qui la possède et aucune cellule n'existe à l'exécution. atom / swap! / reset! / deref sont donc admis via élaboration, et refusés dès que la cellule s'échapperait. ref / dosync / volatile! / binding / var / alter-var-root / set! n'ont aucun modèle de capacité décidé et restent refusés en échec fermé. |
agent, future, locking, pmap, send, send-off
|
La planification des composants et les ressources doivent rester contrôlées par le fournisseur et limitées. Ni les CIDs de définition ni les autorisations déléguées ne mesurent le CPU ou la planification ; le carburant est par instance et les threads ambiants y échapperaient. Une capacité de spawn structuré avec carburant sous-budgeté est concevable mais indécise ; aucun chemin d'élargissement pour l'instant. |
defmacro
|
La surface des composants sûrs doit être inspectable statiquement avant exécution. Inflexible : l’expansion exécute du code à l’intérieur du compilateur (temps de compilation), et les hachages CID de définition post-désucre typé KIR, donc les macros non bornées s’exécutent tôt et rendent l’identité source non vérifiable. defdesugar (désucre pur borné) reste l’alternative admise. |
catch, throw, try
|
Le throw/try/catch ambiant est un flux de contrôle non local non suivi : il sort des portées que la ligne d’effet inférée ne mentionne jamais et saute les obligations de déroulement (la rétractation de la facette dataspace n’a pas encore de déroulement vérifié). L’interdiction porte sur la forme ambiante. Depuis 2026-09-02 la capacité d’abandon typé admet les têtes par élaboration : l’effet apparaît dans la ligne inférée comme :abort et la fonction se réduit en [:result T E], donc la forme ambiante n’existe jamais après élaboration. La tranche 2 (2026-09-02) a fait propager :abort à travers les appels et a normalisé A un opérande ou test d’abandon en une liaison let ; aucun ne dilate l’invariant, car un abandon propagé est sur la ligne de l’appelant et un normalisé A est la même élaboration en position différente. Là où la précondition de déroulement importerait, l’abandon reste refusé -- pour un APPEL maintenant ainsi que pour un throw. |
Ce sont des contraintes de sécurité nommées dans lang/surface-status.edn, pas des fonctionnalités manquantes dans une feuille de route.
Preuve, avec la frontière attachée
Kotoba sépare les preuves d'implémentation de la traction du marché et maintient le risque résiduel à côté de chaque revendication de sécurité.
cœurs 33
Utilisation interne en production
La pile Kotoba plus large exécute 33 cœurs d'inférence en interne. Cela prouve que l'équipe opère sa propre pile ; ce n'est pas une traction client, une adoption payée ou un revenu.
revendications 8
Les frontières sont lisibles par machine
Les revendications de sécurité nomment leur base informatique de confiance, les preuves négatives et le risque résiduel au lieu de se réduire à un slogan « inviolable ».
refuser par défaut
Pas de subvention, pas d'effet hôte
Une politique vide n'accorde aucune autorité sur le système de fichiers, réseau, processus, horloge, modèle ou secret. Les fournisseurs doivent aussi valider la portée concrète des ressources.
L'utilisation interne en production est uniquement une preuve de dogfooding. Elle n'implique pas de clients externes, de pilotes payants ou de revenus.
Cinq benchmarks. Cinq questions différentes.
Le démarrage du compilateur demande à quelle vitesse une source minuscule devient un artefact. L'échelle de construction demande ce qui arrive à ce nombre lorsque la source cesse d'être minuscule — et si l'artefact répond toujours. La boucle développeur sépare la résolution, la vérification, les constructions et le premier résultat. Le runtime natif demande à quelle vitesse le code déjà construit s'exécute. La suite domaine de charge demande comment se comportent les chaînes, collections, allocation, E/S, concurrence et une petite application réelle. Les résultats gardent les cinq questions — et leur statut de preuve — séparés.
chaînes d'outils 4, 21 exécutions chacune
Kotoba 40.998 ms · Rust 126.422 ms · C 146.324 ms · JVM 961.248 ms médian.
21 échantillons à froid du processus en rotation · charge1 30.79 → 39.79 · requis ≤ 1 · 2026-08-29 · Apple M4
Charges 6 × comparateurs 5
Amu natif est testé contre Rust, Clang / C11, Zig, Go c-shared, Swift via une frontière d'appel native commune.
Paires comparateur/charge 30/30 · réponses exactes vérifiées
19 de 30 paires
Amu natif gagne 19 des 30 paires comparateur/charge de travail par au moins 5%, séparé de la propagation propre aux bras. La revendication la plus rapide bornée nécessite chaque paire, donc elle reste non qualifiée — le compte est la moitié informative.
Au moins 2 de ces paires ne peuvent pas être gagnées du tout. Sur l'arithmétique étroite, amu, Apple clang -O3 et rustc -O3 compilent le noyau en la même séquence d'instructions 61 — clang et rustc sont identiques en octets, amu ne diffère que par les numéros de registres. Une marge 5% sur un code identique n'existe pas, donc la revendication bornée est inatteignable plutôt que simplement non satisfaite.
Médiane de 5 exécutions qualifiées sur l'hôte ; le score variait de 19 à 20 et 19 des 30 paires étaient qualifiées à chaque fois. Un seul échantillon bruyant peut disqualifier plusieurs paires à la fois, donc un score d'une seule exécution n'est pas précis pour une paire.
CPU occupé 0.090 → 0.069 → 0.076 · requis ≤ 0.10 · 2026-09-07
Chemins de la chaîne d'outils 11
La résolution des dépendances, la vérification, les builds propres et sans changement, ainsi que le premier résultat à froid du processus sont enregistrés séparément.
Échantillons 7 par étape mesurée · load1 20.84 → 24.49 · requis ≤ 1
Tailles sources 8
Le même programme d'une fonction à 2048, construit par chaque chaîne d'outils sur l'hôte puis exécuté. Le binaire publié a ici le coût de démarrage à froid le plus bas et une exactitude plafond au-dessus des fonctions 128.
artéfacts vérifiés après l'arrêt de l'horloge · charge1 2.73 → 2.73 · requis ≤ 1 · 2026-08-31
domaines 6 × chemins d'exécution 6
Chaînes, collections, allocation, E/S fichier, concurrence à quatre travailleurs, et un noyau d'application de politique d'admission de requêtes sont vérifiés pour la correction.
Échantillons 7 dans les voies process-cold et amorties · load1 13.87 → 12.38 · classement retenu
Temps de compilation à mesure que la source grandit
Les benchmarks ci-dessus construisent un programme assez petit pour tenir sur un écran, qui mesure la rapidité de démarrage d'une chaîne d'outils. Cela dit peu sur le nombre qu'un développeur attend réellement, qui est la pente. Ce cinquième le benchmark génère le même programme à des tailles croissantes — K fonctions indépendantes à quatre opérations et un point d'entrée qui appelle tous — et le construit via chaque chaîne d'outils sur l'hôte, en ordre rotatif.
Il exécute ensuite ce que chaque chaîne d’outils a produit, après que l’horloge s’est arrêtée. Cette vérification n'est pas une décoration. La façon la plus rapide d'émettre un artefact est de émettre un cassé, donc une voie qui a cessé de fonctionner publierait autrement ses meilleurs chiffres exactement là où il a cessé de fonctionner.
Les deux axes sont logarithmiques : les sources couvrent trois ordres de grandeur et les temps aussi. Une ligne se termine par un point où l'exécution s'est arrêtée, par une croix où cette voie a émis un artefact qui n'est pas le programme, et par une barre où la chaîne d'outils a refusé de construire. Ces trois événements ne sont pas identiques et les deux échecs ci-dessous ne sont pas le même échec.
| Chaîne d'outils / cible | K=1 | K=32 | K=128 | K=129 | K=512 | K=1023 | K=1024 | K=2048 |
|---|---|---|---|---|---|---|---|---|
| Kotoba · CLI publié · WebAssembly | 11.753 ms | 35.84 ms | 111.538 ms | artefact invalide | artefact invalide | artefact invalide | échec de la construction | échec de la construction |
| Kotoba / Amu · WebAssembly | 733.255 ms | 825.418 ms | 1123.04 ms | 1123.847 ms | 3380.63 ms | 9242.463 ms | échec de la construction | échec de la construction |
| Kotoba / Amu · Native aarch64-macos | 962.198 ms | 1509.84 ms | 2973.249 ms | 3000.243 ms | 10601.87 ms | 23725.327 ms | échec de la construction | échec de la construction |
| 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 · Hôte natif | 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 | pas de chaîne d'outils | pas de chaîne d'outils | pas de chaîne d'outils | pas de chaîne d'outils | pas de chaîne d'outils | pas de chaîne d'outils | pas de chaîne d'outils | pas de chaîne d'outils |
| C / Clang · Hôte natif | 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 |
Mesuré 2026-08-31 sur judahnoMac-mini.local (Apple M4). K est le nombre de fonctions générées ; la source Kotoba va de 9 à 14338 lignes. Cibles, ABI, niveaux d'optimisation et contrats d'exécution diffèrent selon les voies, donc cela interroge la latence de retour développeur, pas un travail équivalent. La porte de charge hôte a échoué (charge1 2.73–2.73, requis ≤ 1), donc ce sont des observations de cette exécution plutôt que des chiffres portables. Parce que les voies sont entrelacées, l'ordre est qualifié séparément.
Quelles ordonnances survivent au test de bruit
Un ratio n'est pas un classement. perfgate refuse tout ordre dont l’écart tombe à l’intérieur de la propre étendue des deux bras, quelle que soit la taille du ratio, et refuse un bras avec trop peu d'échantillons ou trop de bruit. Il s’exécute ici avec sa politique par défaut, non relâchée — un seuil assoupli pour laisser passer ceci serait un benchmark mesurant ses propres seuils. Parce que les voies sont entrelacées sur un hôte, un écart qui survit à ce test survit à un hôte occupé.
| Taille | Comparé à | Kotoba fois plus rapide ? | Écart vs propagation combinée | Pourquoi pas, sinon |
|---|---|---|---|---|
| K=1 | C / Clang · Hôte natif | oui, qualifié | 17.1 ms vs 1.0 ms | — |
| K=1 | JVM / javac · classe JVM | oui, qualifié | 160.8 ms vs 5.4 ms | — |
| K=1 | Rust / rustc · Hôte natif | oui, qualifié | 44.2 ms contre 0.6 ms | — |
| K=1 | Rust / rustc · WebAssembly | oui, qualifié | 27.1 ms contre 0.5 ms | — |
| K=32 | C / Clang · Hôte natif | non | 5.3 ms contre 1.0 ms | amélioration-sous-seuil |
| K=32 | JVM / javac · classe JVM | oui, qualifié | 161.9 ms contre 1.2 ms | — |
| K=32 | Rust / rustc · Hôte natif | oui, qualifié | 26.7 ms contre 0.7 ms | — |
| K=32 | Rust / rustc · WebAssembly | oui, qualifié | 9.8 ms vs 0.6 ms | — |
| K=128 | C / Clang · Hôte natif | non | 75.8 ms contre 1.2 ms | amélioration-sous-seuil |
| K=128 | JVM / javac · classe JVM | oui, qualifié | 126.2 ms contre 2.2 ms | — |
| K=128 | Rust / rustc · Hôte natif | non | 29.3 ms contre 1.4 ms | amélioration-sous-seuil |
| K=128 | Rust / rustc · WebAssembly | non | 45.8 ms contre 1.1 ms | amélioration-sous-seuil |
amélioration-sous-seuil signifie que la voie Kotoba n'était pas plus rapide à cette taille du tout. L'avantage est réel et qualifié au démarrage à froid, et il disparaît contre C à K=32 et contre Rust à K=128. Ce croisement est le résultat, donc il est montré plutôt que résumé.
Deux échecs qui ne sont pas le même échec
Trois voies Kotoba ont cessé de fonctionner dans cette exécution, et les publier comme une seule la ligne aurait été fausse. L'une est un défaut. Les deux autres sont déclarées limites appliquées exactement comme spécifié, et signalant celles-ci comme défauts signifierait mesurer les limites au lieu du compilateur.
| Observation | Lecture |
|---|---|
| Le CLI kotoba publié émet un module qui ne compilera pas au-delà de 128 fonctions | Un défaut, et la raison de valider dans un harnais. À K=129 un appel doit porter l'index de fonction 128, la première valeur nécessitant deux octets LEB128, et l'émetteur en écrit un. Les octets indiquent qu'il ne s'agit pas d'un encodeur manquant mais d'un non utilisé : local.set 128 est écrit 80 01, et call 128 une instruction plus tard est écrit 80. Le nombre d'opérandes tronqués est exactement K moins 128. Le compilateur actuel ne l'a pas — Amu construit K=129 correctement, et la correction est sur la branche par défaut de son émetteur depuis avant que cette version soit taguée. |
| Chaque voie Kotoba déclenche à K=512 lorsqu’elle est construite avec les paramètres par défaut | Pas un défaut. Un module Kotoba porte un budget d'appels déclaré et la valeur par défaut du compilateur est de 512 appels, que cette charge dépasse à K=512 où le point d'entrée appelle 512 feuilles. Le harnais déclare explicitement 1,048,576 unités et enregistre ce fait. C, Rust et Java n'ont pas de limite équivalente à augmenter. |
| Amu refuse le module immédiatement dès qu'il contiendrait plus de 1,024 fonctions | Ce n’est pas non plus un défaut, et c’est l’opposé de la première ligne. max-functions est une limite d’admission déclarée, donc le compilateur s’arrête avec kotoba.error/subset-reject et nomme ce qu’il a refusé, plutôt que d’émettre quelque chose qui ne se chargera pas. Un plafond bruyant et un plafond silencieux sont des résultats très différents, et seul un harnais qui exécute l’artefact les distingue. Mesuré 2026-09-07 : c’est le plafond de tout le programme, pas d’un seul module — max-project-functions est aussi 1,024 et est vérifié par rapport au projet lié, donc aucune organisation de modules ne compile aujourd’hui un programme à 2,048 fonctions. |
Ce que cela établit
| Question | Réponse de cette exécution |
|---|---|
| Quelle est la rapidité d'une construction Kotoba à froid d'un petit module ? | Le CLI publié construit K=1 en 11.753 ms à froid, artefact exécuté et réponse vérifiée — le premier résultat le plus rapide de toute voie mesurée ici. |
| Quelle taille de module le binaire publié peut-il construire ? | Jusqu’à 128 fonctions. Au-delà, ce n’est pas plus lent, c’est erroné, et ce harnais signale cela comme une voie échouée plutôt qu’une voie rapide. |
| Le temps de build reste-t-il compétitif à mesure que la source grandit ? | À travers K=128 le CLI publié est mesuré par rapport à Rust et C dans le tableau ci-dessus. Au-delà de ce point, le seul compilateur Kotoba qui émet encore un module correct est Amu, qui s'exécute sur nbb plutôt que comme un binaire publié, et est environ un ordre de grandeur plus lent à chaque taille mesurée — donc à grande échelle la vitesse de compilation n'est actuellement pas une force Kotoba, et cette page ne prétendra pas le contraire. |
| Quelle taille une source a-t-elle été construite de bout en bout ? | K=1023 via Amu — 7163 lignes de Kotoba, artefact exécuté et réponse vérifiée. C’est une fonction de moins que le plafond déclaré 1,024, et la taille suivante est refusée plutôt que mal construite. |
| Le code émis est-il rapide ? | Hors de portée ici — ceci mesure la construction, pas l'exécution. La suite runtime natif ci-dessus pose cette question. |
En résumé : À la plus petite taille, le binaire publié est plus rapide que tous les comparateurs ici avec une marge qui survit au test de bruit, et il a un plafond de correction strict à 128 fonctions. Le compilateur sans ce plafond est environ un ordre de grandeur plus lent à chaque taille mesuré. Les deux faits proviennent de la même exécution, et le harnais qui les a trouvés est public, ainsi l'exécution peut être contestée.
Combien de temps chaque charge de travail native prend réellement
La grille ci-dessous rapporte la marge entre deux bras. C’est le nombre règles perfgate activées, mais un pourcentage seul ne dit pas si un la charge s'exécute en cinq millisecondes ou cinq cents, et elle cache le différence entre une paire contestée et une paire non pertinente. Ces panneaux sont les médianes à partir desquelles ces marges sont calculées. Amu natif est la voie colorée dans chaque panneau — y compris ceux où il n'est pas premier. Chaque panneau est échelonné à son bras le plus lent, car la question à laquelle un panel répond est qui est plus rapide dans cette charge de travail.
Arithmétique étroite
Pression large sur les registres
Pression de débordement profonde
Préservation d'appel
Branche + contrôle de flux d'appel
Boucle rappel arête
Médiane en millisecondes sur 5 exécutions qualifiées hôte ; plus court est plus rapide. Chaque bras a retourné la même réponse vérifiée indépendamment, et la médiane candidate est une valeur par charge de travail — la suite fait tourner chaque paire de moteurs en ordre ABBA/BAAB, donc le même artefact Amu est chronométré une fois par charge de travail puis comparé à chaque bras à son tour. Contrairement aux quatre autres benchmarks sur cette page, la porte hôte silencieuse de celui-ci a RÉUSSI (charge qualifiée hôte), donc ce sont des chiffres pour cet hôte plutôt que des observations seulement. La revendication la plus rapide bornée nécessite encore toutes les 30 paires, ce à quoi sert la grille ci-dessous.
Chaque paire d'exécution, victoire ou défaite
La revendication bornée est tout ou rien, donc une seule paire non qualifiée la rend fausse. Publier uniquement ce verdict cacherait quelles paires sont contestées, donc l’ensemble la grille est ici. Une cellule est l'amélioration moyenne de Amu natif par rapport à ce comparateur sur cette charge de travail ; positif signifie qu'Amu est plus rapide, et une coche marque les paires qui perfgate clair — au moins 5% et séparé de la propre dispersion des bras.
| Charge de travail | Rust | Clang / C11 | Zig | Go c-shared | Swift |
|---|---|---|---|---|---|
| Arithmétique étroite | +0.4% | -0.6% | +20.1% | +84.7% | -0.6% |
| Pression large sur les registres | +6.5% | +10.9% | +16.9% | +86.0% | +87.1% |
| Pression de débordement profonde | +4.2% | +9.3% | +5.1% | +82.2% | +92.6% |
| Préservation d'appel | -1.0% | -0.3% | +42.9% | +85.2% | +29.6% |
| Branche + contrôle de flux d'appel | -2.6% | -7.1% | +43.8% | +85.2% | +25.1% |
| Boucle rappel arête | +0.8% | -0.1% | +32.4% | +17.2% | +24.8% |
Chaque cellule est une barre qui grandit à partir d’une ligne centrale : à droite d’elle Amu natif est plus rapide, à gauche plus lent. Les deux directions sont mises à l’échelle séparément — les gains vont jusqu’à +93% et les pertes seulement jusqu’à −7%, donc une échelle partagée aplatirait chaque paire contestée en la même fente invisible. Le signe est aussi porté par le côté de la ligne et par le nombre signé, donc aucune lecture de cette grille ne dépend de distinguer deux couleurs.
19 des 30 paires qualifiées (médiane de 5; 19 à chaque exécution) · candidat 42f092ea5b61 · Apple M4, 10 CPU logiques, 16 GiB
Livraison d'optimisation après l'exécution publiée
Le benchmark daté ci-dessus reste immuable. Les nouvelles tranches d'implémentation sont listées séparément jusqu'à ce que la suite même-artefact soit relancée et passe ses portes de qualification.
| Surface | Livré | Limite de preuve |
|---|---|---|
| Vecteurs natifs / allocation | Les littéraux vectoriels bornés non échappants sont prouvés d'échappement et remplacés par des scalaires sur x86-64 et AArch64. | Tests backend 211 / assertions 2,442 ; les vecteurs échappants conservent l'ABI hôte vérifiée. Pas encore de chronométrage classé. |
| SIMD de chaînes | L'égalité vérifiée POSIX utilise une comparaison explicite NEON ou SSE2 de 16 octets après validation du handle et UTF-8 canonique. | Assembleur optimisé et vecteurs sémantiques ISA natifs vérifiés. Windows reste épinglé séparément ; classement de latence en attente. |
| Capacité E/S asynchrone | Lecture/écriture/liste/existence/suppression éventuelle confinée à la racine utilise CompletableFuture sur JVM et fs.promises sur Node. | Les tests JVM et Node sur système de fichiers réel passent. Le benchmark Wasm autonome public n'a toujours pas de liaison hôte admise, donc sa cellule I/O reste N/A. |
| Concurrence structurée | Une portée enfant 32 bornée fail-fast joint, annule les frères et empêche l'évasion de durée de vie enfant comme état canonique Kotoba. | Assertions de parité 996 à travers l'autorité .kotoba et le chemin de chargement CLJC. Ce sont des sémantiques de durée structurée, pas un résultat de débit de thread OS. |
| Kotoba CLI | kotoba test/build consomme la nouvelle épingle du compilateur ; kotoba compile émet directement x86-64 scellé et AArch64 KEXE. | Cycle de vie CLI public et artefact vectoriel AArch64 vérifié. Native --run reste refusé jusqu’à ce qu’un accusé de réception du chargeur mesuré soit câblé. |
Démarrage du compilateur, quatre chaînes d'outils
Temps mur froid du processus pour une toute petite source, en millisecondes ; plus court est plus rapide. 21 échantillons tournants par chaîne d'outils sur Apple M4. La porte de charge hôte a ÉCHOUÉ lors de cette exécution, donc ce sont des observations d'une machine, pas un classement.
| Chaîne d'outils | Sortie | Médiane | p95 | Temps écoulé relatif |
|---|---|---|---|---|
| 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 · version Homebrew clang 22.1.7 · javac 24.0.2. Kotoba, Rust et C émettent Wasm ; javac émet un fichier class. Différentes cibles et travaux de compilateur font de ceci une observation de démarrage, pas un classement universel. La porte de charge hôte enregistrée a échoué, donc le tableau n'est pas un classement de vitesse qualifié.
| Chaîne d'outils / cible | Résoudre | Vérifier | Construction propre | Compilation sans changement | Démarrer + exécuter | Compilation propre + premier résultat |
|---|---|---|---|---|---|---|
| Kotoba · WebAssembly | N/A | 231.75 ms | 62.906 ms | 42.332 ms | 57.253 ms | 142.644 ms |
| Rust / Cargo · natif macOS arm64 | 138.018 ms | 71.208 ms | 896.478 ms | 67.764 ms | 371.522 ms | 1299.171 ms |
| C / Clang · arm64 macOS natif | 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 natif | N/A | N/A | 1059.624 ms | 395.305 ms | 203.169 ms | 1269.918 ms |
| Go · arm64 macOS natif | 43.553 ms | 6979.823 ms | 3499.277 ms | 150.902 ms | 247.051 ms | 3755.431 ms |
| Swift / SwiftPM · natif arm64 macOS | 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 |
Chaque artefact émis a produit 42 dans un processus frais. Les cibles et contrats d’exécution diffèrent ; N/A n’est jamais zéro. La porte de chargement hôte a échoué, donc ce sont des observations reproductibles plutôt qu’un classement de vitesse inter-langages.
Six domaines, côte à côte
Chaque panneau est mis à l'échelle selon sa propre voie la plus lente, car la question qu'un panneau réponses est qui est plus rapide dans ce domaine, pas comment les domaines se comparent entre eux autre. La voie de Kotoba est celle en couleur dans chaque panneau — y compris le panneaux où il est dernier. Son artefact Wasm autonome s'exécute via un Node l’hôte et paie ce démarrage à chaque échantillon à froid de processus, tandis que Rust, C et Go exécuter comme des binaires natifs ; lorsque la cible n'a pas de système de fichiers ambiant ni de thread contrat du tout, la voie est absente plutôt que nulle.
Chaîne
Collection
Allocation
E/S
Concurrence
Application réelle
Médianes à froid en millisecondes ; plus court est plus rapide. La porte de charge hôte échoué lors de cette exécution, donc ces panneaux sont des observations plutôt qu'un classement, et la voie amortie ci-dessous raconte encore une autre histoire.
| Chemin d'exécution | Chaîne | Collection | Allocation | E/S fichier | Concurrence | Application réelle |
|---|---|---|---|---|---|---|
| Kotoba / Wasm + hôte JS typé | 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 |
| Aller | 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 |
Chaque échantillon a retourné la somme de contrôle de référence exacte. Kotoba utilise son Wasm émis et son ABI typé déclaré ; sa cible autonome n'a pas de système de fichiers ambiant ni de contrat de thread, donc ces cellules sont considérées N/A. La porte de charge hôte enregistrée a échoué, donc les médianes sont des observations, pas un classement.
| Chemin d'exécution | Chaîne | Collection | Allocation | E/S fichier | Concurrence | Application réelle |
|---|---|---|---|---|---|---|
| Kotoba / Wasm + hôte JS typé | 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 |
| Aller | 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 |
Chaque lot plus grand en cours est divisé par son multiplicateur de charge de travail déclaré. Cela amortit le démarrage mais ne supprime pas complètement le coût d'instanciation du processus, VM ou Wasm, donc ce n'est pas étiqueté comme un résultat d'état stable parfaitement chaud. Les chaînes pures inc/dec de la carte Kotoba sont fusionnées en reduce sans vecteurs intermédiaires ; les callbacks hors de ce sous-ensemble prouvé conservent la matérialisation impatiente.
| Question | Implémentations comparées | Conclusion actuelle |
|---|---|---|
| Compilation + exécution Wasm minuscule | Kotoba, Rust, C, et chaînes d'outils JVM | Quatre médianes à froid de processus publiées ci-dessus ; seuls Kotoba/Rust/C partagent la cible Wasm, et aucun classement général de vitesse de construction n'est revendiqué |
| Boucle développeur de petit projet | Kotoba, Rust, C, Zig, TinyGo, Go, Swift, JVM, AssemblyScript, .NET IL et .NET Native AOT | Sept échantillons par étape disponible sont publiés ; les différences de cible et une porte de charge hôte échouée interdisent un classement universel |
| Exécution native en état stable | Amu natif vs Rust, Clang / C11, Zig, Go c-shared, Swift | Toutes les cellules de comparaison sémantique 30 sont complètes ; classement de vitesse retenu car la porte hôte silencieuse a échoué |
| Chaînes, collections, allocation, E/S, concurrence et application réelle | Chemins d'exécution Kotoba, Rust, C, Go, JVM et JavaScript | Les sommes de contrôle exactes et les échantillons amortis à froid sont publiés ; les E/S et threads Kotoba autonomes sont N/A, tandis que son application pure d’admission de requête est mesurée ; la porte de chargement échouée retient le classement |
Ce que couvre la suite native
Chaque implémentation retourne une réponse connue vérifiée indépendamment. La suite fait tourner chaque paire de moteurs en ordre ABBA/BAAB et mesure après chargement, mappage et recherche de symbole.
| Charge de travail | Ce qu'il met en avant | Statut des preuves |
|---|---|---|
| Arithmétique étroite | Résultat exact vérifié ; chronométrage non qualifié | |
| Pression large sur les registres | Résultat exact vérifié ; chronométrage non qualifié | |
| Pression de débordement profonde | Résultat exact vérifié ; chronométrage non qualifié | |
| Préservation d'appel | Résultat exact vérifié ; chronométrage non qualifié | |
| Branche + contrôle de flux d'appel | Résultat exact vérifié ; chronométrage non qualifié | |
| Boucle rappel arête | Résultat exact vérifié ; chronométrage non qualifié |
Où chaque benchmark vit
Chaque nombre ci-dessus provient d'un harnais public et d'un rapport engagé, donc un l'exécution peut être répétée et une revendication peut être contestée. Les chemins dans le dépôt dans cette table est vérifiée par rapport à l'arbre de travail lorsque cette page est générée : un harnais qui fait échouer la compilation plutôt que de livrer un lien mort.
La porte par laquelle chaque ordre sur cette page est passé est kotoba-lang/perfgate, exécuté avec sa propre politique par défaut non relâchée. Un seuil assoupli pour laisser un exécuter serait un benchmark mesurant ses propres seuils.
En résumé : Les artefacts, résultats exacts et échantillons sont réels dans les cinq benchmarks. Trois d'entre eux — démarrage du compilateur, boucle développeur et domaines de charge — ont échoué à leur perfgate hôte silencieux, donc ils ne sont pas classés et sont publiés comme observations. La suite runtime natif a passé son perfgate et gagne 19 de ses 30 paires, en deçà de la revendication de chaque paire nécessaire. La montée en charge de la construction qualifie son ordre de démarrage à froid contre chaque comparateur sur l'hôte et trouve un plafond de correction dans la même exécution. Aucune revendication universelle de classement de vitesse n'est faite sur cette page, et aucune de ces exécutions ne l'autorise.
Revendiquer avec leurs limites attachées
Ces revendications sont générées à partir de lang/safety-claims.edn. Chacun garde sa base de confiance informatique et son risque résiduel visibles, car un slogan de sécurité sans limite n'est que du marketing.
Les composants admis ne peuvent pas adresser la mémoire d’exécution/native et les opérations mémoire des composants sont bornées ou déclenchent une erreur.
Base informatique de confiance
lecteur borné · admission frontend · vérificateur d'artefacts · runtime Wasm/natif
Risque résiduel
- les vulnérabilités du moteur d'exécution restent dans le TCB
- Les chargeurs natifs nécessitent une seconde frontière d'isolation OS
Chaque effet de composant transitif est déclaré et admis avant émission, y compris les effets utilisés par les fournisseurs écrits en Kotoba.
Base informatique de confiance
inférence d'effet · catalogue de capacités · graphe d'appels frontend
Risque résiduel
- kotoba et la parité de grammaire/effet du compilateur doivent être continuellement comparés
Une capacité non accordée est absente ou non liée et ne peut atteindre un fournisseur ou un gestionnaire natif.
Base informatique de confiance
intersection de politique · émission d'import de compilateur · liaison d'import de soumission · garde hôte
Risque résiduel
- le fournisseur et les implémentations natives doivent valider indépendamment la portée des ressources
- les concessions effectives en production doivent interdire la portée générique
La même source admise, cible, politique et verrou produisent le même résultat pur observable et les mêmes octets d'artéfact.
Base informatique de confiance
lecteur canonique · abaissement déterministe · chaîne d'outils épinglée
Risque résiduel
- les effets hôtes sont déterministes uniquement là où leur contrat de capacité le stipule
Source, admission, exécution, mémoire et sortie utilisent des limites finies explicites.
Base informatique de confiance
limites d'admission · compteur de carburant · quota d'exécution · délai d'attente du superviseur
Risque résiduel
- Les superviseurs de plateforme n'ont pas encore de preuve d'isolation de production équivalente
L'admission de publication lie l'identité de l'artefact, le signataire de confiance, la validité et la preuve reproductible.
Base informatique de confiance
vérificateur de signature · configuration de signataire de confiance · horloge · ensemble de révocation
Risque résiduel
- la garde des clés et la distribution externe de révocation restent TCB opérationnels
Un composant portable partagé a une acceptation, un résultat et une trace d'effet égaux à travers des backends qualifiés.
Base informatique de confiance
manifeste de conformité partagé · adaptateurs backend · exécuteur de comparaison
Risque résiduel
- les fonctionnalités uniquement compilateur ne sont pas portables et doivent être rejetées par les profils portables
Une importation de composant atteint son fournisseur ou gestionnaire natif uniquement avec un périmètre de ressource post-intersection concret et émet un reçu.
Base informatique de confiance
intersection de capacité · garde hôte · gestionnaire fournisseur · évier de reçu
Risque résiduel
- Les contrôles spécifiques au fournisseur de chemin, redirection, lien symbolique et locataire nécessitent des kits Q5
Qualification Q1, au 2026-07-18.
Liaison de version
Un profil de langue et une version d'implémentation sont séparés jusqu'à ce qu'une enveloppe signée les lie.
Profil 6
contrat de package 1
v0.7.0
liaison de profil : vérifié
PUBLIÉ
:docs/release-bound-profile
Kotoba v0.7.0 pour darwin-arm64 est l'implémentation publique liée au profil de langue 6 et au contrat de package 1. Son enveloppe signée vérifie l'arbre source, le digest de l'artéfact, et le résultat de conformité 536-test / 8,580-assertion. Les autres plateformes restent non liées.
Lire les preuves de version généréesDémarrer en soixante secondes
Installer et auto-vérifier
brew tap kotoba-lang/kotoba
brew trust kotoba-lang/kotoba
brew install kotoba
kotoba selfhost check --jsonAccepter une réponse valide avec une liste de problèmes vide.
Un premier programme
(defn main []
(+ 40 2))Ce programme ne demande aucune importation hôte ; le module émis n'a pas d'importations.
Apprendre, essayer, puis approfondir
Un chemin connecté du premier programme aux contrats linguistiques, bibliothèques, preuves, et surfaces de déploiement.
Docs par intention
Commencez par l'installation, apprenez la langue admise, ou inspectez la sémantique normative et les données de conformité.
Carte de documentation ouverteUne source, une réponse
L'exemple ci-dessous est la source exacte compilée dans la démo du navigateur—pas une réimplémentation JavaScript.
Lire l'exempleExécuter sur cette page
Charger un artefact WebAssembly lié à la même origine et au digest, et appeler sa fonction principale exportée Kotoba.
Jeu ouvertBibliothèques et contrats
Parcourez les noms de base bornés, les bibliothèques fondamentales, les règles de paquet et leur limite de maturité actuelle.
Parcourir les bibliothèquesUn petit programme Kotoba, s'exécutant pour de vrai
Amu compile cette source pure Kotoba vers le profil wasm32-browser. L'artefact enregistré n'a pas d'importations et retourne 42.
;; W1 pure representative: ordinary Clojure-shaped values/functions only.
(ns examples.w1-pure)
(defn double [n]
(+ n n))
(defn main []
(double 21))
Autorité de mise en évidence : kotoba-lang/grammar → kotoba.grammar.highlight/tokenize → HTML au moment de la construction. Contrat de périmètre de l'éditeur : source.kotoba. Dépendance du surligneur du navigateur : aucune. Inspecter les dépendances
Compiler localement : kotoba compile double-21.kotoba --target wasm32-browser --output double-21.wasm
Exécuter l’artefact vérifié
Le navigateur récupère 344 octets, vérifie SHA-256, rejette chaque importation, instancie le module, et appelle main().
Résultat attendu :
42
Prêt. Aucun code n’a encore été exécuté.
Cela exécute un exemple précompilé et immuable. L’édition de source arbitraire dans le navigateur n’est pas encore une surface de compilateur livrée.
Démos interactives : solar-helix (rendu WebGPU piloté par invité) · kami-survivors (un jeu .kotoba) · gpu-clear (fumée WebGPU). Hébergé sur la surface wasm-webcomponent GitHub Pages ; la disponibilité dépend du support WebGPU/WebAssembly par navigateur.
Bibliothèques, sans masquer la frontière du paquet
Les bibliothèques Kotoba sont des graphes adressés par contenu. Les noms et les dépôts GitHub aident les gens à les découvrir ; les définitions et les CIDs de version signée indiquent exactement ce qu’ils sont.
Référence de symbole générée
Recherchez les noms admis par le contrat de bibliothèque standard borné actuel.
Parcourir les symboles principauxDonnées, effets, E/S, outils
Commencer avec coll, spec, json, text, wit, async, time, fs, http, test, fmt, lint et contrats LSP.
Parcourir la carte de la bibliothèqueDépendances adressées par contenu
Inspecter les CIDs de dépendance exacts, les couches d'identité, la provenance GitHub et la frontière de publication actuelle.
Ouvrir le catalogue de bibliothèques et publier le fluxParcourir toute l'organisation par tag
Il y a 2,215 dépôts publics dans le kotoba-lang organisation. Chaque étiquette ci-dessous est le sujet GitHub de le même nom, donc le filtre du site et les sujets de l'organisation forment un seul vocabulaire plutôt que deux qui dérivent. Choisissez-en un pour ouvrir le catalogue déjà filtré.
Parcourir et filtrer tous les dépôts 2,215
Un dépôt n’est pas un paquet publié. Exactement 1 bibliothèque est publiée via le registre adressé par contenu ; le reste de cette liste est une découverte. Les étiquettes de maturité des dépôts n’impliquent pas la stabilité de l’API 1.0, une adoption large ou des SLOs de production, et les dépôts 255 ne correspondent à aucune règle de domaine et sont affichés sans étiquette plutôt que d’obtenir l’étiquette la plus proche.
Rechercher dans la référence vérifiée
Rechercher commandes, noms de bibliothèque standard, diagnostics et statut de publication. L’index est généré à partir des autorités machines et reste sur cette page.
Essayer : compiler, option-some, docs/lien-manquant
Liaison de version
Kotoba v0.7.0 pour darwin-arm64 est l'implémentation publique liée au profil de langue 6 et au contrat de package 1. Son enveloppe signée vérifie l'arbre source, le digest de l'artéfact, et le résultat de conformité 536-test / 8,580-assertion. Les autres plateformes restent non liées.
Référence ouverte
kotoba id
Créer un plan d’inscription principal Kotoba neutre à la chaîne contrôlé par une clé d’accès. Les comptes intelligents sont des liens CAIP-10 explicites ; aucune chaîne ni fournisseur n’est la racine d’identité.
Référence ouverte
kotoba compile
Compiler la source de la famille Kotoba en un artefact cible. Le .kotoba Web utilise KIR vérifié et le backend restreint kotoba-script ; .cljs reste ClojureScript.
Référence ouverte
kotoba check
Validez la source Kotoba, les contrats ou les métadonnées du paquet sans l'exécuter. Adaptateur compilateur : admission frontend + --profile pure-product (T9.2).
Référence ouverte
kotoba graph
Interroger et transacter le magasin de graphes de langage (kgraph) avec des opérations en forme de Datomic.
Référence ouverte
kotoba git
Exposez les opérations du dépôt Kotoba comme données, pas comme comportement spécifique au shell.
Référence ouverte
kotoba rad
Exécutez des flux de travail de développement rapide d'applications sur les paquets Kotoba.
Référence ouverte
kotoba build
Construisez un projet Kotoba en son artéfact cible vérifié. C'est la commande directe du cycle de vie du projet ; rad build reste une orthographe compatible.
Référence ouverte
kotoba test
Vérifiez et exécutez les tests admis pour un projet Kotoba. C’est la commande directe du cycle de vie du projet ; rad test reste une orthographe de compatibilité.
Référence ouverte
kotoba deploy
Planifier et appliquer l'état désiré du paquet à un reçu local ou à une cible résidente de flotte murakumo.
Référence ouverte
kotoba library
Inspecter et publier un espace de noms de bibliothèque adressé par contenu via la base de code Kotoba existante et le chemin de publication IPNS.
Référence ouverte
kotoba hinshitsu
Exécuter des contrôles de qualité logicielle (preuves, portes, couverture, régression visuelle) en tant que données.
Référence ouverteancre de fermeture binaire stdlib
Nom public standard de bibliothèque cœur borné.
Référence ouverte:commande/inconnue
La commande demandée ne fait pas partie du contrat CLI public. Utilisez une commande générée à partir de lang/cli.edn.
Référence ouverte:contract/invalid
Le contrat CLI a échoué à la validation structurelle. Inspectez la collection structurée :errors ; ne lancez pas la commande.
Référence ouverte:version/non supporté
La version de langue ou de contrat de package demandée est inconnue. Sélectionnez une version listée sous :supported dans lang/version-policy.edn.
Référence ouverte:version/supprimé
La version de contrat demandée a été supprimée. Migrez vers la version active avant de compiler ou d'exécuter.
Référence ouverte:version/dépréciation-expirée
La fenêtre de compatibilité pour une version dépréciée a expiré. Appliquez la migration nommée par la politique de version.
Référence ouverte:release/invalid-semver
Un identifiant de version n'est pas un SemVer strict. Utilisez MAJOR.MINOR.PATCH avec un suffixe pré-version ou de build valide optionnel.
Référence ouverte:docs/no-release-bound-profile
Aucune preuve d’implémentation publiée ne lie le profil de langue actif. Gardez le défaut public bloqué jusqu’à ce qu’une enveloppe de version signée lie l’implémentation et le profil.
Référence ouverte:docs/link-missing
Un document vérifié pointe vers une cible locale manquante. Restaurez la cible ou mettez à jour la carte d'autorité et régénérez la référence.
Référence ouverte:docs/profile-version-drift
Les autorités de grammaire, surface et élaboration ne sont pas d'accord sur le profil linguistique. Réconciliez les autorités avant de publier la documentation.
Référence ouverte:docs/generated-drift
Une référence générée engagée ne correspond pas à son autorité machine. Exécutez nbb scripts/generate-docs-reference.cljs et engagez le résultat.
Référence ouverte:docs/validation-result-invalid
Une observation de validation utilisateur est incomplète ou surestime un résultat externe. Enregistrer la classe de participant, la tâche, le résultat, la preuve et le temps observé.
Référence ouverteAucune requête ne quitte le navigateur.
Feuille de route : élargir seulement après que la frontière tient
Un contrat versionné
Gardez la grammaire, les effets, KIR vérifié, adaptateurs cibles, qualification et documentation du premier lancement alignés.
Combler les lacunes des fournisseurs
Étendre la conformité typée demande/résultat, tests adverses, reçus, révocation, et opérations de version reproductibles.
Obtenir un déploiement plus large
Élargir l'utilisation en production après fournisseur, isolation hôte, retour en arrière et preuve d'immersion — et développer des bibliothèques déclaratives inspectables.
Lire la feuille de route maintenue et les non-objectifs
Les éléments de la feuille de route sont une direction, pas des promesses de capacité livrée ou de dates de livraison.
Construire la communauté en public
Kotoba ne revendique pas encore une grande communauté. Aujourd'hui, les points de rencontre publics honnêtes sont les dépôts sources, les traqueurs de problèmes, l'historique des versions et le canal de sécurité.
Problèmes linguistiques
Poser une question de conception, proposer une amélioration documentaire ou signaler un problème reproductible de contrat linguistique.
Questions ouvertes sur le langageProblèmes du compilateur et du CLI
Suivre le travail d'implémentation, les versions, le support cible, et l'intégration runtime dans l'implémentation installable.
Questions ouvertes d’implémentationRapporter en privé
Utilisez la politique de sécurité publiée pour les vulnérabilités ; ne divulguez pas de détails exploitables dans un problème public.
Lire la politique de sécuritéFinancer la frontière publique, sans acheter d'autorité
Le profil Sponsors Kotoba GitHub est en préparation. La page du projet est prête maintenant et exposera une action de paiement seulement après que GitHub approuve le profil de l'organisation.
Sponsors GitHub
Aucun paiement de parrainage ne peut être effectué via kotoba-lang.org tant que le profil GitHub n'est pas actif.
Le support n’est pas une autorité
Le parrainage n'achète pas une fonctionnalité, une priorité de feuille de route, un SLA de support, un accès privé ou une exception de sécurité.
Statut de parrainage : PRÉPARATION. Vérifié 2026-09-01.
Code sûr. État de confiance. Exécution contrôlée.
Preuves avant slogans
Lire des notes d’ingénierie courtes qui relient les revendications produit aux mesures, fichiers d’autorité et portes restantes.
Lire le blog KotobaExécution contrôlée
Kotoba Cloud connecte identité et contrôle de déploiement à l'environnement d'exécution. La découverte est en direct ; l'application hébergée n'est pas encore offerte. Le calcul reste fourni par des services gouvernés séparément.
Ouvrir Kotoba CloudÉtat du graphe de confiance
Kotobase est la base de données graphe adressée par contenu pour l'état et la connaissance de l'IA : relations explicites, historique identifiable et accès limité.
Ouvrir KotobasePlan de calcul et d'inférence
Infrastructure de calcul et de service de modèle de flotte. La disponibilité et la qualification de la route restent spécifiques au service.
Ouvrir MurakumoPlan de travail de l'agent
Travail continu de l'agent à travers espaces de travail, objectifs, preuves, outils, approbations et effets gouvernés.
Ouvrir ItonamiCes services conservent des frontières distinctes d’autorité, de disponibilité et de qualification. Leur connexion ne prouve pas que chaque capacité Kotoba est disponible comme service hébergé vendu généralement.
Lire le contrat ou exécuter l'implémentation
kotoba-lang/kotoba-lang
Grammaire, sémantique, contrats de capacité, revendications de sécurité, contrat CLI, documentation, et fixtures de conformité.
Lire l'autorité linguistiquekotoba-lang/kotoba
CLI, intégrations hôtes, fournisseurs, adaptateurs d’exécution, tests d’intégration et preuves de qualification spécifiques à la cible.
Ouvrir l'implémentationApprendre, construire ou évaluer
Chemins séparés pour la première utilisation, la référence linguistique, l'implémentation backend, les frontières de sécurité et les preuves de maturité.
Choisir un chemin de documentationProfil linguistique 6; statut de publication par défaut public : PUBLIÉ.
La plateforme portable principale est WebAssembly Components avec WASI 0.3.0. La chaîne d'élaboration a 11 étapes nommées, à échec fermé.