Sicherer Code. Entwickelt für Maschinengeschwindigkeit.

KI kann schneller schreiben, als Menschen prüfen können

Generierter Code kann nützlich sein und dennoch eine Datei, ein Netzwerk, ein Geheimnis, einen Prozess, ein Modell oder eine Zahlungsoberfläche erreichen, die die Anfrage nie offenlegen wollte.

Kotoba ergänzt Laufzeit- und OS-Isolation; es macht diese Schichten nicht überflüssig.

Wo sich Lisp's Geist und GP 2's Graph-Umformung mit Rusts Disziplin treffen

Kotoba ist eine kleine, datenorientierte, Clojure-geformte Sprache. Ihr Design basiert auf der Lisp-Tradition von Code-als-Daten und GP 2's regelbasierte Graphumschreibung, mit statischer Disziplin rund um Autorität, Effekte, Ressourcen, Pakete und Artefaktidentität.

SICHER + SCHNELL · FÜR KI-GENERIERTE SOFTWARE ENTWICKELT.

Dies ist eine Einschränkungsanweisung, keine 'unhackbare' Behauptung. Compiler, Verifizierer, Laufzeit, Anbieter, Richtlinienwurzeln, Schlüsselverwaltung und OS-Isolation bleiben Teil der vertrauenswürdigen Rechenbasis.

Sicherheit über die gesamte Berechnung hinweg

Die Grenze wird von der Absicht bis zur Ausführung getragen. Jede Stufe verengt oder überprüft die Autorität; keine spätere Stufe darf eine Berechtigung erfinden.

Inhaltsidentität ist keine Autorität.

CID-Verifizierung, Signaturen, Widerruf, Host-Policy, Ressourcenprüfungen und OS-Isolation bleiben separate Grenzen.

Lisp-Auswertung, ohne ambient-host-Auswertung

Kotoba wertet geprüften Code als inhaltsadressierte Daten aus. Das vertraute (eval request) Oberfläche senkt sich zum Typisierten :code/eval Fähigkeit; es empfängt niemals Quelltext, eine Leserform, einen Namensraum oder ein Host-Objekt.

Identität, Autorität und Ergebnisnachweis sind drei verschiedene Fakten.

Maschinenvertrag: lang/typed-eval.edn. Compiler-Drahtfähigkeit: 30. Begrenzte Anwendung bleibt gewöhnliche geschlossene Modulabschlussanwendung.

Standards für einen KI-zentrierten Computing-Stack

Dies sind technische Ansprüche mit angehängter Qualifikation. Standard, grenzwertbereit, teilweise und Richtung sind unterschiedliche Zustände; keiner wird stillschweigend zum universellen Anspruch befördert.

Maschinenautorität: lang/product-defaults.edn. Unbegrenzter physischer Speicher, null Kopien überall, universeller Geschwindigkeitsrang, AGI erreicht und nicht hackbar bleiben verbotene absolute Behauptungen.

Was KI-geschriebene Kotoba nicht anfragen kann

Dies sind benannte Sicherheitsbeschränkungen in lang/surface-status.edn, keine fehlenden Funktionen in einer Roadmap.

Beweis, mit angehängter Grenze

Kotoba trennt Implementierungsnachweise vom Marktdurchdringung und hält Rest-Risiko neben jedem Sicherheitsanspruch.

Interne Produktionsnutzung ist nur Beweis für Dogfooding. Sie impliziert keine externen Kunden, bezahlte Pilotprojekte oder Einnahmen.

Fünf Benchmarks. Fünf verschiedene Fragen.

Compiler-Start fragt, wie schnell eine winzige Quelle zu einem Artefakt wird. Skalierung des Builds fragt, was mit dieser Zahl passiert, wenn die Quelle nicht mehr winzig ist – und ob das Artefakt noch antwortet. Die Entwicklerschleife trennt Auflösung, Prüfung, Builds und erstes Ergebnis. Native Laufzeit fragt, wie schnell bereits gebauter Code läuft. Die Workload-Domänen-Suite fragt, wie Strings, Sammlungen, Allokation, I/O, Nebenläufigkeit und eine kleine reale Anwendung sich verhalten. Die Ergebnisse halten alle fünf Fragen – und deren Beweisstatus – getrennt.

