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

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

(defn main []
  (double 21))

исходный CID bafkreiaeohkv2zu… IPFS CIDv1 · raw · sha2-256 файла hello.kotoba
исходник SHA-256 0471d55d668ed5f9… sha-256 точного файла, показанного здесь
проверенный KIR SHA-256 92635333e1e0da86… типизированное, проверенное по эффектам представление, допущенное компилятором
идентичность артефакта SHA-256 cfea3b89cc022a6b… связывает источник, политику, контракт компилятора и ABI цели

Исходный CID открывает hello.kotoba. Хэши SHA-256 идентифицируют исходные байты, проверенный KIR и идентичность артефакта; это не IPFS адреса.

БЕЗОПАСНО + БЫСТРО · СОЗДАНО ДЛЯ ПО, СГЕНЕРИРОВАННОГО ИИ

Безопасный код. Создан для машинной скорости.

Kotoba — язык в форме Lisp, разработанный для безопасного, сверхбыстрого ПО, сгенерированного ИИ. Просматриваемые программы, явные возможности и артефакты с адресацией по содержимому связывают проверки компилятора с контролируемым выполнением.

САМЫЙ БЫСТРЫЙ ХОЛОДНЫЙ БИЛД · 4 ИЗ 4 КВАЛИФИЦИРОВАННЫХ УПОРЯДОЧИВАНИЙ

Самая быстрая холодная сборка любой цепочки инструментов на этом хосте.

11.75мс

Kotoba от исходника до артефакта WebAssembly, холодный процесс — затем выполнено, и ответ проверен после остановки часов.

KotobaВыпущенный CLI · WebAssembly 11.75 msсамый быстрый здесь
C / ClangНативный хост 29.08 ms2.5× Kotoba
Rust / rustcWebAssembly 38.99 ms3.3× Kotoba
Rust / rustcНативный хост 56.02 ms4.8× Kotoba
JVM / javacJVM класс 171.53 ms14.6× Kotoba

Время холодной сборки процесса в миллисекундах; меньше — быстрее. K=1 исходников, каналы перемежаются на одном хосте, 7 образцов каждый.

Все 4 упорядочивания проходят perfgate на своей неослабленной политике по умолчанию — как минимум 5% и отделена от собственное распределение рук — поэтому порядок сохраняется, даже если хост был занят. Ограничено этим хостом, размером исходника и этим запуском: время сборки не скорость выполнения, преимущество сужается по мере роста исходника, и выпущенный бинарный файл имеет жёсткий потолок корректности. Все пять эталонов, включая те которые противоречат Kotoba, приведены ниже. Измерено 2026-08-31 включено Apple M4.

Смотреть пять бенчмарков Просмотреть образцы

Когда ИИ непрерывно генерирует, собирает, тестирует и регенерирует код, задержка сборки становится пропускной способностью инфраструктуры.

Установить и запустить Посмотреть, как это работает Настройка ИИ-агента

ОТКАЗ ПО УМОЛЧАНИЮ

Отсутствие амбиентных полномочий

Нет неявного доступа к файловой системе, сети, процессу, часам, модели или секретам.

ПРОВЕРЕННЫЙ KIR

Авторитет сохраняется после компиляции

Типы, эффекты, ресурсы и поддержка целей допускаются до эмиссии.

ПОДТВЕРЖДЕНО ХОСТОМ

Привязана только грань

Хост и провайдер обеспечивают конкретный объем и фиксируют решение.

ПОСТКВАНТОВЫЙ УРОВЕНЬ

Нет понижения только до классического

Новые границы шифрования и публикации требуют доказательств ML-KEM или ML-DSA и отвергают очищенный PQ материал.

01 Проблема

ИИ может писать быстрее, чем люди могут проверять

Сгенерированный код может быть полезен и при этом достичь файла, сети, секрета, процесса, модели или платежной поверхности, которую запрос никогда не намеревался раскрывать.

СТАРЫЙ ПО УМОЛЧАНИЮ

Стройте широко, ограничивайте позже

Общего назначения программа начинается с окружающей семантики. Вокруг нее добавляются песочницы, IAM, контейнеры, политика и подпись для восстановления предполагаемой границы.

СТАНДАРТ KOTOBA

Дать узко, затем скомпилировать

Эффекты и возможности являются частью допущенного вычисления. Если цель не может доказать и связать грант, она не испускает и не запускает артефакт.

Kotoba дополняет изоляцию времени выполнения и ОС; он не делает эти уровни ненужными.

Где встречаются разум Lisp и графовое переписывание GP 2 с дисциплиной Rust

Kotoba — небольшой, ориентированный на данные язык в стиле Clojure. Его дизайн опирается на традицию Lisp с кодом как данными и Правила графового переписывания GP 2, со статической дисциплиной вокруг полномочий, эффектов, ресурсов, пакетов и идентичности артефактов.

ИНТУИТИВНЫЙ

Код как читаемые данные

Неизменяемые значения, обычные функции, явные данные и композиционный синтаксис легко создавать и проверять людям и моделям.

ДЕКЛАРАТИВНЫЙ

Сказать, что может произойти

Эффекты, возможности, ресурсы, зависимости и цели видимы при допуске — это не сюрпризы, обнаруженные после развертывания.

ПРЕЖДЕ ВСЕГО БЕЗОПАСНОСТЬ

Меньше языка, жёстче граница

Нет амбиентной интероперабельности, загрузки кода во время выполнения, неограниченных мутаций, макросов, определённых гостем, или неограниченной параллельности в принятой поверхности компонента.

БЕЗОПАСНО + БЫСТРО · СОЗДАНО ДЛЯ ПО, СГЕНЕРИРОВАННОГО ИИ.
Это направление ограничения, а не утверждение о «невзламываемости». Компилятор, верификатор, время выполнения, провайдеры, корни политики, хранение ключей и изоляция ОС остаются в доверенной вычислительной базе.

02 Как работает граница

Безопасность во всей вычислительной операции

Граница переносится от намерения к выполнению. Каждый этап сужает или проверяет полномочия; на более поздних этапах не разрешается изобретать грант.

1 · ИСХОДНИК

Декларативное намерение

Небольшая поверхность в форме Clojure сохраняет программы читаемыми и исключает фоновые лазейки для побега.

2 · ПРОВЕРКА

Проверенный KIR

Типы и транзитивные эффекты становятся независимым от цели, инспектируемым представлением.

3 · ДОПУСК

Пересечение авторитета

Запрошенные, делегированные, локальная политика, ресурсы и целевые гранты могут только сужать.

4 · ИДЕНТИФИКАЦИЯ

Обратиться к артефакту

Код, зависимости, политика, контракт компилятора и ABI цели связывают идентичность вычисления.

5 · ПРИНУЖДЕНИЕ

Привязка к хосту

Время выполнения и провайдер связывают только допущенные возможности, обеспечивают конечные бюджеты и выдают квитанции.

Идентичность содержимого не является авторитетом.
Проверка CID, подписи, отзыв, политика хоста, проверки ресурсов и изоляция ОС остаются отдельными границами.

Вычисление Lisp без амбиентного вычисления хоста

Kotoba оценивает проверенный код как данные с адресацией по содержимому. Знакомый (eval request) поверхность снижается до типизированного :code/eval возможность; он никогда не получает исходный текст, форму для чтения, пространство имён или объект хоста.

DEFINITION CID

Какой код?

CID выбирает проверенное по хэшу определение checked-KIR и его зависимость только по CID.

CID ПРИЕМА

Можно ли это запустить здесь?

Точный интерфейс, полный ряд эффектов, текущие разрешения, топливо и уменьшающаяся глубина оценки фиксируются до выполнения.

