;; 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 · hello.kotoba 的 sha2-256 -
源 SHA-256
0471d55d668ed5f9…此处显示文件的 sha-256 -
已检查的 KIR SHA-256
92635333e1e0da86…编译器承认的类型化、效果检查表示 -
工件身份 SHA-256
cfea3b89cc022a6b…绑定源、策略、编译器合同和目标 ABI
源 CID 打开 hello.kotoba。SHA-256 摘要标识源字节、已检查的 KIR 和工件身份；它们不是 IPFS 地址。
安全 + 快速 · 为 AI 生成软件构建
安全代码。为机器速度构建。
Kotoba 是一种 Lisp 形态语言，设计用于安全、超快的 AI 生成软件。可检查程序、显式能力和内容寻址工件将编译器检查与受控执行连接。
此主机上任何工具链最快的冷构建。
11.75毫秒
Kotoba 源码到 WebAssembly 工件，过程冷启动 — 然后执行， 以及时钟停止后检查的答案。
进程冷启动构建墙时间（毫秒）；越短越快。K=1 源代码，单主机交错通道，7 次采样。
所有 4 排序均通过 性能门控 在其未放宽的默认策略下——至少 5%,并与 自身范围的扩展——因此即使主机忙碌，排序仍然保持。 绑定于此主机、此源代码大小和此运行：构建时间不 执行速度，随着源代码增长优势缩小，已发布 二进制具有严格的正确性上限。包括以下五个基准测试 与 Kotoba 相违背的，见下。测量 2026-08-31 开启 苹果 M4.
当 AI 持续生成、构建、测试和再生成代码时，构建延迟变成基础设施吞吐量。
无环境权限
无隐式文件系统、网络、进程、时钟、模型或秘密。
权限在编译后依然有效
类型、效果、资源和目标支持在发射前被准入。
仅绑定授权
主机和提供者强制具体范围并记录决策。
无仅经典降级
新的加密和发布边界要求 ML-KEM 或 ML-DSA 证据，拒绝剥离的后量子材料。
AI 写作速度快于人类审查
生成的代码可能有用，但仍可能达到文件、网络、秘密、进程、模型或支付表面，而请求从未打算暴露这些。
广泛构建，后续约束
通用程序从环境语义开始。沙箱、IAM、容器、策略和签名围绕其添加以恢复预期边界。
先授予权限，再编译
效果和能力是已承认计算的一部分。如果目标无法证明并绑定授权，则不会发出或运行工件。
Kotoba 是对运行时和操作系统隔离的补充;它并不能使这些层变得不必要。
Lisp 的思维与 GP 2 的图重写在 Rust 的纪律中相遇
Kotoba 是一种小型、面向数据、Clojure 形态的语言。其设计借鉴了 Lisp 的代码即数据传统，并且 GP 2 的基于规则的图重写，围绕权限、效果、资源、包和工件身份的静态纪律。
代码作为可读数据
不可变值、普通函数、显式数据和可组合语法易于人类和模型生成与检查。
说明可能发生的情况
效应、能力、资源、依赖和目标是准入的可见输入——不是部署后发现的意外。
语言更少，边界更难
承认组件表面无环境互操作、运行时代码加载、不受限变异、访客定义宏或无界并发。
安全 + 快速 · 为 AI 生成软件构建。这是一个限制方向，而非“不可破解”声明。编译器、验证器、运行时、提供者、策略根、密钥托管和操作系统隔离仍在可信计算基础中。
整个计算过程中的安全性
边界从意图传递到执行。每个阶段都会缩小或验证权限；后续阶段不允许发明授权。
声明式意图
一个小型、Clojure 形态的表面保持程序可读并排除环境逃逸口。
已检查KIR
类型和传递效应成为与目标无关的、可检查的表示。
交叉权威
请求授权、委托授权、本地策略授权、资源授权和目标授权只能收窄。
定位工件
代码、依赖、策略、编译器合同和目标 ABI 绑定计算身份。
绑定于主机
运行时和提供者仅绑定允许的能力，执行有限预算，并发出收据。
内容身份不是权威。CID 验证、签名、撤销、主机策略、资源检查和操作系统隔离保持独立边界。
Lisp 求值，无环境主机求值
Kotoba 评估作为内容寻址数据的已检查代码。熟悉的 (eval request) 表面降低到类型化 :code/eval 能力；它从不接收源文本、阅读器形式、命名空间或主机对象。
什么代码？
CID 选择哈希验证的已检查 KIR 定义及其仅 CID 依赖闭包。
它能在这里运行吗？
确切接口、完整效应行、当前允许、燃料和递减的评估深度在执行前被绑定。
返回了什么？
类型化结果作为内容寻址证据持久化。其哈希不能追溯授权效果。
身份、权威和结果证据是三种不同的事实。
机器合约： lang/typed-eval.edn. 编译器线能力： 30. 有界应用仍为普通闭模块闭包应用。
AI优先计算栈的默认值
这些是带有资格说明的工程声明。默认、边界就绪、部分和方向是不同状态；没有任何状态会被默默提升为通用。
构建更快。运行更快。保持边界。
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 上，一个未压缩、非空的 Arrow float32 列保持一个 WebAssembly 线性内存备份，而 Num 在其借用值切片上执行了一个显式的 v128 f32x4 内核，零 Arrow 到 SIMD 复制；标量尾部覆盖剩余行。在同一 262,147 元素规模工作负载和工件的三次合格运行中，该 SIMD 内核比标量 Wasm 快 3.66-3.72x。这是内核与主机的结果，不是通用运行时声明。相同的有界列路径还通过其 CPU 视图保持一个 ArrayBuffer，跨越 GPU 所有权边界进行一次测量的 WebGPU 上传，在 Metal 上执行，并返回一个四字节标量。可空列、其他 Arrow 数据类型、统一内存上传移除、更广泛的内核和通用 CPU/GPU 资格仍在等待中。
AI 优先。默认代理安全。
Kotoba 设计用于由 AI 代理和机器人编写或操作的程序。模型越强，显式效果、有限资源、能力限制、收据和主机执行越重要。
AGI 准备边界，不是 AGI 声明。
该架构旨在随着模型能力的提升保持权限明确。Kotoba 不声称此处存在 AGI，生成的程序值得信赖，或隔离能移除编译器、运行时、提供者、密钥托管和操作系统的可信计算基础。
机器权限： lang/product-defaults.edn无限物理存储、零复制、普适速度排名、实现 AGI 和不可被黑客攻击仍然是禁止的绝对声明。
AI 编写的 Kotoba 不能请求的内容
| 边界 | 为何缺失 |
|---|---|
compile, load, load-file, load-string, ns-resolve, read-string, require, resolve, use
|
组件不能从环境进程状态制造代码或权限。 源字符串、读取器形式、加载的命名空间和编译的主机 对象从未进行效果推断，且不属于定义 CID。被许可的 `(eval request)` 操作因此独立： 它通过 :code/eval 选择已检查的 KIR 并由主机重新许可。 |
., .., import, new
|
任意 JVM/JS 对象和方法访问绕过能力许可。 授权调度不可放宽：互操作永远不会达到 guard-component-ability-call，因此权限交集、收据和 撤销无法看到调用。对 wasm32 ABI 无效（不存在此路径）；在可移植/受信任环境中承载负载，其中子集门是唯一边界（未声明单独的 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，函数降级为 [:result T E]， 因此环境形式在展开后不再存在。Slice 2 (2026-09-02) 使 :abort 通过调用传播，并将中止操作数或测试 A-归一化为 let 绑定； 两者均不扩展不变量，因为传播的中止在调用者行， A-归一化的则是不同位置的相同展开。 在展开前提重要的地方，中止仍被拒绝——现在对 CALL 也如此。 |
这些是 lang/surface-status.edn 中命名的安全约束，不是路线图中缺失的功能。
带边界的证明
Kotoba 将实现证据与市场牵引分开，并将剩余风险置于每个安全声明旁。
33 核心
内部生产自用
更广泛的 Kotoba 堆栈内部运行 33 推理核心。这证明团队运营自己的堆栈；这不是客户牵引、付费采用或收入。
8 声明
边界是机器可读的
安全声明命名其可信计算基础、负面证据和剩余风险，而不是简化为“不可破解”的口号。
默认拒绝
无授权，无主机效果
空策略不授予文件系统、网络、进程、时钟、模型或秘密权限。提供者还必须验证具体资源范围。
内部生产使用仅为自用证据。不意味着外部客户、付费试点或收入。
五个基准。五个不同问题。
编译器启动询问一个微小源代码变成工件的速度。构建扩展询问当源代码不再微小时该数字如何变化——以及工件是否仍有响应。开发者循环分离了解析、检查、构建和首次结果。原生运行时询问已构建代码的运行速度。工作负载域套件询问字符串、集合、分配、I/O、并发和一个小型真实应用的表现。结果保持所有五个问题及其证据状态分开。
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 原生针对 Rust、Clang / C11、Zig、Go c-shared、Swift 通过一个通用原生调用边界进行测试。
30/30 比较器/工作负载对 · 精确答案已验证
19 对 30 配对
Amu native 在 30 个比较器/工作负载对中赢得了 19，至少领先 5%，且与自身范围分开。边界最快声明需要每对，因此保持无资格——计数为信息性一半。
至少 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 运行时路径
字符串、集合、内存分配、文件 I/O、四工作线程并发,以及一个请求准入策略应用内核均已通过正确性检查。
7 样本涵盖进程冷启动和摊销路径 · 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 |
在 judahnoMac-mini.local(Apple M4)上测得 2026-08-31。K 是生成函数的数量;Kotoba 源码从 9 行增长到 14338 行。各通道的目标、ABI、优化级别和运行时契约各不相同,因此这里考察的是开发者反馈延迟,而非等价的工作量。主机负载门限检查失败(load1 为 2.73–2.73,要求 ≤ 1),因此这些是本次运行的观察结果,而非可移植的数据。由于各通道是交错运行的,排序需另行限定。
哪些排序通过噪声测试
比率不是排名。 性能门控 拒绝任何间隙落在两臂自身扩散范围内的排序， 无论比率看起来多大，且拒绝样本过少的臂或 噪声过多。此处以其默认策略运行，未放宽——一个 放宽阈值以允许此运行将是一个基准测试 其自身阈值。由于通道在一个主机上交错，一个间隙 通过此测试即表示主机繁忙时仍能存活。
| 大小 | 对比对象 | 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 通道在该规模下根本不更快。优势在冷启动时真实且有资格，但在 K=32 时对比 C，K=128 时对比 Rust 已消失。该交叉点即结果，因此展示而非总结。
两个不同的失败
本次运行中三条 Kotoba 通道停止工作，并将它们作为一个发布 行本应错误。一个是缺陷。另两个已声明 严格执行边界并报告为缺陷 意味着测量边界而非编译器。
| 观察 | 阅读中 |
|---|---|
| 发布的 kotoba CLI 发射的模块不支持超过 128 函数的编译 | 一个缺陷，也是需要在测试环境内验证的原因。在 K=129 时，调用必须携带函数索引 128，这是第一个需要两个 LEB128 字节的值，而发射器只写了一个。字节表明这不是缺失的编码器，而是未使用的：local.set 128 写为 80 01，而调用 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 在 11.753 毫秒内冷启动构建 K=1，执行工件并检查答案——这里测量的所有通道中最快的首个结果。 |
| 发布的二进制能构建多大模块？ | 最多 128 个函数。超过此数目不是更慢，而是错误，此测试架构将其报告为失败通道而非快速通道。 |
| 随着源代码增长，构建时间是否保持竞争力？ | 通过 K=128，发布的 CLI 在上表中与 Rust 和 C 进行了比较。超过该点，唯一仍能生成正确模块的 Kotoba 编译器是 Amu，它运行在 nbb 上，而非作为发布的二进制文件，并且在所有测量的大小上速度大约慢一个数量级——因此在大规模时构建速度目前不是 Kotoba 的优势，本页不会声称相反。 |
| 一个源码从头到尾构建了多大规模？ | K=1023 通过 Amu — 7163 行 Kotoba，执行工件并检查答案。比声明的 1,024 上限少一个函数，且拒绝下一个更大尺寸以避免错误构建。 |
| 发出的代码快吗？ | 此处不在范围内 — 这测量的是构建，而非运行。上述本地运行时套件回答该问题。 |
底线： 在最小尺寸下，发布的二进制比此处所有比较器都快，且差距通过噪声测试，且其正确性上限为 128 函数。 无该上限的编译器在所有尺寸上大约慢一个数量级 测量所得。两个事实来自同一次运行，发现它们的测试框架是公开的， 因此运行结果可以被异议。
每个本地工作负载实际耗时
下方网格报告两臂间距。该数值为 perfgate 规则开启，但单独的百分比并不能说明是否 工作负载运行时间为五毫秒或五百毫秒，并隐藏了 有争议对与无关对之间的差异。这些面板是 计算这些边距的中位数。Amu native 是彩色车道 出现在每个面板中——包括它不是第一位的那些面板。每个面板都是 按其自身最慢的 ARM 进行缩放，因为面板回答的问题是谁是 在该工作负载中更快。
窄算术
宽寄存器压力
深度溢出压力
调用保留
分支 + 调用控制流
循环回调边
5 次符合主机条件的运行的中位数毫秒数;越短越快。每个分支都返回了同一个经独立校验的答案,且候选中位数是每个工作负载一个值——测试套件以 ABBA/BAAB 顺序轮换每个引擎对,因此同一个 Amu 制品在每个工作负载下计时一次,然后依次与每个分支比较。与页面上其他四个基准测试不同,这一项的安静主机门限检查通过(qualified-host-load),因此这些是该主机的数据,而不仅仅是观察结果。有界的最快声明仍需要全部 30 个引擎对,这正是下方网格的用途。
每对运行时，无论胜负
有界声明是全有或全无，因此单个不合格对使其为假。 仅发布该裁决会隐藏哪些配对存在争议，因此整个 网格在这里。单元格是Amu本地相对于该比较器的平均改进 在该工作负载上；正值表示 Amu 更快，勾选标记获胜配对 清晰的性能门槛 — 至少 5%，且与ARM自身的扩散分开。
| 工作负载 | 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 本地更快，左侧更慢。两个方向分别缩放——胜利延伸至 +93%，失败仅至 −7%，因此共享刻度会将所有有争议对压平为同一不可见细条。符号也由线侧和带符号数字携带，因此读取此网格不依赖区分两种颜色。
19 的 30 对合格（中位数为 5；每次运行均为 19）· 候选 42f092ea5b61 · Apple M4，10 逻辑CPU，16 GiB
发布运行后的优化交付
上述过时基准保持不变。新实现切片单独列出，直到相同工件套件重新运行并通过其资格门。
| 表面 | 已交付 | 证据边界 |
|---|---|---|
| 本地向量 / 分配 | 有界非逃逸向量字面量在 x86-64 和 AArch64 上经过逃逸证明和标量替换。 | 211 后端测试 / 2,442 断言；逃逸向量保留已检查的主机 ABI。尚无新的排名计时。 |
| 字符串 SIMD | POSIX 检查的相等性使用显式 16 字节 NEON 或 SSE2 比较，先进行句柄和规范 UTF-8 验证。 | 优化的汇编和本地 ISA 语义向量均已验证。Windows 仍单独固定；延迟排名待定。 |
| 异步输入/输出能力 | 根限制的最终读/写/列出/存在/删除在 JVM 上使用 CompletableFuture，在 Node 上使用 fs.promises。 | JVM 和 Node 真实文件系统测试通过。公共独立 Wasm 基准仍无承认的主机绑定，因此其 I/O 单元仍为 N/A。 |
| 结构化并发 | 有界的 32 子快速失败作用域加入、取消兄弟，并防止子生命周期逃逸为规范 Kotoba 状态。 | 996 跨 .kotoba 权限和 CLJC 加载路径的等价断言。这是结构化生命周期语义，不是操作系统线程吞吐量结果。 |
| Kotoba CLI | kotoba 测试/构建使用新的编译器固定；kotoba 编译直接发出封闭的 x86-64 和 AArch64 KEXE。 | 公开 CLI 生命周期和 AArch64 向量工件已验证。原生 --run 在测量加载器收据接入前仍被拒绝。 |
编译器启动，四个工具链
单个微小源文件的进程冷启动墙钟时间,单位毫秒;越短越快。每个工具链在 Apple M4 上轮换 21 个样本。本次运行的主机负载门限检查失败,因此这些只是对单台机器的观察,不是排名。
| 工具链 | 输出 | 中位数 | 第95百分位 | 相对经过时间 |
|---|---|---|---|---|
| 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 发出类文件。不同目标和编译器工作使这成为启动观察，而非通用排名。记录的主机负载门失败，因此表格不是合格的速度排名。
| 工具链 / 目标 | 解析 | 检查 | 干净构建 | 无变更构建 | 启动 + 执行 | 干净构建 + 首个结果 |
|---|---|---|---|---|---|---|
| Kotoba · WebAssembly | 不适用 | 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 原生 | 不适用 | 90.446 ms | 121.838 ms | 77.905 ms | 327.741 ms | 453.685 ms |
| Zig · WebAssembly | 不适用 | 387.713 ms | 648.665 ms | 464.795 ms | 67.523 ms | 728.007 ms |
| TinyGo · arm64 macOS 原生 | 不适用 | 不适用 | 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 类 | 不适用 | 不适用 | 805.822 ms | 739.957 ms | 76.252 ms | 882.074 ms |
| AssemblyScript · WebAssembly | 不适用 | 1074.197 ms | 895.187 ms | 1090.658 ms | 64.658 ms | 954.878 ms |
| .NET IL · .NET IL | 2309.472 ms | 不适用 | 4750.407 ms | 2141.103 ms | 79.248 ms | 4851.792 ms |
| .NET Native AOT · arm64 macOS 原生 AOT | 2236.962 ms | 不适用 | 11995.489 ms | 2707.907 ms | 375.7 ms | 12391.54 ms |
每个发射工件在新进程中生成 42。目标和运行时合约不同；不适用绝不为零。主机加载门禁失败，因此这些是可复现观察，而非跨语言速度排名。
六个领域，并排展示
每个面板按其最慢通道缩放，因为面板的问题 答案是哪个领域更快，而不是领域之间的比较 其他。Kotoba 的车道是每个面板中带颜色的那条——包括 面板中最后的。其独立 Wasm 工件通过 Node 运行 主机并为每个进程冷启动样本支付费用，而 Rust、C 和 Go 作为本地二进制运行；目标无环境文件系统或线程时 合约不存在时，通道缺失而非为零。
字符串
集合
分配
输入/输出
并发
真实应用
进程冷启动中位数，单位毫秒；越短越快。主机负载门控 本次运行失败，因此这些面板是观察结果而非排名， 下方的摊销通道又讲述了不同的故事。
| 运行时路径 | 字符串 | 集合 | 分配 | 文件 I/O | 并发 | 真实应用 |
|---|---|---|---|---|---|---|
| Kotoba / Wasm + 类型化 JS 主机 | 30.539 ms | 29.98 ms | 29.567 ms | 不适用 | 不适用 | 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；其独立目标没有环境文件系统或线程契约，因此这些单元被视为不适用。记录的主机加载门失败，因此中位数是观察值，而非排名。
| 运行时路径 | 字符串 | 集合 | 分配 | 文件 I/O | 并发 | 真实应用 |
|---|---|---|---|---|---|---|
| Kotoba / Wasm + 类型化 JS 主机 | 0.351 ms | 0.039 ms | 0.066 ms | 不适用 | 不适用 | 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 的纯 inc/dec 映射链被融合进 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 本地与 Rust、Clang / C11、Zig、Go c-shared、Swift | 所有 30 语义比较单元完整；因静默主机门失败，速度排名保留 |
| 字符串、集合、分配、输入/输出、并发和真实应用 | Kotoba、Rust、C、Go、JVM 和 JavaScript 运行时路径 | 发布了精确校验和及冷启动加摊销采样；独立 Kotoba I/O 和线程不适用，其纯请求准入应用被测量；失败的加载门禁阻止排名。 |
本地套件涵盖内容
每个实现返回一个独立检查的已知答案。测试套件以 ABBA/BAAB 顺序轮换每对引擎，并在加载、映射和符号查找后进行测量。
| 工作负载 | 它强调的内容 | 证据状态 |
|---|---|---|
| 窄算术 | 精确结果已验证；时间未认证 | |
| 宽寄存器压力 | 精确结果已验证；时间未认证 | |
| 深度溢出压力 | 精确结果已验证；时间未认证 | |
| 调用保留 | 精确结果已验证；时间未认证 | |
| 分支 + 调用控制流 | 精确结果已验证；时间未认证 | |
| 循环回调边 | 精确结果已验证；时间未认证 |
每个基准所在位置
上述每个数字均来自公共工具和已提交报告，因此 运行可以重复，声明可以被反对。仓库内路径在 此表在生成此页面时与工作树核对： 一个使失败导致构建失败而非发布死链接的测试工具。
本页所有排序均通过的门槛是 kotoba-lang/perfgate，以其自身未放宽的默认策略运行。阈值放宽以允许 运行过程将是测量自身阈值的基准。
底线： 所有五个基准中的工件、精确结果和样本均真实。三者——编译器启动、开发者循环和工作负载域——未通过其静默主机门槛，因此排名为零，作为观察发布。本地运行时套件通过其门槛，赢得了 19 的 30 对，未达到每对声明所需。构建扩展在主机上针对每个比较器验证其冷启动排序，并在同次运行中发现正确性上限。此页未声明任何通用速度排名，且无任何运行授权此类排名。
附带边界的声明
这些声明来源于 lang/safety-claims.edn。每个保持其可信计算基础和剩余风险可见，因为没有边界的安全口号只是营销。
被承认的组件不能访问运行时/本地内存，且组件内存操作有界或陷阱。
可信计算基础
有界读取器 · 前端准入 · 工件验证器 · Wasm/本地运行时
剩余风险
- 运行时引擎漏洞仍存在于TCB中
- 本地加载器需要第二个操作系统隔离边界
每个传递组件效应在发射前均被声明和承认，包括 Kotoba 编写的提供者使用的效应。
可信计算基础
效果推断 · 能力目录 · 前端调用图
剩余风险
- kotoba 和编译器语法/效果必须持续比较
未授予的能力缺失或未绑定，无法访问提供者或本地处理程序。
可信计算基础
策略交集 · 编译器导入发射 · 招标导入绑定 · 主机保护
剩余风险
- 提供者和原生实现必须独立验证资源范围
- 生产环境的有效授权必须禁止通配符作用域
相同的已承认源、目标、策略和锁产生相同的可观察纯结果和工件字节。
可信计算基础
规范读取器 · 确定性降级 · 固定工具链
剩余风险
- 主机效应仅在其能力合约明确规定时才是确定性的
源代码、准入、执行、内存和输出使用明确的有限边界。
可信计算基础
准入限制 · 燃料计量 · 运行时配额 · 监管超时
剩余风险
- 平台监管者尚无同等生产隔离证据
发布准入绑定工件身份、可信签名者、有效性和可复现证据。
可信计算基础
签名验证器 · 可信签名者配置 · 时钟 · 吊销集
剩余风险
- 密钥托管和外部撤销分发保持操作可信计算基（TCB）
共享的可移植组件在合格后端之间具有相等的接受度、结果和效果跟踪。
可信计算基础
共享合规清单 · 后端适配器 · 比较运行器
剩余风险
- 仅编译器特性不可移植,必须被可移植配置拒绝
组件导入仅在具有具体的后交集资源范围时到达其提供者或本地处理程序，并发出收据。
可信计算基础
能力交集 · 宿主守卫 · 提供者处理器 · 回执接收端
剩余风险
- 提供者特定路径、重定向、符号链接和租户检查需要 Q5 工具包
资格认定 第一季度截至 2026-07-18.
发布绑定
在签名信封将二者绑定之前,语言配置与实现发布是相互独立的。
配置文件 6
包契约 1
v0.7.0
配置绑定： 已验证
已发布
:docs/release-bound-profile
Kotoba v0.7.0 适用于 darwin-arm64，是绑定到语言配置文件 6 和包契约 1 的公共实现。其签名信封验证源代码树、工件摘要以及 536-测试 / 8,580-断言符合性结果。其他平台仍未绑定。
读取生成的发布证据六十秒内开始
安装和自检
brew tap kotoba-lang/kotoba
brew trust kotoba-lang/kotoba
brew install kotoba
kotoba selfhost check --json接受带有空问题列表的有效响应。
第一个程序
(defn main []
(+ 40 2))该程序不请求主机导入；发出的模块无导入。
学习，尝试，然后深入
从第一个程序到语言合同、库、证据和部署表面的连接路径。
一个小的 Kotoba 程序,真实运行
Amu 将此纯 Kotoba 源代码编译为 wasm32-browser 配置。已签入工件无导入，返回 42。
;; 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
运行已验证工件
浏览器获取 344 字节，验证 SHA-256，拒绝所有导入，实例化模块，并调用 main()。
预期结果：
42
准备就绪。尚未运行任何代码。
这执行预编译的不可变示例。浏览器中编辑任意源代码尚未作为已发布的编译器表面。
交互式演示： solar-helix（访客驱动的 WebGPU 渲染） · kami-survivors（一个 .kotoba 游戏） · gpu-clear（WebGPU 烟雾测试）. 托管于 wasm-webcomponent GitHub Pages 表面；可用性取决于浏览器 WebGPU/WebAssembly 支持。
库，无需隐藏包边界
Kotoba 库是内容寻址图。名称和 GitHub 仓库帮助人们发现它们；定义和签名发布 CID 精确说明它们是什么。
按标签浏览整个组织
有 2,215 公共仓库位于 kotoba-lang 组织。以下每个标签都是 GitHub 的主题标签,属于 相同名称，因此站点过滤器和组织的主题是同一词汇表 而非两个漂移。选择一个打开已过滤的目录。
代码库不是已发布的软件包。仅通过内容寻址注册表发布了确切的 1 库；此列表其余部分为发现。代码库成熟度标签不意味着 1.0 API 稳定性、广泛采用或生产级 SLO，且 255 代码库不符合任何领域规则，显示为无标签而非赋予最近标签。
搜索已检查的参考
搜索命令、标准库名称、诊断和发布状态。索引由机器权威生成，保留在此页面。
尝试：编译、选项-某些、文档/链接缺失
发布绑定
Kotoba v0.7.0 适用于 darwin-arm64，是绑定到语言配置文件 6 和包契约 1 的公共实现。其签名信封验证源代码树、工件摘要以及 536-测试 / 8,580-断言符合性结果。其他平台仍未绑定。
开放参考
kotoba compile
将 Kotoba 系列源代码编译为目标产物。Web .kotoba 使用已检查的 KIR 和受限的 kotoba-script 后端；.cljs 仍为 ClojureScript。
开放参考没有查询离开浏览器。
路线图：仅在边界成立后扩展
一个版本化合同
保持语法、效果、已检查 KIR、目标适配器、合格及首次运行文档一致。
弥合提供者差距
扩展类型请求/结果一致性、对抗测试、收据、撤销和可复现发布操作。
获得更广泛部署
在提供者、主机隔离、回滚和浸泡证据之后扩大生产使用——并发展可检查的声明式库。
路线图条目仅代表方向,不是对已交付能力或交付日期的承诺。
公开构建社区
Kotoba 尚未声称拥有庞大社区。当前诚实的公共聚集点是源代码仓库、问题跟踪器、发布历史和安全频道。
资助公共边界，而非购买权限
Kotoba GitHub 赞助者配置正在准备中。项目页面已就绪，只有在 GitHub 批准组织配置后才会显示付款操作。
支持不等于权威
赞助不购买功能、路线图优先级、支持SLA、私人访问或安全例外。
赞助状态： 准备中已检查 2026-09-01.
安全代码。可信状态。受控执行。
这些服务保持独立的权威、可用性和资格边界。它们的连接并不证明每个 Kotoba 能力作为普遍销售的托管服务均可用。
阅读合同或运行实现
语言配置文件 6;public-default 发布状态: 已发布.
主要可移植平台是带 WASI 的 WebAssembly 组件 0.3.0。展开管道具有 11 命名、失败关闭阶段。