Build-Zeit, wenn die Quelle größer wird

Die obigen Benchmarks erstellen ein Programm, das klein genug ist, um auf einen Bildschirm zu passen, was misst, wie schnell eine Toolchain startet. Es sagt wenig über die Zahl, auf die ein Entwickler tatsächlich wartet, was die Steigung ist. Dieses fünfte Benchmark erzeugt dasselbe Programm in zunehmenden Größen — K unabhängige Vier-Operationen-Funktionen und ein Einstiegspunkt, der ruft sie alle auf — und baut es durch jede Toolchain auf dem Host, in rotierende Reihenfolge.

Es führt dann aus, was jede Toolchain produziert hat, nachdem die Uhr gestoppt wurde. Diese Prüfung ist keine Dekoration. Der schnellste Weg, ein Artefakt zu erzeugen, ist ein defektes ausgeben, sodass eine Bahn, die nicht mehr funktioniert, sonst posten würde seine besten Zahlen genau dort, wo es aufgehört hat zu funktionieren.

Beide Achsen sind logarithmisch: Die Quellen erstrecken sich über drei Größenordnungen, ebenso die Zeiten. Eine Linie endet in einem Punkt, wo der Lauf endete, in einem Kreuz, wo diese Spur ein Artefakt erzeugte, das nicht das Programm ist, und in einer Leiste, wo die Toolchain den Build verweigerte. Diese drei sind nicht dasselbe Ereignis und die beiden untenstehenden Fehler sind nicht derselbe Fehler.

Gemessen 2026-08-31 auf judahnoMac-mini.local (Apple M4). K ist die Anzahl generierter Funktionen; die Kotoba Quelle läuft von 9 bis 14338 Zeilen. Ziele, ABIs, Optimierungsstufen und Laufzeitverträge unterscheiden sich zwischen Bahnen, daher fragt dies nach Entwickler-Feedback-Latenz, nicht äquivalenter Arbeit. Das Host-Last-Gate schlug fehl (load1 2.73–2.73, erforderlich ≤ 1), daher sind dies Beobachtungen dieses Laufs und keine portablen Werte. Da die Bahnen verflochten sind, wird die Reihenfolge separat qualifiziert.

Welche Reihenfolgen den Rauschtest überstehen

Ein Verhältnis ist keine Rangfolge. perfgate verweigert jede Ordnung, deren Lücke innerhalb der eigenen Spannweite der beiden Arme liegt, so groß das Verhältnis auch aussieht, und lehnt einen Arm mit zu wenigen Proben ab oder zu viel Rauschen. Es läuft hier mit seiner eigenen Standardrichtlinie, unentspannt — ein Schwelle gelockert, um dies durchlaufen zu lassen, wäre ein Benchmark, der misst seine eigenen Schwellenwerte. Da die Lanes auf einem Host verflochten sind, entsteht eine Lücke wer diesen Test besteht, übersteht es, wenn der Host beschäftigt ist.

Verbesserung-unter-Schwelle bedeutet, dass die Kotoba Lane bei dieser Größe überhaupt nicht schneller war. Der Vorteil ist real und qualifiziert beim Kaltstart, und er ist gegen C bei K=32 und gegen Rust bei K=128 verschwunden. Dieser Kreuzungspunkt ist das Ergebnis, daher wird er gezeigt und nicht zusammengefasst.

Zwei Fehler, die nicht derselbe Fehler sind

Drei Kotoba-Spuren funktionierten in diesem Lauf nicht mehr, und sie als eine zu veröffentlichen Reihe wäre falsch gewesen. Eine ist ein Defekt. Die anderen beiden sind erklärt Grenzen werden genau wie angegeben durchgesetzt und als Defekte gemeldet würde bedeuten, die Grenzen statt des Compilers zu messen.

Was dies etabliert

Fazit: Bei der kleinsten Größe ist das veröffentlichte Binär schneller als jeder Vergleich hier mit einem Abstand, der den Rauschtest übersteht, und es hat eine harte Korrektheitsgrenze bei 128 Funktionen. Der Compiler ohne diese Obergrenze ist bei jeder Größe ungefähr eine Größenordnung langsamer gemessen. Beide Fakten stammen vom selben Lauf, und das Testgerüst, das sie fand, ist öffentlich, damit dem Lauf widersprochen werden kann.