CID ЗНАЧЕНИЯ

Что вернулось?

Типизированный результат сохраняется как доказательство с адресацией по содержимому. Его хэш не может ретроактивно авторизовать эффект.

Идентичность, полномочия и доказательства результата — три разных факта.

Контракт машины: lang/typed-eval.edn. Возможности компилятора по проводам: 30. Ограниченное применение остаётся обычным применением замыкания закрытого модуля.

Настройки по умолчанию для вычислительного стека с приоритетом ИИ

Это инженерные утверждения с прикрепленной квалификацией. По умолчанию, bounded-ready, partial и direction — разные состояния; ни одно не продвигается молча до универсального.

ИЗМЕРЕННОЕ НАПРАВЛЕНИЕ

Собирайте быстрее. Запускайте быстрее. Сохраняйте границу.

Kotoba публикует измерения запуска компилятора, цикла разработчика, нативного времени выполнения и домена нагрузки с проверками точных результатов. Текущие ранги скорости остаются скрытыми, пока не пройдут тихие шлюзы хоста; допуск безопасности никогда не снимается ради выигрыша по времени.

ГОТОВО ОГРАНИЧЕНО

Хранение без языкового ограничения.

Kotobase использует идентичность контента, чтение диапазонов, неизменяемую историю и нейтральное к провайдеру хранилище. Физическая емкость, аренда, хранение, стоимость, репликация и бюджеты выполнения остаются явными; это не претензия на бесконечный диск.

ПО УМОЛЧАНИЮ

Постквантовая криптография по умолчанию.

Каждая новая криптографическая граница Kotoba должна называть доказательства ML-KEM или ML-DSA и отвергать классический даунгрейд. Существующие Passkey, транспорт, реализации и хранение ключей остаются отдельно квалифицированными границами.

ПО УМОЛЧАНИЮ

Аутентификация присутствует. Авторитет по умолчанию отклонён.

Идентичность Passkey принадлежит к границе управления. Проверенная идентичность по-прежнему не получает файловую систему, сеть, хранилище, модель, секрет, платеж или GPU-авторитет до тех пор, пока явное ограниченное разрешение не пройдет локальную политику и проверки хоста.

ГОТОВО ОГРАНИЧЕНО

Гибкая делегация, которая может только сужать.

Запрошенные, делегированные, локальная политика, ресурсы и целевые области пересекаются. Делегация может быть составной и ослабленной, но не может создавать амбиентные полномочия или расширять грант своего эмитента.

ГОТОВО ОГРАНИЧЕНО

Готово для Web3, цепочно-нейтрально в корне.

Стабильный главный Kotoba и контроллер Passkey являются основными. Аккаунты CAIP-10, ERC-1271 и ERC-6492 — явные доказательства связанных аккаунтов; адрес кошелька никогда не становится молчаливым полномочием хранения или исполнения.

РЕАЛИЗОВАНО ЧАСТИЧНО

Нулевое копирование, где позволяет владение; одна копия, где это требует граница.

Колонковые байтовые представления сохраняют вектор, прямой ByteBuffer и Uint8Array. Проекция Arrow может сохранять не сжатые буферы колонковыми через авторизованный путь озера Kotobase. Сетевой вход, распаковка, загрузка на GPU и неизменяемые постоянные обновления остаются именованными границами копирования.

РЕАЛИЗОВАНО ЧАСТИЧНО

Данные в форме стрелы. Явные CPU SIMD и нативные GPU ядра устройства.

На Apple M4 не сжатый, не допускающий null столбец Arrow float32 сохранял одну линейную память WebAssembly, в то время как Num выполнял явное ядро v128 f32x4 над срезом заимствованных значений без копий Arrow-to-SIMD; скалярный хвост покрывал оставшиеся строки. В трёх квалифицированных запусках той же нагрузки масштаба 262,147 элементов и артефакта это SIMD-ядро завершилось на 3.66-3.72x быстрее, чем скалярный Wasm. Это результат ядра и хоста, а не общее утверждение времени выполнения. Тот же ограниченный путь столбца также сохраняет один ArrayBuffer через свои CPU-представления, пересекает границу владения GPU с одной измеренной загрузкой WebGPU, выполняется на Metal и возвращает один четырёхбайтовый скаляр. Nullable столбцы, другие типы Arrow, удаление загрузки объединённой памяти, более широкие ядра и универсальная квалификация CPU/GPU остаются в ожидании.

ПО УМОЛЧАНИЮ

Искусственный интеллект в первую очередь. Агент-безопасен по умолчанию.

Kotoba предназначен для программ, написанных или управляемых ИИ-агентами и ботами. Чем сильнее модель, тем важнее явные эффекты, конечные ресурсы, ограничение возможностей, квитанции и обеспечение хоста.

НАПРАВЛЕНИЕ

Границы, готовые к AGI, не претензия на AGI.

Архитектура предназначена для явного сохранения авторитета по мере повышения возможностей моделей. Kotoba не утверждает, что здесь существует ИИ общего назначения, что сгенерированные программы заслуживают доверия, или что изоляция устраняет компилятор, среду выполнения, провайдера, хранение ключей и доверенную вычислительную базу ОС.

Авторитет машины: lang/product-defaults.edn. Неограниченное физическое хранение, нулевые копии везде, универсальный ранг скорости, достижение AGI и невозможность взлома остаются запрещёнными абсолютными утверждениями.

Что AI-созданный Kotoba не может запросить

Преднамеренно отсутствующая поверхность языка
Граница	Почему отсутствует
`compile, load, load-file, load-string, ns-resolve, read-string, require, resolve, use`	Компоненты не могут создавать код или полномочия из амбиентного состояния процесса. Исходные строки, формы чтения, загруженные пространства имён и скомпилированные объекты хоста никогда не были выведены по эффектам и не входят в определение CID. Допущенная операция `(eval request)` поэтому отдельна: она выбирает уже проверенный KIR по CID через :code/eval и повторно допускается хостом.
`., .., import, new`	Произвольный доступ к объектам и методам JVM/JS обходят допуск возможностей. Невозможно ослабить через выдачу грантов: interop никогда не достигает guard-component-ability-call, поэтому пересечение грантов, квитанции и отзыв не видят вызов. Пусто на wasm32 ABI (такого пути нет); несущая нагрузка на portable/trusted, где подмножество — единственная граница (отдельная песочница VM там не заявлена).
`alter-var-root, atom, binding, deref, dosync, ref, reset!, set!, swap!, var, volatile!`	Внешнее изменяемое состояние принадлежит провайдеру и регулируется возможностями/политикой; локальное состояние компонента должно использовать явно ограниченную модель. Инвариант — АМБИЕНТ, а не сама мутация. С 2026-09-02 это чтение имеет два следствия вместо одного. Ячейка, которая уходит, сохраняется или пересекает функцию, принадлежит провайдеру и остаётся на пути :state-kit-desugar (строка эффектов показывает :state, грант требуется при инстанцировании, дескрипторы возможностей отвергаются как сохранённые значения). Ячейка, которая этого не делает — (let [a (atom 0)] (swap! a + 1) @a) — не нуждается в хосте вообще: срез локального состояния 1 преобразует её в обычные let-переопределения, так что её наблюдает только прямой код, который её владеет, и ячейка не существует во время выполнения. atom / swap! / reset! / deref поэтому допускаются через преобразование и отвергаются в момент, когда ячейка могла бы уйти. ref / dosync / volatile! / binding / var / alter-var-root / set! не имеют решённой модели возможностей и остаются отвергнутыми с закрытым отказом.
`agent, future, locking, pmap, send, send-off`	Планирование компонентов и ресурсы должны оставаться под контролем tender и ограниченными. Ни определения CID, ни делегированные гранты не измеряют CPU или планирование; топливо на экземпляр, а амбиентные потоки бы его обходили. Способность структурированного запуска с суббюджетированным топливом проектируема, но не решена; путь расширения пока отсутствует.
`defmacro`	Безопасная поверхность компонента должна быть статически проверяема до выполнения. Неразрешимо: расширение выполняет код внутри компилятора (время сборки), а хэши CID определения после десугара типизированного KIR, поэтому неограниченные макросы выполняются рано и делают идентичность исходника непроверяемой. defdesugar (ограниченный чистый десугар) остается допустимой альтернативой.
`catch, throw, try`	Амбиентный throw/try/catch — это неотслеживаемый нелокальный контроль потока: он выходит из областей, которые инферируемая строка эффектов никогда не упоминает, и пропускает обязательства по разворачиванию (отзыв фасета пространства данных пока не проверен). Запрет распространяется на амбиентную форму. С 2026-09-02 возможность типизированного abort допускает головы через разработку: эффект появляется в инферируемой строке как :abort, и функция понижается до [:result T E], так что амбиентная форма не существует после разработки. Срез 2 (2026-09-02) сделал :abort распространяемым через вызовы и A-нормализовал прерывающий операнд или тест в let-привязку; ни один из них не расширяет инвариант, потому что распространяемый abort находится в строке вызывающего, а A-нормализованный — та же разработка в другой позиции. Там, где предусловие разворачивания имело бы значение, abort остается отклоненным — теперь для CALL так же, как и для throw.