Wie lange jede native Arbeitslast tatsächlich dauert

Das untenstehende Raster berichtet die Marge zwischen zwei Armen. Das ist die Zahl perfgate-Regeln an, aber ein Prozentsatz allein sagt nicht, ob ein Arbeitslast läuft in fünf Millisekunden oder fünfhundert und verbirgt das Unterschied zwischen einem umstrittenen Paar und einem irrelevanten. Diese Panels sind die Mediane, aus denen diese Margen berechnet werden. Amu native ist die farbige Spur in jedem Panel — einschließlich der Panels, in denen es nicht zuerst ist. Jedes Panel ist skaliert auf seinen eigenen langsamsten Arm, weil die Frage, die ein Gremium beantwortet, ist, wer schneller bei dieser Arbeitslast.

Median Millisekunden über 5 host-qualifizierte Läufe; kürzer ist schneller. Jeder Arm lieferte dieselbe unabhängig geprüfte Antwort, und der Kandidaten-Median ist ein Wert pro Arbeitslast — das Suite rotiert jedes Engine-Paar in ABBA/BAAB-Reihenfolge, sodass dasselbe Amu-Artefakt einmal pro Arbeitslast getimt und dann gegen jeden Arm verglichen wird. Im Gegensatz zu den anderen vier Benchmarks auf dieser Seite hat dieses das Quiet-Host-Gate BESTANDEN (qualifiziertes Host-Load), daher sind dies Werte für diesen Host und nicht nur Beobachtungen. Die begrenzte schnellste Behauptung benötigt noch alle 30 Paare, wofür das untenstehende Raster ist.

Jedes Laufzeitpaar, Gewinn oder Verlust

Die begrenzte Behauptung ist Alles-oder-Nichts, daher macht ein einzelnes nicht qualifiziertes Paar sie falsch. Nur dieses Urteil zu veröffentlichen würde verbergen, welche Paare umstritten sind, daher das Ganze Raster ist hier. Eine Zelle ist die durchschnittliche Verbesserung von Amu native gegenüber diesem Vergleichswert bei dieser Arbeitslast; positiv bedeutet Amu ist schneller, und ein Häkchen markiert die Paare, die klarer Perfgate — mindestens 5% und getrennt von der eigenen Streuung der Arme.

Jede Zelle ist eine Leiste, die von einer Mittellinie wächst: rechts davon ist Amu native schneller, links davon langsamer. Die beiden Richtungen sind separat skaliert — die Gewinne reichen bis +93% und die Verluste nur bis −7%, sodass eine gemeinsame Skala jedes umstrittene Paar in denselben unsichtbaren Schlitz flachen würde. Das Vorzeichen wird auch durch die Seite der Linie und durch die vorzeichenbehaftete Zahl getragen, sodass keine Lesung dieses Gitters davon abhängt, zwei Farben zu unterscheiden.

19 von 30 Paaren qualifiziert (Median von 5; 19 in jedem Lauf) · Kandidat 42f092ea5b61 · Apple M4, 10 logische CPUs, 16 GiB

Optimierungsbereitstellung nach dem veröffentlichten Lauf

Der oben datierte Benchmark bleibt unveränderlich. Neue Implementierungsschnitte werden separat gelistet, bis die Suite mit demselben Artefakt neu läuft und ihre Qualifikationstore besteht.

Compiler-Start, vier Toolchains

KOTOBA 0.7.3 · RUSTC 1.97.1 · Homebrew clang Version 22.1.7 · javac 24.0.2. Kotoba, Rust und C erzeugen Wasm; javac erzeugt eine Klassendatei. Unterschiedliche Ziele und Compiler-Arbeiten machen dies zu einer Startbeobachtung, nicht zu einer universellen Rangfolge. Das aufgezeichnete Host-Last-Tor ist fehlgeschlagen, daher ist die Tabelle kein qualifizierter Geschwindigkeitsrang.

Jedes ausgegebene Artefakt erzeugte 42 in einem frischen Prozess. Ziele und Laufzeitverträge unterscheiden sich; N/A ist nie Null. Das Host-Lade-Gate ist fehlgeschlagen, daher sind dies reproduzierbare Beobachtungen und kein sprachübergreifendes Geschwindigkeitsranking.

Sechs Bereiche nebeneinander

Jedes Panel wird an seine eigene langsamste Spur angepasst, weil die Frage eines Panels Antworten sind, wer in diesem Bereich schneller ist, nicht wie die Bereiche miteinander verglichen werden andere. Kotoba's Spur ist die farbige in jedem Panel — einschließlich des Panels, wo es zuletzt ist. Sein eigenständiges Wasm-Artefakt läuft durch einen Node hostet und bezahlt diesen Start bei jeder prozesskalten Probe, während Rust, C und Go als native Binärdateien ausführen; wo das Ziel kein Umgebungsdateisystem oder Thread Vertrag überhaupt nicht, die Spur ist abwesend statt null.

Prozess-kalte Mediane in Millisekunden; kürzer ist schneller. Das Host-Last-Gate bei diesem Lauf fehlgeschlagen, daher sind diese Panels Beobachtungen und keine Rangliste, und die amortisierte Lane unten erzählt wieder eine andere Geschichte.

Jede Probe lieferte die exakte Referenzprüfsumme zurück. Kotoba verwendet sein erzeugtes Wasm und deklarierte typisierte ABI; sein eigenständiges Ziel hat kein Umgebungsdateisystem oder Thread-Vertrag, daher werden diese Zellen als N/A betrachtet. Das aufgezeichnete Host-Load-Gate schlug fehl, daher sind Mediane Beobachtungen, keine Rangfolge.

Jede größere In-Prozess-Batch wird durch ihren deklarierten Arbeitslast-Multiplikator geteilt. Dies amortisiert den Start, entfernt aber nicht vollständig Prozess-, VM- oder Wasm-Instanziierungskosten, daher wird es nicht als perfekt erwärmtes Gleichgewichtsergebnis bezeichnet. Kotoba's reine ink/dec Map-Ketten sind in reduce ohne Zwischenvektoren verschmolzen; Rückrufe außerhalb dieser bewiesenen Teilmenge behalten eifrige Materialisierung bei.

Was die native Suite abdeckt

Jede Implementierung liefert eine unabhängig geprüfte bekannte Antwort. Die Suite rotiert jedes Motorpaar in ABBA/BAAB-Reihenfolge und misst nach Laden, Mapping und Symbolsuche.

Wo jeder Benchmark lebt

Jede obige Zahl stammt aus einem öffentlichen Harness und einem festgeschriebenen Bericht, daher ein Der Lauf kann wiederholt werden und einer Behauptung kann widersprochen werden. Die Pfade im Repository in diese Tabelle wird gegen den Arbeitsbaum geprüft, wenn diese Seite generiert wird: Ein Harness, das Fehler zum Build-Abbruch führt, anstatt einen toten Link zu liefern.

Das Tor, durch das jede Reihenfolge auf dieser Seite geht, ist kotoba-lang/perfgate, läuft mit seiner eigenen nicht gelockerten Standardrichtlinie. Eine Schwelle wurde gelockert, um ein Ein Durchlauf wäre ein Benchmark, der seine eigenen Schwellenwerte misst.

Fazit: Die Artefakte, exakten Ergebnisse und Proben sind in allen fünf Benchmarks real. Drei davon — Compiler-Start, Entwickler-Schleife und Arbeitslast-Domänen — haben ihr ruhiges Host-Tor nicht bestanden, daher rangieren sie nichts und werden als Beobachtungen veröffentlicht. Die native Laufzeitsuite hat ihr Tor bestanden und gewinnt 19 von seinen 30 Paaren, knapp unter der Behauptung für jedes Paar, die sie bräuchte. Die Bau-Skalierung qualifiziert ihre Kaltstart-Reihenfolge gegen jeden Vergleichswert auf dem Host und findet eine Korrektheitsdecke im selben Lauf. Kein universeller Geschwindigkeitsrang wird auf dieser Seite beansprucht, und keiner dieser Läufe erlaubt einen solchen.

Behauptungen mit ihren angehängten Grenzen

Diese Ansprüche werden generiert aus lang/safety-claims.edn. Jede behält ihre vertrauenswürdige Rechenbasis und das Restrisiko sichtbar, denn ein Sicherheitsslogan ohne Grenze ist nur Marketing.

Qualifikation Q1, Stand 2026-07-18.