Это именованные ограничения безопасности в lang/surface-status.edn, а не отсутствующие функции в дорожной карте.

03 Доказательства

Доказательство с прикреплённой границей

Kotoba отделяет доказательства реализации от рыночного проникновения и сохраняет остаточный риск рядом с каждым заявлением о безопасности.

Ядра 33

Внутреннее производство dogfooding

Более широкий стек Kotoba запускает 33 ядер вывода внутренне. Это доказывает, что команда управляет своим собственным стеком; это не рыночное проникновение, платное принятие или доход.

утверждения 8

Границы машинно-читаемы

Заявления о безопасности называют их доверенную вычислительную базу, отрицательные доказательства и остаточный риск вместо того, чтобы сводиться к лозунгу «взломать невозможно».

запрет по умолчанию

Нет гранта, нет эффекта хоста

Пустая политика не даёт прав на файловую систему, сеть, процессы, часы, модель или секретные полномочия. Провайдеры также должны проверять конкретный объём ресурсов.

Внутреннее производственное использование — только доказательство dogfooding. Не подразумевает внешних клиентов, оплачиваемых пилотов или дохода.

Пять бенчмарков. Пять разных вопросов.

Запуск компилятора спрашивает, как быстро один маленький исходник становится артефактом. Масштабирование сборки спрашивает, что происходит с этим числом, когда исходник перестает быть маленьким — и отвечает ли артефакт. Цикл разработчика разделяет разрешение, проверку, сборки и первый результат. Нативная среда выполнения спрашивает, как быстро работает уже собранный код. Набор тестов в домене нагрузки проверяет поведение строк, коллекций, выделения памяти, ввода-вывода, параллелизма и небольшого реального приложения. Результаты сохраняют все пять вопросов — и их статус доказательств — отдельно.

ЗАПУСК СБОРКИ · РАНГ НЕ КВАЛИФИЦИРОВАН

4 цепочек инструментов, 21 запусков каждая

Kotoba 40.998 мс · Rust 126.422 мс · C 146.324 мс · JVM 961.248 мс медиана.

21 вращающихся холодных образцов процесса · load1 30.79 → 39.79 · требуется ≤ 1 · 2026-08-29 · Apple M4

ВРЕМЯ ВЫПОЛНЕНИЯ · ПОКРЫТИЕ ПОЛНОЕ

Нагрузки 6 × компараторы 5

Amu native тестируется против Rust, Clang / C11, Zig, Go c-shared, Swift через одну общую нативную границу вызова.

30/30 пары компараторов/нагрузок · точные ответы проверены

СКОРОСТЬ ВРЕМЕНИ ВЫПОЛНЕНИЯ · 19/30 КВАЛИФИЦИРОВАНО

19 из 30 пар

Amu native выигрывает 19 из 30 пар компараторов/нагрузок минимум на 5%, отделён от собственного распределения рук. Заявление о bounded fastest требует каждую пару, поэтому остаётся неквалифицированным — количество является информативной половиной.

По крайней мере 2 из этих пар невозможно выиграть вообще. При узкой арифметике amu, Apple clang -O3 и rustc -O3 компилируют ядро в одну и ту же последовательность инструкций 61 — clang и rustc идентичны по байтам, amu отличается только номерами регистров. Запаса 5% над идентичным кодом не существует, поэтому ограниченное утверждение недостижимо, а не просто не выполнено.

Медиана 5 запусков с квалификацией хоста; оценка варьировалась от 19 до 20, и 19 из 30 пар квалифицированы в каждом запуске. Один шумный образец может дисквалифицировать несколько пар сразу, поэтому оценка одного запуска не точна для одной пары.

занятая CPU 0.090 → 0.069 → 0.076 · требуется ≤ 0.10 · 2026-09-07

ЦИКЛ РАЗРАБОТЧИКА · РАНГ НЕ КВАЛИФИЦИРОВАН

пути инструментальной цепочки 11

Разрешение зависимостей, проверка, чистые и без изменений сборки, а также первый результат после холодного запуска процесса записываются отдельно.

7 образцов на измеренном этапе · load1 20.84 → 24.49 · требуется ≤ 1

МАСШТАБИРОВАНИЕ СБОРКИ · НАЙДЕН ПОТОЛОК

исходные размеры 8

Та же программа от одной функции до 2048, построено каждым инструментальным набором на хосте и затем выполнено. Выпущенный бинарник имеет здесь наименьшую стоимость холодного старта и корректность потолок над функциями 128.

артефакты проверены после остановки часов · load1 2.73 → 2.73 · требуется ≤ 1 · 2026-08-31

ДОМЕНЫ НАГРУЗКИ · РАНГ НЕКВАЛИФИЦИРОВАН

6 доменов × 6 путей выполнения

Проверяется корректность строк, коллекций, выделения памяти, файлового ввода-вывода, параллелизма с четырьмя рабочими и ядра приложения политики допуска запросов.

7 образцов в обеих дорожках process-cold и amortized · load1 13.87 → 12.38 · рейтинг не раскрыт

Время сборки с увеличением исходного кода

Приведённые выше бенчмарки создают программу, достаточно маленькую, чтобы поместиться на одном экране, что измеряет, как быстро запускается цепочка инструментов. Это мало говорит о число, на которое разработчик действительно ждет, что и есть наклон. Этот пятый бенчмарк генерирует одну и ту же программу с увеличивающимися размерами — K независимые функции с четырьмя операциями и одна точка входа, которая вызывает их все — и собирает через каждую инструментальную цепочку на хосте, в вращающийся порядок.

Затем запускается то, что произвел каждый тулчейн, после остановки часов. Эта проверка не украшение. Самый быстрый способ сгенерировать артефакт — выдать сломанный, так что линия, которая перестала работать, иначе опубликовала бы его лучшие показатели именно там, где он перестал работать.

Обе оси логарифмические: источники охватывают три порядка величины, как и времена. Линия заканчивается точкой там, где выполнение завершилось, крестом там, где эта дорожка сгенерировала артефакт, не являющийся программой, и полосой там, где цепочка инструментов отказалась собирать. Эти три события не совпадают, и два сбоя ниже — разные.

Время стены сборки холодного процесса по размеру исходника; медианы, один хост, полосы перемежаются
Цепочка инструментов / цель	K=1	K=32	K=128	K=129	K=512	K=1023	K=1024	K=2048
Kotoba · Выпущенный CLI · WebAssembly	11.753 ms	35.84 ms	111.538 ms	недопустимый артефакт	недопустимый артефакт	недопустимый артефакт	сборка не удалась	сборка не удалась
Kotoba / Amu · WebAssembly	733.255 ms	825.418 ms	1123.04 ms	1123.847 ms	3380.63 ms	9242.463 ms	сборка не удалась	сборка не удалась
Kotoba / Amu · Нативный aarch64-macos	962.198 ms	1509.84 ms	2973.249 ms	3000.243 ms	10601.87 ms	23725.327 ms	сборка не удалась	сборка не удалась
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 · Нативный хост	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	нет тулчейна	нет тулчейна	нет тулчейна	нет тулчейна	нет тулчейна	нет тулчейна	нет тулчейна	нет тулчейна
C / Clang · Родной хост	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 · класс 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

Измерено 2026-08-31 на judahnoMac-mini.local (Apple M4). K — количество сгенерированных функций; исходный код Kotoba содержит от 9 до 14338 строк. Цели, ABI, уровни оптимизации и контракты времени выполнения различаются по линиям, поэтому это вопрос задержки обратной связи разработчика, а не эквивалентной работы. Ворота нагрузки хоста провалились (load1 2.73–2.73, требуется ≤ 1), так что это наблюдения этого запуска, а не переносимые данные. Поскольку линии перемешаны, порядок квалифицируется отдельно.

Какие упорядочивания проходят тест шума

Отношение — это не рейтинг. perfgate отказывается от любого упорядочивания, чей разрыв попадает внутрь собственного разброса двух ветвей, как бы ни выглядело отношение, и отказывается от руки с слишком малым количеством образцов или слишком много шума. Он запускается здесь по своей собственной политике по умолчанию, без ослабления — порог ослаблен, чтобы это прошло, был бы бенчмарком, измеряющим собственные пороги. Поскольку дорожки перемежаются на одном хосте, возникает разрыв кто проходит этот тест, выживает при занятом хосте.

Выпущен Kotoba CLI против каждого компаратора, на каждом размере, где он ещё испускает валидный модуль
Размер	Сравнено с	Kotoba быстрее?	Разрыв против комбинированного разброса	Почему нет, если нет
K=1	C / Clang · Родной хост	да, квалифицировано	17.1 мс против 1.0 мс	—
K=1	JVM / javac · класс JVM	да, квалифицировано	160.8 мс против 5.4 мс	—
K=1	Rust / rustc · Нативный хост	да, квалифицировано	44.2 мс против 0.6 мс	—
K=1	Rust / rustc · WebAssembly	да, квалифицировано	27.1 мс против 0.5 мс	—
K=32	C / Clang · Родной хост	нет	5.3 мс против 1.0 мс	улучшение-ниже-порога
K=32	JVM / javac · класс JVM	да, квалифицировано	161.9 мс против 1.2 мс	—
K=32	Rust / rustc · Нативный хост	да, квалифицировано	26.7 мс против 0.7 мс	—
K=32	Rust / rustc · WebAssembly	да, квалифицировано	9.8 мс против 0.6 мс	—
K=128	C / Clang · Родной хост	нет	75.8 мс против 1.2 мс	улучшение-ниже-порога
K=128	JVM / javac · класс JVM	да, квалифицировано	126.2 мс против 2.2 мс	—
K=128	Rust / rustc · Нативный хост	нет	29.3 мс против 1.4 мс	улучшение-ниже-порога
K=128	Rust / rustc · WebAssembly	нет	45.8 мс против 1.1 мс	улучшение-ниже-порога

улучшение ниже порога означает, что линия Kotoba вовсе не была быстрее при таком размере. Преимущество реально и подтверждено при холодном старте, но исчезает по сравнению с C при K=32 и с Rust при K=128. Этот переход — результат, поэтому он показан, а не суммирован.

Два сбоя, которые не являются одним и тем же сбоем

Три полосы Kotoba перестали работать в этом запуске, и публикация их как одной строка была бы неверной. Один — дефект. Другие два объявлены границы строго соблюдаются как указано и сообщаются как дефекты означало бы измерение границ вместо компилятора.

Что остановилось и что это значит
Наблюдение	Чтение
Выпущенный CLI kotoba генерирует модуль, который не скомпилируется при количестве функций выше 128	Дефект и причина для валидации внутри оболочки. При K=129 вызов должен нести индекс функции 128, первое значение, требующее двух байт LEB128, а эмиттер пишет один. Байты показывают, что это не отсутствующий кодировщик, а неиспользуемый: local.set 128 записан как 80 01, а call 128 на одну инструкцию позже записан как 80. Количество усечённых операндов ровно K минус 128. Текущий компилятор этого не имеет — Amu строит K=129 корректно, и исправление было в ветке эмиттера по умолчанию ещё до пометки этого релиза.
Каждая полоса Kotoba ловит на K=512 при сборке с настройками по умолчанию	Не дефект. Модуль Kotoba имеет объявленный бюджет вызовов, а значение по умолчанию компилятора — 512 вызовов, который этот рабочий нагрузка превышает при K=512, где точка входа вызывает 512 листов. Среда явно объявляет 1,048,576 единиц и фиксирует это. C, Rust и Java не имеют эквивалентного ограничения для повышения.
Amu отказывается от модуля сразу, если он содержит более 1,024 функций	Также не дефект и противоположность первой строке. max-functions — это объявленный предел допуска, поэтому компилятор останавливается с kotoba.error/subset-reject и называет то, что отказался, вместо генерации чего-то, что не загрузится. Громкий потолок и тихий — очень разные результаты, и только тест, выполняющий артефакт, их различает. Измерено 2026-09-07: это потолок всей программы, а не одного модуля — max-project-functions тоже 1,024 и проверяется по связанному проекту, так что сегодня ни одна компоновка модулей не компилирует программу с 2,048 функциями.

Что это устанавливает

Ответы пятого бенчмарка, включая неблагоприятные
Вопрос	Ответ из этого запуска
Насколько быстро холодная сборка Kotoba маленького модуля?	Выпущенный CLI собирает K=1 за 11.753 мс при холодном процессе, артефакт выполняется и ответ проверяется — самый быстрый первый результат среди всех измеренных здесь линий.
Какой размер модуля может собрать выпущенный бинарник?	До 128 функций. Свыше этого это не медленнее, это неправильно, и этот каркас сообщает об этом как о неудачной полосе, а не быстрой.
Остаётся ли время сборки конкурентоспособным с ростом исходников?	Через K=128 выпущенный CLI сравнивается с Rust и C в таблице выше. После этой точки единственный компилятор Kotoba, который по-прежнему генерирует корректный модуль — Amu, который работает на nbb, а не как выпущенный бинарник, и примерно на порядок медленнее на всех измеренных размерах — поэтому при больших размерах скорость сборки в настоящее время не является сильной стороной Kotoba, и эта страница не будет утверждать обратное.
Насколько большой исходный код построен от начала до конца?	K=1023 через Amu — 7163 строк Kotoba, артефакт выполнен и ответ проверен. Это на одну функцию меньше объявленного потолка 1,024, и следующий размер отклоняется, а не строится неправильно.
Быстрый ли сгенерированный код?	Вне области здесь — это измеряет сборку, а не запуск. Набор native runtime выше отвечает на этот вопрос.