Release-Bindung

Ein Sprachprofil und eine Implementierungsversion sind getrennt, bis ein signierter Umschlag sie verbindet.

Kotoba v0.7.0 für darwin-arm64 ist die öffentliche Implementierung, gebunden an das Sprachprofil 6 und den Paketvertrag 1. Sein signierter Umschlag überprüft den Quellbaum, den Artefakt-Digest und das 536-Test- / 8,580-Assertions-Konformitätsergebnis. Andere Plattformen bleiben ungebunden.

Starte in sechzig Sekunden

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

(defn main []
  (+ 40 2))

Lernen, ausprobieren, dann tiefer gehen

Ein verbundener Pfad vom ersten Programm zu Sprachverträgen, Bibliotheken, Belegen und Bereitstellungsoberflächen.

Ein kleines Kotoba Programm, läuft real

Amu kompiliert diesen reinen Kotoba-Quellcode zum wasm32-Browser-Profil. Das eingecheckte Artefakt hat keine Importe und gibt 42 zurück.

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

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

(defn main []
  (double 21))

Bibliotheken, ohne die Paketgrenze zu verbergen

Kotoba Bibliotheken sind inhaltsadressierte Graphen. Namen und GitHub Repositorien helfen Menschen, sie zu entdecken; Definition und signierte Release-CIDs sagen genau, was sie sind.

Durchsuchen Sie die gesamte Organisation nach Tag

Es gibt 2,215 öffentliche Repositorien in der kotoba-lang Organisation. Jeder untenstehende Tag ist das GitHub Thema von derselbe Name, sodass der Seitenfilter und die Themen der Organisation ein Vokabular sind statt zwei, die abdriften. Wähle eine, um den bereits gefilterten Katalog zu öffnen.

Durchsuchen und filtern Sie alle 2,215-Repositorys

Ein Repository ist kein veröffentlichtes Paket. Genau 1 Bibliothek wird über das inhaltsadressierte Register veröffentlicht; der Rest dieser Liste ist Entdeckung. Reifegrad-Labels von Repositories implizieren keine 1.0 API-Stabilität, breite Akzeptanz oder Produktions-SLOs, und 255 Repositories entsprechen keiner Domänenregel und werden unmarkiert statt mit dem nächstgelegenen Label angezeigt.

Die geprüfte Referenz durchsuchen

Befehle, Standardbibliotheksnamen, Diagnosen und Veröffentlichungsstatus durchsuchen. Der Index wird aus Maschinenautoritäten generiert und bleibt auf dieser Seite.

Keine Abfrage verlässt den Browser.

Fahrplan: Erweiterung nur, wenn die Grenze hält

Lies die gepflegte Roadmap und Nicht-Ziele

Roadmap-Punkte sind Richtungen, keine Versprechen gelieferter Fähigkeiten oder Termine.

Baue die Gemeinschaft öffentlich auf

Kotoba beansprucht noch keine große Gemeinschaft. Heute sind die ehrlichen öffentlichen Treffpunkte die Quell-Repositorys, Issue-Tracker, Versionshistorie und der Sicherheitskanal.

Erkunde alle öffentlichen Kotoba Repositorien

Finanzieren Sie die öffentliche Grenze, ohne Autorität zu kaufen

Das Kotoba GitHub Sponsorenprofil wird vorbereitet. Die Projektseite ist jetzt bereit und zeigt eine Zahlungsaktion erst, nachdem GitHub das Organisationsprofil genehmigt hat.

Sponsoring-Status: VORBEREITUNG. Geprüft 2026-09-01.

Sicherer Code. Vertrauenswürdiger Zustand. Kontrollierte Ausführung.

Diese Dienste behalten separate Autoritäts-, Verfügbarkeits- und Qualifikationsgrenzen. Ihre Verbindung ist kein Beweis dafür, dass jede Kotoba-Fähigkeit als allgemein verkauftes gehostetes Service verfügbar ist.

Lesen Sie den Vertrag oder führen Sie die Implementierung aus

Sprachprofil 6; öffentlich-standard Veröffentlichungsstatus: VERÖFFENTLICHT.

Die primäre portable Plattform sind WebAssembly Komponenten mit WASI 0.3.0. Die Elaborations-Pipeline hat 11 benannte, fail-closed Stufen.