Итог: При самом маленьком размере выпущенный бинарник быстрее каждого сравниваемого здесь с запасом, который выдерживает тест шума, и имеет жёсткий потолок корректности на 128 функциях. Компилятор без этого потолка примерно в десять раз медленнее на всех размерах измерено. Оба факта получены из одного запуска, и тест, который их обнаружил, является публичным, чтобы запуск мог быть оспорен.

Просмотреть образцы масштабирования сборки Запустите снова на вашей машине Дефект с его байтами

Сколько времени на самом деле занимает каждая нативная нагрузка

Сетка ниже показывает разницу между двумя ветвями. Это число правила perfgate включены, но процент сам по себе не говорит, является ли нагрузка выполняется за пять миллисекунд или пятьсот, и она скрывает разница между оспариваемой парой и несущественной. Эти панели медианы, из которых вычисляются эти маржи. Amu native — это цветная полоса в каждой панели — включая панели, где он не первый. Каждая панель масштабировано по самой медленной своей части, потому что вопрос, на который отвечает панель, — кто быстрее в этой нагрузке.

Узкая арифметика

Clang / C11 6.41 ms
Amu native 6.53 ms1.02× самый быстрый здесь
Swift 6.55 ms
Rust 6.58 ms
Zig 8.24 ms
Go c-shared 42.84 ms

Широкое давление на регистры

Amu native 5.80 msсамый быстрый здесь
Rust 6.19 ms
Clang / C11 6.50 ms
Zig 6.97 ms
Go c-shared 41.07 ms
Swift 44.08 ms

Глубокое давление на сброс

Amu native 9.23 msсамый быстрый здесь
Rust 9.61 ms
Zig 9.71 ms
Clang / C11 10.23 ms
Go c-shared 51.86 ms
Swift 124.27 ms

Сохранение вызова

Rust 4.77 ms
Clang / C11 4.82 ms
Amu native 4.85 ms1.02× самый быстрый здесь
Swift 6.77 ms
Zig 8.44 ms
Go c-shared 32.49 ms

Ветвление + управление вызовами

Clang / C11 4.67 ms
Rust 4.90 ms
Amu native 4.98 ms1.07× самый быстрый здесь
Swift 6.72 ms
Zig 8.95 ms
Go c-shared 33.84 ms

Обратное ребро вызова цикла

Clang / C11 139.84 ms
Amu native 140.59 ms1.01× самый быстрый здесь
Rust 141.73 ms
Go c-shared 169.38 ms
Swift 186.09 ms
Zig 207.01 ms

Медианное время в миллисекундах по 5 квалифицированным запускам хоста; меньше — быстрее. Каждая ветвь вернула одинаковый независимо проверенный ответ, и кандидат в медианы — одно значение на нагрузку — набор чередует каждую пару движков в порядке ABBA/BAAB, так что один и тот же артефакт Amu замеряется один раз на нагрузку, а затем сравнивается с каждой ветвью по очереди. В отличие от других четырёх бенчмарков на этой странице, у этого прошли ворота тихого хоста (qualified-host-load), так что это данные для этого хоста, а не только наблюдения. Ограниченное быстрое утверждение всё ещё требует все 30 пар, для чего предназначена сетка ниже.

Каждая пара времени выполнения, выигрыш или проигрыш

Ограниченное утверждение — всё или ничего, поэтому одна неквалифицированная пара делает его ложным. Публикация только этого вердикта скрыла бы, какие пары оспариваются, поэтому весь сетка здесь. Ячейка — это среднее улучшение Amu native по сравнению с этим компаратором по этой нагрузке; положительное значение означает, что Amu быстрее, а галочка отмечает пары, которые чёткий перфгейт — как минимум 5% и отделён от собственного разброса рук.

Amu native против каждого компаратора, 2026-09-07, квалифицированный хостом; ✓ = проходит perfgate
Рабочая нагрузка	Rust	Clang / C11	Zig	Go c-shared	Swift
Узкая арифметика	+0.4%	-0.6%	+20.1%	+84.7%	-0.6%
Широкое давление на регистры	+6.5%	+10.9%	+16.9%	+86.0%	+87.1%
Глубокое давление на сброс	+4.2%	+9.3%	+5.1%	+82.2%	+92.6%
Сохранение вызова	-1.0%	-0.3%	+42.9%	+85.2%	+29.6%
Ветвление + управление вызовами	-2.6%	-7.1%	+43.8%	+85.2%	+25.1%
Обратное ребро вызова цикла	+0.8%	-0.1%	+32.4%	+17.2%	+24.8%

Каждая ячейка — это столбец, выросший от центральной линии: справа от нее Amu native быстрее, слева медленнее. Два направления масштабируются отдельно — выигрыши идут до +93%, а проигрыши только до −7%, поэтому общая шкала сгладила бы каждую оспариваемую пару в одну невидимую полоску. Знак также передается стороной линии и подписанным числом, так что чтение этой сетки не зависит от различения двух цветов.

19 из 30 пар квалифицированы (медиана 5; 19 в каждом запуске) · кандидат 42f092ea5b61 · Apple M4, 10 логических ЦП, 16 ГиБ

Доставка оптимизации после опубликованного запуска

Устаревший бенчмарк выше остается неизменным. Новые реализации перечислены отдельно, пока набор тех же артефактов не пройдет квалификационные ворота.

Реализованные поверхности, которые ещё не являются новыми утверждениями о скорости
Поверхность	Доставлено	Граница доказательств
Нативные векторы / выделение	Ограниченные векторы литералов без выхода за пределы проверены на x86-64 и AArch64 с заменой на скаляры.	Тесты бэкенда 211 / 2,442 утверждений; векторы выхода сохраняют проверенный ABI хоста. Новых ранжированных замеров времени пока нет.
Строковый SIMD	Проверка равенства POSIX использует явное сравнение NEON или SSE2 на 16 байтах после проверки дескриптора и канонической UTF-8 валидации.	Оптимизированная сборка и проверенные семантические векторы нативной ISA. Windows остаётся отдельно закреплённым; рейтинг задержки ожидается.
Асинхронные возможности ввода/вывода	Ограниченный корнем конечный read/write/list/exists/delete использует CompletableFuture на JVM и fs.promises на Node.	Тесты JVM и Node с реальной файловой системой проходят. Публичный автономный Wasm-бенчмарк по-прежнему не имеет подтвержденной привязки к хосту, поэтому его I/O ячейка остается N/A.
Структурированная конкуренция	Ограниченная область fail-fast дочернего 32 объединяет, отменяет сиблинг и предотвращает выход дочернего времени жизни как канонического состояния Kotoba.	Утверждения паритета 996 по .kotoba authority и CLJC load path. Это структурированная семантика времени жизни, а не результат пропускной способности ОС-потока.
Kotoba CLI	kotoba test/build использует новый компилятор pin; kotoba compile напрямую генерирует запечатанный x86-64 и AArch64 KEXE.	Публичный CLI жизненный цикл и векторный артефакт AArch64 проверены. Нативный --run остается отклоненным до тех пор, пока не будет подключена измеренная квитанция загрузчика.

Запуск компилятора, четыре цепочки инструментов

KotobaWebAssembly 40.998 msбазовый уровень
Rust / rustcWebAssembly 126.422 ms3.084× Kotoba
C / ClangWebAssembly 146.324 ms3.569× Kotoba
JVM / javacJVM класс 961.248 ms23.446× Kotoba

Время работы процесса в холодном состоянии для одного маленького исходника, в миллисекундах; меньше — быстрее. 21 вращающихся образцов на цепочку инструментов на Apple M4. Ворота нагрузки хоста ПРОВАЛИЛИСЬ в этом запуске, так что это наблюдения одной машины, а не рейтинг.

Малое измерение сборки от исходника до артефакта в холодном процессе
Цепочка инструментов	Вывод	Медиана	p95	Относительное прошедшее время
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	JVM класс	961.248 ms	2223.49 ms	23.446× Kotoba

KOTOBA 0.7.3 · RUSTC 1.97.1 · Homebrew clang версия 22.1.7 · javac 24.0.2. Kotoba, Rust и C генерируют Wasm; javac генерирует класс-файл. Разные цели и работа компилятора делают это наблюдением на старте, а не универсальным рейтингом. Зафиксированный хост-загрузочный шлюз не прошёл, поэтому таблица не является квалифицированным рейтингом скорости.

Медианы цикла разработки маленького проекта без зависимостей; N/A означает, что отдельная фаза не измерялась
Цепочка инструментов / цель	Разрешить	Проверить	Чистая сборка	Сборка без изменений	Запуск + выполнение	Чистая сборка + первый результат
Kotoba · WebAssembly	N/A	231.75 ms	62.906 ms	42.332 ms	57.253 ms	142.644 ms
Rust / Cargo · arm64 macOS нативный	138.018 ms	71.208 ms	896.478 ms	67.764 ms	371.522 ms	1299.171 ms
C / Clang · arm64 macOS нативный	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 нативный	N/A	N/A	1059.624 ms	395.305 ms	203.169 ms	1269.918 ms
Go · arm64 macOS нативный	43.553 ms	6979.823 ms	3499.277 ms	150.902 ms	247.051 ms	3755.431 ms
Swift / SwiftPM · arm64 macOS нативный	1017.252 ms	427.372 ms	3695.557 ms	1259.829 ms	431.84 ms	4016.271 ms
JVM / javac · класс 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

Каждый сгенерированный артефакт производил 42 в новом процессе. Цели и контракты времени выполнения различаются; N/A никогда не равен нулю. Шлюз загрузки хоста не прошел, поэтому это воспроизводимые наблюдения, а не кросс-языковое ранжирование скорости.

Шесть областей, рядом

Каждая панель масштабируется под свою самую медленную полосу, потому что вопрос панели ответы — кто быстрее в этой области, а не как области сравниваются друг с другом другие. Полоса Kotoba — цветная во всех панелях — включая панели, где он последний. Его отдельный Wasm-артефакт запускается через Node хост и платит этот старт на каждом холодном процессе, в то время как Rust, C и Go запускать как нативные бинарники; если у цели нет амбиентной файловой системы или потока контракта вообще нет, полоса отсутствует, а не равна нулю.

Строка

C / Clang 1.463 ms
Rust 1.907 ms
Go 1.974 ms
JVM / Java 27.819 ms
Kotoba / Wasm + типизированный JS хост 30.539 ms20.9× быстрее всех здесь
JavaScript / Node.js 31.628 ms

Коллекция

C / Clang 1.357 ms
Go 1.852 ms
Rust 1.92 ms
Kotoba / Wasm + типизированный JS хост 29.98 ms22.1× быстрее всех здесь
JVM / Java 31.42 ms
JavaScript / Node.js 31.818 ms

Распределение

C / Clang 1.353 ms
Rust 1.943 ms
Go 1.962 ms
JVM / Java 26.447 ms
Kotoba / Wasm + типизированный JS хост 29.567 ms21.9× самый быстрый здесь
JavaScript / Node.js 31.055 ms

Ввод/вывод

C / Clang 2.539 ms
Rust 2.686 ms
Go 6.577 ms
JVM / Java 38.685 ms
JavaScript / Node.js 94.124 ms
Kotoba / Wasm + типизированный JS хост Н/Д — не входит в контракт этой цели —

Параллелизм

C / Clang 2.916 ms
Rust 3.328 ms
Go 3.377 ms
JVM / Java 34.828 ms
JavaScript / Node.js 55.105 ms
Kotoba / Wasm + типизированный JS хост Н/Д — не входит в контракт этой цели —

Реальное приложение

C / Clang 1.294 ms
Go 1.964 ms
Rust 2.047 ms
JVM / Java 26.411 ms
JavaScript / Node.js 29.534 ms
Kotoba / Wasm + типизированный JS хост 29.652 ms22.9× самый быстрый здесь

Медианы холодного процесса в миллисекундах; меньше — быстрее. Ворота загрузки хоста неудача в этом запуске, поэтому эти панели — наблюдения, а не рейтинг, а амортизированная линия ниже рассказывает совсем другую историю.

Медианы рабочих нагрузок с холодным процессом; N/A означает, что целевой контракт не предоставляет эту возможность
Путь выполнения	Строка	Коллекция	Распределение	Файловый ввод-вывод	Параллелизм	Реальное приложение
Kotoba / Wasm + типизированный JS хост	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
Go	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

Каждый образец вернул точную контрольную сумму ссылки. Kotoba использует сгенерированный Wasm и объявленный типизированный ABI; его автономная цель не имеет окружения файловой системы или контракта потоков, поэтому эти ячейки считаются Н/Д. Записанный хост-загрузочный шлюз не прошёл, поэтому медианы — это наблюдения, а не рейтинг.

Амортизированные медианы пакетной обработки в процессе на базовую нагрузку; N/A сохраняет ту же границу возможностей
Путь выполнения	Строка	Коллекция	Распределение	Файловый ввод-вывод	Параллелизм	Реальное приложение
Kotoba / Wasm + типизированный JS хост	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
Go	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

Каждая большая партия в процессе делится на объявленный множитель нагрузки. Это амортизирует запуск, но не полностью устраняет затраты на процесс, ВМ или инстанцирование Wasm, поэтому это не считается идеально прогретым устойчивым результатом. Чистые цепочки инк/дек карты Kotoba объединены в reduce без промежуточных векторов; обратные вызовы вне этого проверенного подмножества сохраняют жадную материализацию.

Что каждый публичный бенчмарк устанавливает — и не устанавливает
Вопрос	Сравнённые реализации	Текущий вывод
Мини-компиляция и выполнение Wasm	Kotoba, Rust, C и JVM цепочки инструментов	Опубликованы четыре медианы холодного процесса выше; только Kotoba/Rust/C используют цель Wasm, и общий ранг скорости сборки не заявлен
Цикл разработчика маленького проекта	Kotoba, Rust, C, Zig, TinyGo, Go, Swift, JVM, AssemblyScript, .NET IL и .NET Native AOT	Опубликовано семь образцов на доступную стадию; различия целей и проваленные ворота нагрузки хоста запрещают универсальный рейтинг
Нативное выполнение в устойчивом состоянии	Amu native против Rust, Clang / C11, Zig, Go c-shared, Swift	Все 30 семантические сравнительные ячейки завершены; рейтинг скорости не раскрыт, потому что тихий хост-шлюз не прошёл
Строки, коллекции, выделение памяти, ввод/вывод, параллелизм и реальное приложение	Пути выполнения Kotoba, Rust, C, Go, JVM и JavaScript	Публикуются точные контрольные суммы и холодные процессы плюс амортизированные выборки; автономный ввод-вывод и потоки Kotoba не применимы, в то время как чистое приложение с допуском запросов измеряется; неудачный загрузочный шлюз удерживает ранжирование

Что покрывает нативный набор

Каждая реализация возвращает независимо проверенный известный ответ. Набор тестов вращает каждую пару движков в порядке ABBA/BAAB и измеряет после загрузки, отображения и поиска символов.

Шесть обязательных нативных нагрузок времени выполнения
Рабочая нагрузка	На что это делает акцент	Статус доказательств
Узкая арифметика		Точный результат проверен; время не квалифицировано
Широкое давление на регистры		Точный результат проверен; время не квалифицировано
Глубокое давление на сброс		Точный результат проверен; время не квалифицировано
Сохранение вызова		Точный результат проверен; время не квалифицировано
Ветвление + управление вызовами		Точный результат проверен; время не квалифицировано
Обратное ребро вызова цикла		Точный результат проверен; время не квалифицировано

Где живёт каждый бенчмарк

Каждое число выше исходит из публичного средства и зафиксированного отчёта, поэтому запуск можно повторить, и с утверждением можно не согласиться. Пути в репозитории в эта таблица проверяется по рабочему дереву при генерации этой страницы: испытательная среда, которая при ошибке прерывает сборку, а не поставляет неработающую ссылку.

Средства, метод и отчет для каждого опубликованного бенчмарка
Бенчмарк	Репозиторий	Средства и метод	Отчет
Запуск компилятора	kotoba-lang/kotoba-lang	scripts/benchmark-public-compile.mjs · bench/public-compile-comparison/README.md · bench/public-compile-comparison/main.kotoba	опубликованный JSON · bench/public-compile-comparison/latest.json
Цикл разработчика	kotoba-lang/kotoba-lang	scripts/benchmark-public-end-to-end.mjs · bench/public-end-to-end-comparison/README.md	опубликованный JSON · bench/public-end-to-end-comparison/latest.json
Нативное время выполнения	kotoba-lang/amu	runtime-multidomain-suite.mjs · multidomain-suite.json · performance.md · scripts/project-runtime-comparison.cljs	опубликованный JSON · bench/public-runtime-comparison/latest.json
Масштабируемая сборка	kotoba-lang/buildbench	buildbench	опубликованный JSON · bench/public-build-scaling/latest.json
Домены нагрузки	kotoba-lang/kotoba-lang	scripts/benchmark-public-domains.mjs · bench/public-domain-comparison/README.md · bench/public-domain-comparison/probes	опубликованный JSON · bench/public-domain-comparison/latest.json

Ворота, через которые проходит каждый порядок на этой странице, это kotoba-lang/perfgate, запущен с собственной неослабленной политикой по умолчанию. Порог ослаблен, чтобы позволить прогон будет бенчмарком, измеряющим собственные пороги.

Итог: Артефакты, точные результаты и образцы реальны во всех пяти бенчмарках. Три из них — запуск компилятора, цикл разработчика и домены нагрузки — не прошли свой тихий хост-гейт, поэтому они не ранжируются и публикуются как наблюдения. Набор native runtime прошёл свой гейт и выигрывает 19 из 30 пар, не достигая утверждения для каждой пары, которое ему нужно. Масштабирование сборки квалифицирует порядок холодного старта против каждого компаратора на хосте и находит потолок корректности в том же запуске. Ни один универсальный рейтинг скорости не заявлен на этой странице, и ни один из этих запусков не лицензирует его.

Просмотреть образцы компиляции Проверить доказательства времени выполнения Проверить образцы цикла разработчика Проверить образцы домена нагрузки Просмотрите метод выполнения Перезапустить компиляцию

Утверждения с прикреплёнными границами

Эти утверждения сгенерированы из lang/safety-claims.edn. Каждое сохраняет свою доверенную вычислительную базу и остаточный риск видимыми, потому что лозунг безопасности без границы — это лишь маркетинг.

T1-ПАМЯТЬ

Допущенные компоненты не могут обращаться к памяти во время выполнения/родной памяти, а операции с памятью компонентов ограничены или вызывают ловушку.

Доверенная вычислительная база

ограниченный ридер · фронтенд-допуск · проверка артефактов · Wasm/native runtime

Остаточный риск

уязвимости runtime-engine остаются в TCB
нативные загрузчики требуют второй границы изоляции ОС

T2-ЭФФЕКТ

Каждое транзитивное влияние компонента объявляется и принимается до эмиссии, включая эффекты, используемые провайдерами, написанными на Kotoba.

Доверенная вычислительная база

вывод эффектов · каталог возможностей · граф вызовов фронтенда

Остаточный риск

kotoba и грамматика/эффекты компилятора должны постоянно сравниваться

T3-ОГРАНИЧЕНИЕ

Непредоставленная возможность отсутствует или не привязана и не может достичь провайдера или нативного обработчика.

Доверенная вычислительная база

пересечение политики · импорт компилятора · связывание тендера · защита хоста

Остаточный риск

провайдер и нативные реализации должны независимо проверять область ресурсов
производственные эффективные гранты должны запрещать область с подстановочными знаками

T4-ДЕТЕРМИНИЗМ

Один и тот же допущенный источник, цель, политика и блокировка создают один и тот же наблюдаемый чистый результат и байты артефакта.

Доверенная вычислительная база

канонический ридер · детерминированное понижение · закреплённая цепочка инструментов

Остаточный риск

эффекты хоста детерминированы только там, где это указано в их контракте возможностей

T5-ОГРАНИЧЕНИЯ-РЕСУРСОВ

Исходник, допуск, выполнение, память и вывод используют явные конечные ограничения.

Доверенная вычислительная база

лимиты допуска · счетчик топлива · квота времени выполнения · таймаут супервизора

Остаточный риск

Супервизоры платформ пока не имеют равных доказательств изоляции производства

T6-ЦЕПОЧКА ПОСТАВОК

Принятие выпуска связывает идентичность артефакта, доверенного подписанта, действительность и воспроизводимые доказательства.

Доверенная вычислительная база

верификатор подписи · конфигурация доверенного подписанта · часы · набор отзывов

Остаточный риск

хранение ключей и внешнее распространение отзывов остаются операционным TCB

T7-BACKEND-PARITY

Общий переносимый компонент имеет равное принятие, результат и трассировку эффектов на квалифицированных бэкендах.

Доверенная вычислительная база

общий манифест соответствия · адаптеры бэкенда · раннер сравнений

Остаточный риск

функции только для компилятора не являются переносимыми и должны быть отклонены переносимыми профилями

T8-HOST-RESOURCE-SCOPE

Импорт компонента достигает своего провайдера или нативного обработчика только с конкретной областью ресурсов после пересечения и генерирует квитанцию.

Доверенная вычислительная база

пересечение возможностей · защита хоста · обработчик провайдера · приёмник квитанций

Остаточный риск

Провайдер-специфичные проверки путей, перенаправлений, символических ссылок и арендаторов требуют наборов Q5

Квалификация Q1, по состоянию на 2026-07-18.

Связывание релиза

Профиль языка и релиз реализации разделены, пока их не свяжет подписанный конверт.

ЯЗЫК

Профиль 6

контракт пакета 1

РЕАЛИЗАЦИЯ

v0.7.0

привязка профиля: проверено

ПУБЛИЧНЫЙ ПО УМОЛЧАНИЮ

ВЫПУЩЕНО

:docs/release-bound-profile

Kotoba v0.7.0 для darwin-arm64 — это публичная реализация, привязанная к языковому профилю 6 и контракту пакета 1. Его подписанный конверт проверяет исходное дерево, дайджест артефакта и результат соответствия 536-тесту / 8,580-утверждению. Другие платформы остаются непривязанными.

Прочитать сгенерированные доказательства релиза

04 Начать использовать

Начать через шестьдесят секунд

Установка и самопроверка

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

Принять допустимый ответ с пустым списком проблем.

Первая программа

(defn main []
  (+ 40 2))

Эта программа не запрашивает импортов хоста; сгенерированный модуль не имеет импортов.

AI агент: исполняемый быстрый старт Открыть руководство по началу работы Прочитайте справочник CLI

Учитесь, пробуйте, затем углубляйтесь

Связанный путь от первой программы к языковым контрактам, библиотекам, доказательствам и поверхностям развертывания.

УЧИТЕСЬ

Документация по назначению

Начните с установки, изучите допущенный язык или изучите нормативную семантику и данные соответствия.

Открыть карту документации

ЧИТАТЬ КОД

Один источник, один ответ

Пример ниже — точный исходный код, скомпилированный в демонстрацию браузера — не переосмысление на JavaScript.

Прочитать пример

ЗАПУСТИТЬ

Выполнить на этой странице

Загрузите артефакт WebAssembly с тем же происхождением и привязкой дайджеста и вызовите его экспортированную основную функцию Kotoba.

Открытая игра

СБОРКА

Библиотеки и контракты

Просматривайте ограниченные имена ядра, фундаментальные библиотеки, правила пакетов и их текущую границу зрелости.

Просмотреть библиотеки

Небольшая программа Kotoba, работающая в реальном времени

Amu компилирует этот чистый исходник Kotoba в профиль wasm32-browser. Зафиксированный артефакт не имеет импортов и возвращает 42.

ИСТОЧНИК KOTOBA

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

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

(defn main []
  (double 21))

Выделение авторитета: kotoba-lang/grammar → kotoba.grammar.highlight/tokenize → HTML во время сборки. Контракт области редактора: source.kotoba. Зависимость выделения в браузере: отсутствует. Проверить зависимости

Компилировать локально: kotoba compile double-21.kotoba --target wasm32-browser --output double-21.wasm

ИГРАТЬ · WEBASSEMBLY

Запустить проверенный артефакт

Браузер загружает 344 байт, проверяет SHA-256, отклоняет все импорты, инициализирует модуль и вызывает main().

Ожидаемый результат: 42

Готово. Код еще не запускался.

Это выполняет предварительно скомпилированный, неизменяемый пример. Редактирование произвольного исходного кода в браузере пока не является доступной поверхностью компилятора.

Интерактивные демонстрации: solar-helix (рендеринг WebGPU, управляемый гостем) · kami-survivors (игра .kotoba) · gpu-clear (WebGPU дым). Размещено на wasm-webcomponent GitHub Pages surface; доступность зависит от поддержки WebGPU/WebAssembly в браузере.

Библиотеки, без скрытия границ пакета

Библиотеки Kotoba — это графы с адресацией по содержимому. Имена и репозитории GitHub помогают людям их находить; определения и подписанные релизные CID точно указывают, что они из себя представляют.

ОГРАНИЧЕННОЕ ЯДРО

Сгенерированная ссылка на символ

Ищите имена, допущенные текущим ограниченным контрактом стандартной библиотеки.

Просмотреть основные символы

ФУНДАМЕНТАЛЬНЫЙ

Данные, эффекты, ввод-вывод, инструменты

Начните с coll, spec, json, text, wit, async, time, fs, http, test, fmt, lint и LSP контрактов.

Просмотреть карту библиотеки

КОНТРАКТ ПАКЕТА

Зависимости с адресацией по содержимому

Просмотрите точные CID зависимостей, слои идентичности, происхождение GitHub и текущую границу публикации.

Откройте каталог библиотек и публикуйте поток

Просмотреть всю организацию по тегу

Есть 2,215 публичные репозитории в kotoba-lang организация. Каждый тег ниже — это тема GitHub одно и то же имя, поэтому фильтр сайта и темы организации — это один словарь вместо двух, которые дрейфуют. Выберите один, чтобы открыть уже отфильтрованный каталог.

Внешнее происхождение · 1,275 Возможность · 61 Приложение · 55 Актёр · 7 Цикл · 11 kami — семейство движков · 103 kotoba — семейство языков · 51 kotobase — семейство хранилищ · 35 ОС и ядро · 41 Драйверы и оборудование · 18 Моделирование и симуляция · 31 Компиляторы и IR · 45 Время выполнения и WebAssembly · 227 Криптография · 45 Идентичность и полномочия · 127 Сети и протоколы · 58 Хранение и форматы · 73 Базы данных и запросы · 62 Адресация содержимого · 49 Блокчейн и кошельки · 17 Графика, 3D и GPU · 118 Аудио и видео · 27 UI и дизайн-системы · 40 ИИ, LLM и агенты · 67 EDA, CAD и производство · 29 Робототехника и транспорт · 29 Финансы и платежи · 36 Юридическое и соответствие · 31 Наука и здоровье · 32 Геопространственные данные · 11 Инструменты разработчика · 26 Документы, текст и i18n · 25

Просмотрите и отфильтруйте все репозитории 2,215

Репозиторий — это не опубликованный пакет. Точно 1 библиотека опубликована через реестр с адресацией по содержимому; остальная часть этого списка — это обнаружение. Метки зрелости репозитория не подразумевают стабильность API 1.0, широкое принятие или производственные SLO, а 255 репозиториев не соответствуют ни одному правилу домена и отображаются без меток, а не с ближайшей меткой.

Поиск по проверенной ссылке

Поиск команд, имен стандартной библиотеки, диагностики и статуса выпуска. Индекс генерируется из машинных авторитетов и остается на этой странице.

Поиск документации Kotoba

Попробуйте: компиляция, option-some, docs/link-missing

релиз

Связывание релиза

Открытая ссылка

cli

`kotoba id`

Создайте цепь-нейтральный план регистрации главного Kotoba, контролируемый паролем. Умные аккаунты — явные ссылки CAIP-10; ни одна цепь или провайдер не является корнем идентичности.

Открытая ссылка

cli

`kotoba run`

Скомпилировать и запустить точку входа Kotoba.

Открытая ссылка

cli

`kotoba compile`

Компилировать исходники семейства Kotoba в целевой артефакт. Веб .kotoba использует проверенный KIR и ограниченный backend kotoba-script; .cljs остается ClojureScript.

Открытая ссылка

cli

`kotoba check`

Проверяйте исходники Kotoba, контракты или метаданные пакетов без запуска. Адаптер компилятора: фронтенд admit + --profile pure-product (T9.2).

Открытая ссылка

cli

`kotoba graph`

Запрашивайте и транзакционируйте хранилище графа языка (kgraph) с операциями в стиле Datomic.

Открытая ссылка

cli

`kotoba git`

Открыть операции репозитория Kotoba как данные, а не как поведение, специфичное для оболочки.

Открытая ссылка

cli

`kotoba rad`

Запускайте рабочие процессы быстрого развития приложений над пакетами Kotoba.

Открытая ссылка

cli

`kotoba build`

Соберите проект Kotoba в его проверенный целевой артефакт. Это прямая команда жизненного цикла проекта; rad build остаётся совместимым написанием.

Открытая ссылка

cli

`kotoba test`

Проверьте и запустите допущенные тесты для проекта Kotoba. Это прямая команда жизненного цикла проекта; rad test остаётся совместимым написанием.

Открытая ссылка

cli

`kotoba deploy`

Планируйте и применяйте желаемое состояние пакета к локальной квитанции или цели резидента флота murakumo.

Открытая ссылка

cli

`kotoba library`

Проверить и опубликовать пространство имен библиотеки с адресацией по содержимому через существующую кодовую базу Kotoba и путь публикации IPNS.

Открытая ссылка

cli

`kotoba hinshitsu`

Запускайте проверки качества ПО (доказательства, ворота, покрытие, визуальная регрессия) как данные.

Открытая ссылка

stdlib