;; 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 · कच्चा · 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-जनित सॉफ़्टवेयर के लिए डिज़ाइन की गई है। निरीक्षण योग्य प्रोग्राम, स्पष्ट क्षमताएं, और सामग्री-आधारित कलाकृतियां संकलक जांचों को नियंत्रित निष्पादन से जोड़ती हैं।

सबसे तेज़ ठंडा बिल्ड · 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 क्रम सफल परफगेट अपने अनरिलैक्स्ड डिफ़ॉल्ट नीति पर — कम से कम 5% और इससे अलग हथियारों का अपना फैलाव — इसलिए आदेश बरकरार रहता है भले ही होस्ट व्यस्त था। इस होस्ट, इस स्रोत आकार और इस रन तक सीमित: बिल्ड समय नहीं है कार्य निष्पादन गति, स्रोत बढ़ने पर लाभ संकुचित होता है, और जारी किया गया बाइनरी की कठोर शुद्धता सीमा होती है। सभी पांच बेंचमार्क, जिनमें शामिल हैं जो Kotoba के खिलाफ जाते हैं, नीचे हैं। मापा गया 2026-08-31 चालू एप्पल M4.

पांच बेंचमार्क देखें नमूनों का निरीक्षण करें

जब AI लगातार कोड उत्पन्न, निर्माण, परीक्षण और पुनः उत्पन्न करता है, तो निर्माण विलंब अवसंरचना थ्रूपुट बन जाता है।

इंस्टॉल करें और चलाएं देखें यह कैसे काम करता है AI एजेंट सेटअप

डिफ़ॉल्ट रूप से अस्वीकृत

कोई परिवेशीय अधिकार नहीं

कोई निहित फाइल सिस्टम, नेटवर्क, प्रक्रिया, घड़ी, मॉडल, या गुप्त नहीं।

जांच किया गया KIR

अधिकार संकलन के बाद भी जीवित रहता है

प्रकार, प्रभाव, संसाधन, और लक्ष्य समर्थन उत्सर्जन से पहले स्वीकार किए जाते हैं।

होस्ट द्वारा लागू किया गया

केवल अनुदान बंधित है

होस्ट और प्रदाता ठोस दायरा लागू करते हैं और निर्णय रिकॉर्ड करते हैं।

पोस्ट-क्वांटम फर्श

कोई केवल क्लासिकल डाउनग्रेड नहीं

नई एन्क्रिप्शन और प्रकाशन सीमाएं ML-KEM या ML-DSA साक्ष्य की आवश्यकता रखती हैं और स्ट्रिप्ड PQ सामग्री को अस्वीकार करती हैं।

01 समस्या

AI मनुष्यों की तुलना में तेज़ लिख सकता है

उत्पन्न कोड उपयोगी हो सकता है और फिर भी एक फ़ाइल, नेटवर्क, गुप्त, प्रक्रिया, मॉडल, या भुगतान सतह तक पहुंच सकता है जिसे अनुरोध ने कभी उजागर करने का इरादा नहीं किया।

पुराना डिफ़ॉल्ट

व्यापक रूप से बनाएं, बाद में प्रतिबंधित करें

एक सामान्य प्रयोजन प्रोग्राम परिवेशीय अर्थशास्त्र के साथ शुरू होता है। सैंडबॉक्स, IAM, कंटेनर, नीति, और हस्ताक्षर इसके चारों ओर जोड़े जाते हैं ताकि इच्छित सीमा पुनः प्राप्त हो सके।

कोटोबा डिफ़ॉल्ट

संकीर्ण रूप से अनुमति दें, फिर संकलित करें

प्रभाव और क्षमताएं स्वीकृत गणना का हिस्सा हैं। यदि लक्ष्य अनुदान को प्रमाणित और बाइंड नहीं कर सकता, तो यह कलाकृति को जारी या चलाता नहीं है।

Kotoba रनटाइम और OS पृथक्करण को पूरक करता है; यह उन परतों को अनावश्यक नहीं बनाता।

जहां Lisp का मन और GP 2 का ग्राफ़ पुनर्लेखन Rust के अनुशासन से मिलता है

Kotoba एक छोटा, डेटा-केंद्रित, Clojure-आकार की भाषा है। इसका डिज़ाइन Lisp के कोड-एज़-डेटा परंपरा से प्रेरित है और GP 2 का नियम-आधारित ग्राफ पुनर्लेखन, प्राधिकरण, प्रभाव, संसाधन, पैकेज, और कलाकृति पहचान के चारों ओर स्थैतिक अनुशासन के साथ।

सहज

कोड को पठनीय डेटा के रूप में

अपरिवर्तनीय मान, सामान्य फ़ंक्शन, स्पष्ट डेटा, और संयोज्य सिंटैक्स मनुष्यों और मॉडलों के लिए उत्पादन और निरीक्षण में आसान हैं।

घोषणात्मक

क्या हो सकता है बताएं

प्रभाव, क्षमताएं, संसाधन, निर्भरताएं, और लक्ष्य प्रवेश के लिए दृश्य इनपुट हैं—परिनियोजन के बाद खोजे गए आश्चर्य नहीं।

सुरक्षा-प्रथम

कम भाषा, कठिन सीमा

स्वीकृत कंपोनेंट सतह में कोई परिवेशीय इंटरऑप, रनटाइम कोड लोडिंग, असीमित म्यूटेशन, अतिथि-परिभाषित मैक्रोज़, या असीमित सामयिकता नहीं।

सुरक्षित + तेज · AI-जनित सॉफ़्टवेयर के लिए निर्मित।
यह एक प्रतिबंध दिशा-निर्देश है, 'अहैक करने योग्य नहीं' दावा नहीं। कंपाइलर, सत्यापनकर्ता, रनटाइम, प्रदाता, नीति मूल, कुंजी संरक्षण, और OS पृथक्करण विश्वसनीय कंप्यूटिंग आधार में बने रहते हैं।

02 सीमा कैसे काम करती है

पूरे गणना में सुरक्षा

सीमा इरादे से निष्पादन तक ले जाई जाती है। प्रत्येक चरण प्राधिकरण को संकीर्ण या सत्यापित करता है; बाद के किसी भी चरण को कोई अनुदान आविष्कार करने की अनुमति नहीं है।

1 · स्रोत

घोषणात्मक इरादा

एक छोटा, Clojure-आकार सतह प्रोग्रामों को पठनीय रखता है और परिवेशीय बच निकलने के रास्तों को बाहर करता है।

2 · जांच

जांचित KIR

प्रकार और पारगामी प्रभाव एक लक्ष्य-स्वतंत्र, निरीक्षणीय प्रतिनिधित्व बन जाते हैं।

3 · प्रवेश करें

प्राधिकरण का छेदन

अनुरोधित, प्रतिनिधि, स्थानीय-नीति, संसाधन, और लक्ष्य अनुदान केवल संकीर्ण कर सकते हैं।

4 · पहचान

कलाकृति को संबोधित करें

कोड, निर्भरता, नीति, कंपाइलर अनुबंध, और लक्ष्य ABI गणना की पहचान को बांधते हैं।

5 · प्रवर्तन

होस्ट पर बाइंड करें

रनटाइम और प्रदाता केवल स्वीकृत क्षमताओं को बांधते हैं, सीमित बजट लागू करते हैं, और रसीदें जारी करते हैं।

सामग्री पहचान प्राधिकरण नहीं है।
CID सत्यापन, हस्ताक्षर, निरस्तीकरण, होस्ट नीति, संसाधन जांच, और OS पृथक्करण अलग सीमाएं बनी रहती हैं।

Lisp मूल्यांकन, बिना परिवेशीय होस्ट मूल्यांकन के

Kotoba जांचे गए कोड का मूल्यांकन सामग्री-संबोधित डेटा के रूप में करता है। परिचित (eval request) सतह टाइप किए गए तक नीचे आती है :code/eval क्षमता; यह कभी स्रोत पाठ, एक रीडर फॉर्म, एक नामस्थान, या एक होस्ट ऑब्जेक्ट प्राप्त नहीं करता।

परिभाषा CID

कौन सा कोड?

CID एक हैश-सत्यापित जाँचे गए-KIR परिभाषा और उसके CID-केवल निर्भरता समापन का चयन करता है।

प्रवेश CID

क्या यह यहाँ चलेगा?

सटीक इंटरफ़ेस, पूर्ण प्रभाव पंक्ति, वर्तमान भत्ता, ईंधन, और घटती मूल्यांकन गहराई निष्पादन से पहले बंधित होती हैं।

मूल्य CID

क्या वापस आया?

टाइप किया गया परिणाम सामग्री-संबोधित साक्ष्य के रूप में स्थायी होता है। इसका हैश प्रभाव को पीछे से अधिकृत नहीं कर सकता।

पहचान, प्राधिकरण, और परिणाम साक्ष्य तीन अलग तथ्य हैं।

मशीन अनुबंध: lang/typed-eval.edn. संकलक वायर क्षमता: 30. सीमित लागू सामान्य बंद-मॉड्यूल समापन आवेदन रहता है।

AI-प्रथम कंप्यूटिंग स्टैक के लिए डिफ़ॉल्ट

ये इंजीनियरिंग दावे हैं जिनके साथ उनकी योग्यता जुड़ी है। डिफ़ॉल्ट, सीमित-तैयार, आंशिक, और दिशा विभिन्न अवस्थाएँ हैं; कोई भी चुपचाप सार्वभौमिक में बढ़ावा नहीं पाता।

दिशा मापा गया

तेज़ बनाएं। तेज़ चलाएं। सीमा बनाए रखें।

Kotoba कंपाइलर-स्टार्टअप, डेवलपर-लूप, नेटिव-रनटाइम, और वर्कलोड-डोमेन मापन सटीक परिणाम जांच के साथ प्रकाशित करता है। वर्तमान गति रैंक तब तक रोकी जाती है जब तक उनके शांत-होस्ट गेट पास न हों; सुरक्षा स्वीकृति कभी भी समय जीतने के लिए हटाई नहीं जाती।

तैयार सीमित

भाषा सीमा के बिना भंडारण।

Kotobase सामग्री पहचान, रेंज रीड्स, अपरिवर्तनीय इतिहास, और प्रदाता-तटस्थ भंडारण का उपयोग करता है। भौतिक क्षमता, किरायेदारी, प्रतिधारण, लागत, प्रतिकृति, और निष्पादन बजट स्पष्ट रहते हैं; यह अनंत-डिस्क दावा नहीं है।

डिफ़ॉल्ट

डिफ़ॉल्ट रूप से पोस्ट-क्वांटम क्रिप्टोग्राफी।

हर नया Kotoba क्रिप्टोग्राफिक सीमा ML-KEM या ML-DSA साक्ष्य का नाम देना चाहिए और केवल क्लासिकल डाउनग्रेड को अस्वीकार करना चाहिए। मौजूदा Passkeys, ट्रांसपोर्ट, कार्यान्वयन, और कुंजी संरक्षण अलग-अलग योग्य सीमाएं बनी रहती हैं।

डिफ़ॉल्ट

प्रमाणीकरण मौजूद है। प्राधिकरण डिफ़ॉल्ट रूप से अस्वीकृत।

Passkey पहचान नियंत्रण सीमा पर होनी चाहिए। एक सत्यापित पहचान तब भी कोई फ़ाइल सिस्टम, नेटवर्क, भंडारण, मॉडल, गुप्त, भुगतान, या GPU प्राधिकरण प्राप्त नहीं करती जब तक कि एक स्पष्ट स्कोप्ड ग्रांट स्थानीय नीति और होस्ट जांचों को पार न कर जाए।

तैयार सीमित

लचीला प्रतिनिधित्व जो केवल संकीर्ण कर सकता है।

अनुरोधित, प्रतिनिधि, स्थानीय-नीति, संसाधन, और लक्ष्य स्कोप्स इंटरसेक्ट करते हैं। प्रतिनिधित्व संयोजित और कम किया जा सकता है, लेकिन परिवेशीय प्राधिकरण नहीं बना सकता या इसके जारीकर्ता के अनुदान को विस्तृत नहीं कर सकता।

तैयार सीमित

Web3 तैयार, मूल पर चेन-तटस्थ।

एक स्थिर Kotoba प्रिंसिपल और Passkey नियंत्रक प्राथमिक हैं। CAIP-10 खाते, ERC-1271, और ERC-6492 स्पष्ट लिंक किए गए खाते के प्रमाण हैं; एक वॉलेट पता कभी भी चुपचाप संग्रह या निष्पादन प्राधिकरण नहीं बनता।

आंशिक कार्यान्वित

जहाँ स्वामित्व अनुमति देता है शून्य-कॉपी; जहाँ सीमा आवश्यक हो एक कॉपी।

कॉलम-आधारित बाइट दृश्य वेक्टर, डायरेक्ट ByteBuffer, और Uint8Array बैकिंग को बनाए रखते हैं। एरो प्रोजेक्शन अधिकृत Kotobase लेक पथ के माध्यम से बिना संपीड़ित बफ़र्स कॉलम-आधारित रख सकता है। नेटवर्क इनग्रैस, डीकोम्प्रेशन, GPU अपलोड, और अपरिवर्तनीय स्थायी अपडेट नामित कॉपी सीमाएं बनी रहती हैं।

आंशिक कार्यान्वित

तीर के आकार का डेटा। स्पष्ट CPU SIMD और डिवाइस-नेटिव GPU कर्नेल।

Apple M4 पर, एक अनकंप्रेस्ड, गैर-नल योग्य Arrow float32 कॉलम ने एक WebAssembly रैखिक-स्मृति बैकिंग बनाए रखा जबकि Num ने अपने उधार लिए गए मान स्लाइस पर एक स्पष्ट v128 f32x4 कर्नेल चलाया जिसमें शून्य Arrow-to-SIMD प्रतियां थीं; एक स्केलर पूंछ ने शेष पंक्तियों को कवर किया। एक ही 262,147-तत्व पैमाने के कार्यभार और कलाकृति के तीन योग्य रन में, उस SIMD कर्नेल ने स्केलर Wasm की तुलना में 3.66-3.72x तेज़ी से पूरा किया। यह एक कर्नेल-और-होस्ट परिणाम है, सामान्य रनटाइम दावा नहीं। वही सीमित कॉलम पथ एक ArrayBuffer को इसके CPU दृश्य के माध्यम से भी बनाए रखता है, GPU स्वामित्व सीमा को एक मापा WebGPU अपलोड के साथ पार करता है, Metal पर निष्पादित होता है, और एक चार-बाइट स्केलर लौटाता है। नल योग्य कॉलम, अन्य Arrow dtype, एकीकृत-स्मृति अपलोड हटाना, व्यापक कर्नेल, और सार्वभौमिक CPU/GPU योग्यता लंबित हैं।

डिफ़ॉल्ट

एआई प्रथम। एजेंट-सुरक्षित डिफ़ॉल्ट रूप से।

Kotoba उन प्रोग्रामों के लिए डिज़ाइन किया गया है जो AI एजेंट और बॉट्स द्वारा लिखे या संचालित होते हैं। मॉडल जितना मजबूत होगा, उतना ही महत्वपूर्ण स्पष्ट प्रभाव, सीमित संसाधन, क्षमता संगरोध, रसीदें, और होस्ट प्रवर्तन हो जाते हैं।

दिशा

AGI-तैयार सीमाएं, AGI दावा नहीं।

यह वास्तुकला अधिक सक्षम मॉडल बनने पर अधिकार को स्पष्ट रखने के लिए बनाई गई है। Kotoba यह दावा नहीं करता कि AGI यहाँ मौजूद है, कि उत्पन्न प्रोग्राम विश्वसनीय हैं, या कि संगरोध कंपाइलर, रनटाइम, प्रदाता, कुंजी-रखरखाव, और OS विश्वसनीय कंप्यूटिंग बेस को हटाता है।

मशीन प्राधिकरण: 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 ऑब्जेक्ट और मेथड एक्सेस क्षमता प्रवेश को बायपास करता है। अनरिलैक्सेबल ग्रांट डिस्पैच द्वारा: इंटरऑप कभी नहीं पहुंचता गार्ड-कंपोनेंट-क्षमता-कॉल तक, इसलिए ग्रांट इंटरसेक्शन, रसीदें और निरस्तीकरण कॉल को नहीं देख सकते। wasm32 ABI पर व्यर्थ (ऐसा कोई पथ मौजूद नहीं है); पोर्टेबल/विश्वसनीय पर भार वहन करता है, जहां उपसमूह गेट एकमात्र सीमा है (वहाँ कोई अलग VM सैंडबॉक्स दावा नहीं किया गया)।
`alter-var-root, atom, binding, deref, dosync, ref, reset!, set!, swap!, var, volatile!`	बाहरी परिवर्तनीय स्थिति प्रदाता-स्वामित्व वाली और क्षमता/नीति मध्यस्थता वाली होती है; घटक-स्थानीय स्थिति को स्पष्ट रूप से सीमित मॉडल का उपयोग करना चाहिए। अपरिवर्तनीय AMBIENT है, स्वयं उत्परिवर्तन नहीं। 2026-09-02 के बाद पढ़ना दो परिणाम देता है न कि एक। एक सेल जो बच निकलता है, स्थायी रहता है, या एक फ़ंक्शन को पार करता है वह प्रदाता-स्वामित्व वाली होती है और :state-kit-desugar पथ पर रहती है (प्रभाव पंक्ति :state दिखाती है, एक अनुदान इंस्टैंसिएशन पर आवश्यक है, क्षमता हैंडल संग्रहित मान के रूप में अस्वीकृत होते हैं)। एक सेल जो ऐसा नहीं करता -- (let [a (atom 0)] (swap! a + 1) @a) -- उसे होस्ट की बिल्कुल भी आवश्यकता नहीं है: स्थानीय-स्थिति स्लाइस 1 इसे सामान्य let पुनःबाध्यताओं में विस्तृत करता है, इसलिए इसे केवल सीधे-लाइन कोड देखता है जो इसका मालिक है और रनटाइम पर कोई सेल मौजूद नहीं होता। atom / swap! / reset! / deref इसलिए elaboration के माध्यम से स्वीकृत हैं, और जैसे ही सेल बच निकलता है, अस्वीकृत कर दिए जाते हैं। ref / dosync / volatile! / binding / var / alter-var-root / set! के लिए कोई क्षमता मॉडल निर्धारित नहीं है और वे अस्वीकृत फेल-क्लोज्ड रहते हैं।
`agent, future, locking, pmap, send, send-off`	कंपोनेंट शेड्यूलिंग और संसाधन को टेंडर-नियंत्रित और सीमित रहना चाहिए। न तो परिभाषा CIDs और न ही प्रतिनिधि अनुदान CPU या शेड्यूलिंग को मापते हैं; ईंधन प्रति-इंस्टेंस है और परिवेशीय थ्रेड इससे बच जाएंगे। एक संरचित-स्पॉन क्षमता उप-बजटेड ईंधन के साथ डिजाइन योग्य है लेकिन अभी तक निर्णय नहीं लिया गया है; कोई विस्तृत मार्ग नहीं है।
`defmacro`	सुरक्षित घटक सतह को निष्पादन से पहले स्थैतिक रूप से निरीक्षण योग्य होना चाहिए। अनछूट: विस्तार कंपाइलर के अंदर कोड निष्पादित करता है (निर्माण समय), और परिभाषा CID हैश पोस्ट-डेसुगार टाइप्ड KIR होते हैं, इसलिए असीमित मैक्रोज़ जल्दी चलते हैं और स्रोत पहचान अवलोकनीय नहीं बनाते। defdesugar (सीमित शुद्ध डेसुगार) स्वीकृत विकल्प रहता है।
`catch, throw, try`	एम्बिएंट throw/try/catch ट्रैक न किए गए गैर-स्थानीय नियंत्रण प्रवाह हैं: यह निकास करता है स्कोप्स जिन्हें अनुमानित प्रभाव पंक्ति कभी नहीं बताती और अनवाइंड दायित्वों को छोड़ देता है (डेटास्पेस फेसट रिट्रैक्शन में अभी कोई जांचा गया अनवाइंड नहीं है)। प्रतिबंध एम्बिएंट रूप पर है। चूंकि 2026-09-02 से टाइप किया गया एबॉर्ट क्षमता सिरों को विस्तार द्वारा स्वीकार करती है: प्रभाव अनुमानित पंक्ति में :abort के रूप में प्रकट होता है और फ़ंक्शन [:result T E] में नीचे आता है, इसलिए एम्बिएंट रूप विस्तार के बाद कभी मौजूद नहीं रहता। स्लाइस 2 (2026-09-02) ने :abort को कॉल्स के माध्यम से फैलाया और एक ए-नॉर्मलाइज़्ड एबॉर्टिंग ऑपरेन्ड या परीक्षण को एक लेट बाइंडिंग में बदला; कोई भी अपरिवर्तनीय को विस्तृत नहीं करता, क्योंकि फैलाया गया एबॉर्ट कॉलर की पंक्ति पर होता है और एक ए-नॉर्मलाइज़्ड वही विस्तार है एक अलग स्थिति में। जहां अनवाइंड पूर्वशर्त मायने रखती, एबॉर्ट अस्वीकृत रहता है -- अब एक CALL के लिए भी और एक throw के लिए भी।

ये lang/surface-status.edn में नामित सुरक्षा प्रतिबंध हैं, रोडमैप से गायब सुविधाएँ नहीं।

03 साक्ष्य

प्रमाण, सीमा संलग्न के साथ

Kotoba कार्यान्वयन साक्ष्य को बाजार ट्रैक्शन से अलग करता है और हर सुरक्षा दावे के पास अवशिष्ट जोखिम रखता है।

33 कोर

आंतरिक उत्पादन डॉगफूडिंग

चौड़ा Kotoba स्टैक आंतरिक रूप से 33 इन्फेरेंस कोर चलाता है। यह साबित करता है कि टीम अपना स्टैक संचालित करती है; यह ग्राहक ट्रैक्शन, भुगतान स्वीकृति, या राजस्व नहीं है।

8 दावे

सीमाएं मशीन-पठनीय हैं

सुरक्षा दावे अपने विश्वसनीय कंप्यूटिंग बेस, नकारात्मक साक्ष्य, और अवशिष्ट जोखिम का नाम देते हैं बजाय इसके कि वे 'अहैक करने योग्य नहीं' के नारे में समाहित हो जाएं।

डिफ़ॉल्ट रूप से अस्वीकृत

कोई अनुदान नहीं, कोई होस्ट प्रभाव नहीं

एक खाली नीति कोई फ़ाइल सिस्टम, नेटवर्क, प्रक्रिया, घड़ी, मॉडल, या गुप्त प्राधिकरण नहीं देती। प्रदाताओं को ठोस संसाधन दायरा भी मान्य करना चाहिए।

आंतरिक उत्पादन उपयोग केवल डॉगफूडिंग साक्ष्य है। इसका अर्थ बाहरी ग्राहक, भुगतान किए गए पायलट, या राजस्व नहीं है।

पांच बेंचमार्क। पांच अलग-अलग प्रश्न।

कंपाइलर स्टार्टअप पूछता है कि एक छोटा स्रोत कितनी जल्दी एक कलाकृति बन जाता है। बिल्ड स्केलिंग पूछता है कि जब स्रोत छोटा होना बंद हो जाता है तो उस संख्या का क्या होता है—और क्या कलाकृति अभी भी उत्तर देती है। डेवलपर लूप समाधान, जांच, बिल्ड, और पहला परिणाम अलग करता है। नेटिव रनटाइम पूछता है कि पहले से निर्मित कोड कितनी तेजी से चलता है। वर्कलोड-डोमेन सूट पूछता है कि स्ट्रिंग्स, संग्रह, आवंटन, I/O, समवर्तीता, और एक छोटा वास्तविक अनुप्रयोग कैसे व्यवहार करता है। परिणाम सभी पांच प्रश्नों—और उनके साक्ष्य स्थिति—को अलग रखते हैं।

बिल्ड स्टार्टअप · रैंक अयोग्य

4 टूलचेन, 21 प्रत्येक चलाता है

Kotoba 40.998 मिलीसेकंड · रस्ट 126.422 मिलीसेकंड · सी 146.324 मिलीसेकंड · जेवीएम 961.248 मिलीसेकंड माध्यिका।

21 घूर्णन प्रक्रिया-ठंडी नमूने · load1 30.79 → 39.79 · आवश्यक ≤ 1 · 2026-08-29 · Apple M4

रनटाइम · कवरेज पूर्ण

6 वर्कलोड × 5 तुलनाकार

अमु नेटिव को Rust, Clang / C11, Zig, Go c-shared, Swift के खिलाफ एक सामान्य नेटिव कॉल सीमा के माध्यम से परीक्षण किया जाता है।

30/30 तुलनाकार/कार्यभार जोड़े · सटीक उत्तर सत्यापित

रनटाइम गति · 19/30 योग्य

19 जोड़े 30 के

अमु नेटिव 30 तुलनाकार/कार्यभार जोड़ों में से कम से कम 5% से 19 जीतता है, हथियारों के अपने फैलाव से अलग। सीमित सबसे तेज दावा हर जोड़ी की आवश्यकता है, इसलिए यह अयोग्य रहता है — गिनती सूचनात्मक आधा है।

कम से कम 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 / अमु · WebAssembly	733.255 ms	825.418 ms	1123.04 ms	1123.847 ms	3380.63 ms	9242.463 ms	निर्माण विफल	निर्माण विफल
Kotoba / अमु · नेटिव 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
रस्ट / 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, अनुकूलन स्तर और रनटाइम अनुबंध लेन के अनुसार भिन्न होते हैं, इसलिए यह डेवलपर प्रतिक्रिया विलंबता के बारे में पूछता है, समान कार्य के बारे में नहीं। होस्ट-लोड गेट असफल रहा (लोड1 2.73–2.73, आवश्यक ≤ 1), इसलिए ये इस रन के अवलोकन हैं न कि पोर्टेबल आंकड़े। चूंकि लेन इंटरलीव्ड हैं, क्रम अलग से योग्य है।

कौन से क्रम शोर परीक्षण में जीवित रहते हैं

एक अनुपात रैंकिंग नहीं है। परफगेट किसी भी आदेश को अस्वीकार करता है जिसकी दूरी दो भुजाओं के अपने फैलाव के अंदर आती है, चाहे अनुपात कितना भी बड़ा दिखे, और बहुत कम नमूनों के साथ एक हाथ को अस्वीकार करता है या बहुत अधिक शोर। यह यहां अपनी डिफ़ॉल्ट नीति पर चलता है, बिना ढील के — एक इसको चलाने के लिए सीमा ढीली की गई तो यह एक मापन बेंचमार्क होगा अपने स्वयं के थ्रेशोल्ड। क्योंकि लेन एक होस्ट पर इंटरलीव्ड हैं, एक अंतर जो इस परीक्षण को पार करता है वह होस्ट के व्यस्त होने से बच जाता है।

प्रत्येक तुलनाकार के खिलाफ Kotoba CLI जारी किया गया, हर आकार पर जहां यह अभी भी मान्य मॉड्यूल जारी करता है
आकार	तुलना की गई	Kotoba तेज़?	अंतर बनाम संयुक्त फैलाव	अगर नहीं, तो क्यों नहीं
K=1	C / Clang · मूल होस्ट	हाँ, योग्य	17.1 मिलीसेकंड बनाम 1.0 मिलीसेकंड	—
K=1	JVM / javac · JVM क्लास	हाँ, योग्य	160.8 मिलीसेकंड बनाम 5.4 मिलीसेकंड	—
K=1	रस्ट / rustc · नेटिव होस्ट	हाँ, योग्य	44.2 ms बनाम 0.6 ms	—
K=1	Rust / rustc · WebAssembly	हाँ, योग्य	27.1 मिलीसेकंड बनाम 0.5 मिलीसेकंड	—
K=32	C / Clang · मूल होस्ट	नहीं	5.3 ms बनाम 1.0 ms	सुधार-थ्रेशोल्ड-से-नीचे
K=32	JVM / javac · JVM क्लास	हाँ, योग्य	161.9 मिलीसेकंड बनाम 1.2 मिलीसेकंड	—
K=32	रस्ट / 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	रस्ट / rustc · नेटिव होस्ट	नहीं	29.3 मिलीसेकंड बनाम 1.4 मिलीसेकंड	सुधार-थ्रेशोल्ड-से-नीचे
K=128	Rust / rustc · WebAssembly	नहीं	45.8 मिलीसेकंड बनाम 1.1 मिलीसेकंड	सुधार-थ्रेशोल्ड-से-नीचे

सुधार-थ्रेशोल्ड-से-नीचे का मतलब है कि Kotoba लेन उस आकार पर बिल्कुल भी तेज़ नहीं था। लाभ वास्तविक और ठंडे प्रारंभ पर योग्य है, और यह C के खिलाफ K=32 और रस्ट के खिलाफ K=128 पर समाप्त हो जाता है। वह क्रॉसओवर परिणाम है, इसलिए इसे दिखाया गया है बजाय संक्षेप में हटाए।

दो असफलताएँ जो एक जैसी नहीं हैं

इस रन में तीन Kotoba लेन काम करना बंद कर गए, और उन्हें एक के रूप में प्रकाशित करना पंक्ति गलत होती। एक दोष है। अन्य दो घोषित हैं सीमाओं को ठीक वैसे ही लागू करना जैसा निर्दिष्ट है, और उन्हें दोष के रूप में रिपोर्ट करना इसका मतलब कंपाइलर के बजाय सीमाओं को मापना होगा।

क्या रुका, और इसका क्या मतलब है
अवलोकन	पढ़ना
रिलीज़ किया गया kotoba CLI एक मॉड्यूल उत्सर्जित करता है जो 128 से अधिक फ़ंक्शंस पर कंपाइल नहीं होगा	एक दोष, और हार्नेस के अंदर सत्यापित करने का कारण। K=129 पर एक कॉल को फ़ंक्शन इंडेक्स 128 ले जाना होता है, जो पहली मान है जिसे दो LEB128 बाइट्स की आवश्यकता होती है, और उत्सर्जक एक लिखता है। बाइट्स कहते हैं कि यह कोई गायब एन्कोडर नहीं बल्कि एक अप्रयुक्त है: local.set 128 80 01 लिखा गया है, और कॉल 128 एक निर्देश बाद लिखा गया है 80। ट्रंकेट किए गए ऑपरेटरों की संख्या ठीक K माइनस 128 है। वर्तमान संकलक के पास यह नहीं है — अमु K=129 को सही ढंग से बनाता है, और सुधार इसके उत्सर्जक की डिफ़ॉल्ट शाखा पर इस रिलीज़ के टैग होने से पहले से है।
हर Kotoba लेन डिफ़ॉल्ट सेटिंग्स के साथ बनाए जाने पर K=512 पर ट्रैप करता है	त्रुटि नहीं। एक Kotoba मॉड्यूल एक घोषित कॉल-ईंधन बजट रखता है और संकलक डिफ़ॉल्ट 512 कॉल है, जिसे यह कार्यभार K=512 पर पार करता है जहाँ प्रवेश बिंदु 512 पत्तियों को कॉल करता है। हार्नेस स्पष्ट रूप से 1,048,576 इकाइयां घोषित करता है और रिकॉर्ड करता है कि उसने ऐसा किया। C, Rust और Java के पास बढ़ाने के लिए कोई समकक्ष सीमा नहीं है।
अमू मॉड्यूल को पूरी तरह से अस्वीकार कर देता है जब यह 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 अमु के माध्यम से — 7163 पंक्तियाँ Kotoba की, आर्टिफैक्ट निष्पादित और उत्तर जांचा गया। यह घोषित 1,024 सीमा से एक फ़ंक्शन कम है, और अगला आकार अस्वीकृत किया जाता है बजाय गलत निर्माण के।
क्या जारी किया गया कोड तेज़ है?	यहाँ दायरे से बाहर — यह निर्माण को मापता है, चलाने को नहीं। ऊपर नेटिव रनटाइम सूट वह प्रश्न पूछता है।

निचली रेखा: सबसे छोटे आकार पर जारी बाइनरी यहां हर तुलना से तेज़ है, एक अंतर के साथ जो शोर परीक्षण में बचता है, और इसका कठोर सही सीमा 128 फ़ंक्शंस पर है। उस सीमा के बिना कंपाइलर हर आकार पर लगभग एक क्रम के गुणा धीमा है मापा गया। दोनों तथ्य एक ही रन से आते हैं, और जो हार्नेस उन्हें पाया वह सार्वजनिक है, इसलिए रन से असहमति हो सकती है।

बिल्ड-स्केलिंग नमूने निरीक्षण करें इसे अपनी मशीन पर पुनः चलाएं दोष, इसके बाइट्स के साथ

प्रत्येक नेटिव कार्यभार वास्तव में कितना समय लेता है

नीचे ग्रिड दो भुजाओं के बीच मार्जिन रिपोर्ट करता है। वह संख्या है perfgate नियम चालू हैं, लेकिन केवल प्रतिशत यह नहीं बताता कि कार्यभार पाँच मिलीसेकंड या पाँच सौ में चलता है, और यह छुपाता है एक विवादित जोड़ी और एक अप्रासंगिक जोड़ी के बीच अंतर। ये पैनल हैं माध्य वे मार्जिन से गणना किए जाते हैं। अमु नेटिव रंगीन लेन है हर पैनल में — उन पैनलों सहित जहाँ यह पहला नहीं है। प्रत्येक पैनल है अपने सबसे धीमे आर्म पर मापा गया, क्योंकि एक पैनल का उत्तर देने वाला प्रश्न है कि कौन है उस कार्यभार में तेज़।

संकीर्ण अंकगणित

Clang / C11 6.41 ms
अमू नेटिव 6.53 ms1.02× यहाँ सबसे तेज़
स्विफ्ट 6.55 ms
रस्ट 6.58 ms
ज़िग 8.24 ms
Go c-shared 42.84 ms

व्यापक रजिस्टर दबाव

अमू नेटिव 5.80 msयहाँ सबसे तेज़
रस्ट 6.19 ms
Clang / C11 6.50 ms
ज़िग 6.97 ms
Go c-shared 41.07 ms
स्विफ्ट 44.08 ms

गहरा स्पिल दबाव

अमू नेटिव 9.23 msयहाँ सबसे तेज़
रस्ट 9.61 ms
ज़िग 9.71 ms
Clang / C11 10.23 ms
Go c-shared 51.86 ms
स्विफ्ट 124.27 ms

कॉल संरक्षण

रस्ट 4.77 ms
Clang / C11 4.82 ms
अमू नेटिव 4.85 ms1.02× यहाँ सबसे तेज़
स्विफ्ट 6.77 ms
ज़िग 8.44 ms
Go c-shared 32.49 ms

ब्रांच + कॉल नियंत्रण प्रवाह

Clang / C11 4.67 ms
रस्ट 4.90 ms
अमू नेटिव 4.98 ms1.07× यहाँ सबसे तेज़
स्विफ्ट 6.72 ms
ज़िग 8.95 ms
Go c-shared 33.84 ms

लूप कॉल बैक एज

Clang / C11 139.84 ms
अमू नेटिव 140.59 ms1.01× यहाँ सबसे तेज़
रस्ट 141.73 ms
Go c-shared 169.38 ms
स्विफ्ट 186.09 ms
ज़िग 207.01 ms

मध्य माप मिलीसेकंड में 5 होस्ट-योग्य रन के ऊपर; कम समय तेज़ है। हर आर्म ने स्वतंत्र रूप से जाँचा गया समान उत्तर लौटाया, और उम्मीदवार मध्य मान प्रत्येक कार्यभार के लिए एक मान है — सूट प्रत्येक इंजन जोड़ी को ABBA/BAAB क्रम में घुमाता है, इसलिए समान अमु आर्टिफैक्ट को प्रत्येक कार्यभार पर एक बार मापा जाता है और फिर प्रत्येक आर्म के खिलाफ क्रम से तुलना की जाती है। इस पृष्ठ के अन्य चार बेंचमार्क के विपरीत, इस एक का शांत-होस्ट गेट पास हुआ (योग्य-होस्ट-लोड), इसलिए ये इस होस्ट के लिए आंकड़े हैं न कि केवल अवलोकन। सीमित सबसे तेज दावा अभी भी सभी 30 जोड़ों की आवश्यकता है, जो नीचे ग्रिड के लिए है।

हर रनटाइम जोड़ी, जीत या हार

सीमित दावा सब या कुछ नहीं है, इसलिए एक भी अयोग्य जोड़ा इसे गलत बनाता है। केवल उस निर्णय को प्रकाशित करना यह छुपा देगा कि कौन से जोड़े विवादित हैं, इसलिए पूरा ग्रिड यहाँ है। एक सेल उस तुलना के मुकाबले अमु नेटिव के औसत सुधार को दर्शाता है उस कार्यभार पर; सकारात्मक का अर्थ है Amu तेज़ है, और एक चेक उन जोड़ों को चिह्नित करता है जो स्पष्ट परफगेट — कम से कम 5% और बाहुओं के अपने फैलाव से अलग।

Amu मूल बनाम प्रत्येक तुलनाकार, 2026-09-07, होस्ट-योग्य; ✓ = परफगेट पास करता है
वर्कलोड	रस्ट	Clang / C11	ज़िग	Go c-shared	स्विफ्ट
संकीर्ण अंकगणित	+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%

प्रत्येक सेल एक बार है जो एक केंद्र रेखा से बढ़ा है: इसके दाईं ओर अमु नेटिव तेज है, इसके बाईं ओर धीमा। दोनों दिशाओं को अलग-अलग मापा गया है — जीत +93% तक जाती हैं और हार केवल −7% तक, इसलिए एक साझा पैमाना हर विवादित जोड़ी को एक ही अदृश्य पट्टी में समतल कर देगा। संकेत भी रेखा के किनारे और हस्ताक्षरित संख्या द्वारा ले जाया जाता है, इसलिए इस ग्रिड को पढ़ने के लिए दो रंगों को अलग करने की आवश्यकता नहीं है।

19 में से 30 जोड़े योग्य (माध्यिका 5; हर रन में 19) · उम्मीदवार 42f092ea5b61 · Apple M4, 10 तार्किक CPU, 16 GiB

प्रकाशित रन के बाद अनुकूलन वितरण

ऊपर दिया गया तिथि वाला बेंचमार्क अपरिवर्तनीय रहता है। नए कार्यान्वयन स्लाइस अलग से सूचीबद्ध हैं जब तक कि समान-कलाकृति सूट पुनः नहीं चलता और अपनी योग्यता गेट पास नहीं करता।

ऐसे कार्यान्वित सतहें जो अभी नई गति दावे नहीं हैं
सतह	प्रदान किया गया	साक्ष्य सीमा
नेटिव वेक्टर / आवंटन	सीमित गैर-भागने वाले वेक्टर लिटरल x86-64 और AArch64 पर भागने से प्रमाणित और स्केलर-प्रतिस्थापित हैं।	211 बैकएंड परीक्षण / 2,442 दावे; बचने वाले वेक्टर जांचे गए होस्ट ABI को बनाए रखते हैं। अभी तक कोई नया रैंक्ड टाइमिंग नहीं।
स्ट्रिंग SIMD	POSIX जांचित समानता हैंडल और कैनोनिकल UTF-8 मान्यता के बाद स्पष्ट 16-बाइट NEON या SSE2 तुलना का उपयोग करती है।	संसाधित असेंबली और दोनों मूल ISA सेमांटिक वेक्टर सत्यापित। विंडोज़ अलग से पिन किया गया है; विलंबता रैंक लंबित है।
असिंक्रोनस I/O क्षमता	रूट-सीमित अंतिम पढ़ना/लिखना/सूची/मौजूदगी/हटाना JVM पर CompletableFuture और Node पर fs.promises का उपयोग करता है।	JVM और Node वास्तविक-फ़ाइल सिस्टम परीक्षण पास होते हैं। सार्वजनिक स्टैंडअलोन Wasm बेंचमार्क अभी भी कोई स्वीकृत होस्ट बाइंडिंग नहीं रखता, इसलिए इसका I/O सेल N/A रहता है।
संरचित समवर्तीता	एक सीमित 32-चाइल्ड फेल-फास्ट स्कोप जुड़ता है, भाई-बहनों को रद्द करता है, और canonical Kotoba स्थिति के रूप में चाइल्ड जीवनकाल पलायन को रोकता है।	996 समानता दावे .kotoba प्राधिकरण और CLJC लोड पथ में। यह संरचित जीवनकाल अर्थ है, OS-थ्रेड थ्रूपुट परिणाम नहीं।
Kotoba CLI	kotoba टेस्ट/बिल्ड नए कंपाइलर पिन का उपयोग करता है; kotoba कंपाइल सील्ड 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

एक छोटे स्रोत के लिए प्रक्रिया-ठंडी दीवार समय, मिलीसेकंड में; कम समय तेज़ है। Apple M4 पर 21 टूलचेन प्रति घुमावदार नमूने। इस रन पर होस्ट-लोड गेट असफल रहा, इसलिए ये एक मशीन के अवलोकन हैं, रैंकिंग नहीं।

सूत्र से आर्टिफैक्ट प्रक्रिया-ठंडी बिल्ड मापन
टूलचेन	आउटपुट	माध्यिका	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 · होमब्रू क्लैंग संस्करण 22.1.7 · javac 24.0.2. Kotoba, रस्ट, और C वास्म जारी करते हैं; javac एक क्लास फ़ाइल जारी करता है। विभिन्न लक्ष्य और कंपाइलर कार्य इसे एक स्टार्टअप अवलोकन बनाते हैं, सार्वभौमिक रैंकिंग नहीं। रिकॉर्ड किया गया होस्ट-लोड गेट विफल रहा, इसलिए तालिका एक योग्य गति रैंक नहीं है।

निर्भरता-मुक्त छोटे-प्रोजेक्ट डेवलपर-लूप माध्य; N/A का अर्थ है कोई अलग चरण मापा नहीं गया
टूलचेन / लक्ष्य	सुलझाएं	जांचें	साफ़ निर्माण	कोई बदलाव नहीं बिल्ड	प्रारंभ + निष्पादित करें	साफ बिल्ड + पहला परिणाम
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
गो · arm64 macOS नेटिव	43.553 ms	6979.823 ms	3499.277 ms	150.902 ms	247.051 ms	3755.431 ms
स्विफ्ट / 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 नेटिव AOT · arm64 macOS नेटिव AOT	2236.962 ms	लागू नहीं	11995.489 ms	2707.907 ms	375.7 ms	12391.54 ms

प्रत्येक उत्सर्जित आर्टिफैक्ट ने 42 को एक ताजा प्रक्रिया में उत्पन्न किया। लक्ष्य और रनटाइम अनुबंध भिन्न हैं; लागू नहीं कभी शून्य नहीं होता। होस्ट-लोड गेट विफल रहा, इसलिए ये पुनरुत्पादनीय अवलोकन हैं न कि एक क्रॉस-भाषा गति रैंकिंग।

छह डोमेन, साथ-साथ

प्रत्येक पैनल को अपनी सबसे धीमी लेन के अनुसार मापा जाता है, क्योंकि एक पैनल का प्रश्न उत्तर यह है कि उस डोमेन में कौन तेज़ है, न कि डोमेनों की तुलना एक-दूसरे से कैसे होती है अन्य। Kotoba की लेन हर पैनल में रंगीन होती है — जिसमें पैनल जहां यह अंतिम है। इसका स्टैंडअलोन वास्म आर्टिफैक्ट नोड के माध्यम से चलता है होस्ट और हर प्रोसेस-कोल्ड नमूने पर वह स्टार्टअप भुगतान करता है, जबकि Rust, C और Go देशी बाइनरी के रूप में चलाएं; जहाँ लक्ष्य के पास कोई परिवेशीय फ़ाइल सिस्टम या थ्रेड नहीं है अनुबंध बिल्कुल नहीं है, लेन अनुपस्थित है बजाय शून्य के।

स्ट्रिंग

C / Clang 1.463 ms
रस्ट 1.907 ms
जाएं 1.974 ms
JVM / जावा 27.819 ms
Kotoba / Wasm + टाइप्ड JS होस्ट 30.539 ms20.9× यहाँ सबसे तेज़
जावास्क्रिप्ट / नोड.जेएस 31.628 ms

संग्रह

C / Clang 1.357 ms
जाएं 1.852 ms
रस्ट 1.92 ms
Kotoba / Wasm + टाइप्ड JS होस्ट 29.98 ms22.1× यहाँ सबसे तेज़
JVM / जावा 31.42 ms
जावास्क्रिप्ट / नोड.जेएस 31.818 ms

आवंटन

C / Clang 1.353 ms
रस्ट 1.943 ms
जाएं 1.962 ms
JVM / जावा 26.447 ms
Kotoba / Wasm + टाइप्ड JS होस्ट 29.567 ms21.9× यहाँ सबसे तेज़
जावास्क्रिप्ट / नोड.जेएस 31.055 ms

इनपुट/आउटपुट

C / Clang 2.539 ms
रस्ट 2.686 ms
जाएं 6.577 ms
JVM / जावा 38.685 ms
जावास्क्रिप्ट / नोड.जेएस 94.124 ms
Kotoba / Wasm + टाइप्ड JS होस्ट N/A — इस लक्ष्य के अनुबंध में नहीं है —

सामयिकता

C / Clang 2.916 ms
रस्ट 3.328 ms
जाएं 3.377 ms
JVM / जावा 34.828 ms
जावास्क्रिप्ट / नोड.जेएस 55.105 ms
Kotoba / Wasm + टाइप्ड JS होस्ट N/A — इस लक्ष्य के अनुबंध में नहीं है —

वास्तविक अनुप्रयोग

C / Clang 1.294 ms
जाएं 1.964 ms
रस्ट 2.047 ms
JVM / जावा 26.411 ms
जावास्क्रिप्ट / नोड.जेएस 29.534 ms
Kotoba / Wasm + टाइप्ड JS होस्ट 29.652 ms22.9× यहाँ सबसे तेज़

प्रक्रिया-ठंडा माध्य मिलीसेकंड में; कम समय तेज़। होस्ट-लोड गेट इस रन में विफल, इसलिए ये पैनल अवलोकन हैं न कि रैंकिंग, और नीचे दिया गया औसत लेन फिर एक अलग कहानी बताता है।

प्रक्रिया-ठंडा वर्कलोड-डोमेन माध्य; N/A का मतलब है कि लक्ष्य अनुबंध वह क्षमता प्रदान नहीं करता
रनटाइम पथ	स्ट्रिंग	संग्रह	आवंटन	फ़ाइल I/O	सामयिकता	वास्तविक ऐप
Kotoba / Wasm + टाइप्ड JS होस्ट	30.539 ms	29.98 ms	29.567 ms	लागू नहीं	लागू नहीं	29.652 ms
रस्ट	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
जाएं	1.974 ms	1.852 ms	1.962 ms	6.577 ms	3.377 ms	1.964 ms
JVM / जावा	27.819 ms	31.42 ms	26.447 ms	38.685 ms	34.828 ms	26.411 ms
जावास्क्रिप्ट / नोड.जेएस	31.628 ms	31.818 ms	31.055 ms	94.124 ms	55.105 ms	29.534 ms

हर नमूने ने सटीक संदर्भ चेकसम लौटाया। Kotoba अपने जारी किए गए Wasm और घोषित टाइप्ड ABI का उपयोग करता है; इसका स्टैंडअलोन लक्ष्य कोई परिवेश फ़ाइल सिस्टम या थ्रेड अनुबंध नहीं रखता, इसलिए उन कोशिकाओं को N/A माना जाता है। रिकॉर्ड किया गया होस्ट-लोड गेट विफल रहा, इसलिए माध्यक अवलोकन हैं, रैंकिंग नहीं।

प्रति आधार कार्यभार में अमोर्टाइज्ड इन-प्रोसेस बैच माध्य; N/A समान क्षमता सीमा बनाए रखता है
रनटाइम पथ	स्ट्रिंग	संग्रह	आवंटन	फ़ाइल I/O	सामयिकता	वास्तविक ऐप
Kotoba / Wasm + टाइप्ड JS होस्ट	0.351 ms	0.039 ms	0.066 ms	लागू नहीं	लागू नहीं	0.048 ms
रस्ट	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
जाएं	0.023 ms	0.002 ms	0.004 ms	5.071 ms	1.582 ms	0.002 ms
JVM / जावा	0.433 ms	0.051 ms	0.064 ms	17.175 ms	5.589 ms	0.043 ms
जावास्क्रिप्ट / नोड.जेएस	0.336 ms	0.033 ms	0.067 ms	68.507 ms	7.771 ms	0.032 ms

प्रत्येक बड़े इन-प्रोसेस बैच को उसके घोषित कार्यभार गुणक से विभाजित किया जाता है। यह स्टार्टअप को अमोर्टाइज़ करता है लेकिन प्रक्रिया, VM, या Wasm इंस्टांटिएशन लागत को पूरी तरह से नहीं हटाता, इसलिए इसे पूरी तरह गर्म स्थिर-स्थिति परिणाम नहीं कहा जाता। Kotoba के शुद्ध इंक/डिक मैप चेन बिना मध्यवर्ती वेक्टर के reduce में विलयित हैं; उस प्रमाणित उपसमूह के बाहर कॉलबैक उत्साही सामग्रीकरण बनाए रखते हैं।

प्रत्येक सार्वजनिक बेंचमार्क क्या करता है—और क्या नहीं स्थापित करता
प्रश्न	तुलनात्मक कार्यान्वयन	वर्तमान निष्कर्ष
छोटा Wasm संकलन + निष्पादन	Kotoba, Rust, C, और JVM टूलचेन	ऊपर चार प्रक्रिया-ठंडे माध्य प्रकाशित; केवल Kotoba/Rust/C Wasm लक्ष्य साझा करते हैं, और कोई सामान्य बिल्ड-गति रैंक दावा नहीं किया गया
छोटे प्रोजेक्ट डेवलपर लूप	Kotoba, Rust, C, Zig, TinyGo, Go, Swift, JVM, AssemblyScript, .NET IL, और .NET नेटिव AOT	प्रत्येक उपलब्ध चरण के लिए सात नमूने प्रकाशित किए जाते हैं; लक्ष्य भिन्नताएं और असफल होस्ट-लोड गेट सार्वभौमिक रैंकिंग को रोकते हैं
नेटिव स्थिर-स्थिति निष्पादन	अमू नेटिव बनाम रस्ट, क्लैंग / C11, ज़िग, गो c-शेयरड, स्विफ्ट	सभी 30 सेमांटिक तुलना कोशिकाएं पूर्ण हैं; गति रैंकिंग रोक दी गई क्योंकि शांत-होस्ट गेट विफल रहा
स्ट्रिंग्स, संग्रह, आवंटन, I/O, समवर्तीता, और वास्तविक ऐप	Kotoba, रस्ट, C, गो, JVM, और जावास्क्रिप्ट रनटाइम पथ	सटीक चेकसम और प्रोसेस-कोल्ड के साथ-साथ औसत नमूने प्रकाशित किए गए हैं; स्टैंडअलोन Kotoba I/O और थ्रेड्स लागू नहीं हैं, जबकि इसका शुद्ध अनुरोध-स्वीकृति अनुप्रयोग मापा गया है; असफल लोड गेट रैंकिंग रोकता है

नेटिव सूट क्या कवर करता है

प्रत्येक कार्यान्वयन स्वतंत्र रूप से जांचे गए ज्ञात उत्तर लौटाता है। सूट 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
स्केलिंग बनाएं	कोटोबा-लैंग/बिल्डबेंच	buildbench	प्रकाशित JSON · bench/public-build-scaling/latest.json
कार्यभार डोमेन	kotoba-lang/kotoba-lang	scripts/benchmark-public-domains.mjs · bench/public-domain-comparison/README.md · बेंच/सार्वजनिक-डोमेन-तुलना/प्रोब्स	प्रकाशित JSON · bench/public-domain-comparison/latest.json

इस पृष्ठ पर हर आदेश को जो गेट से गुजारा जाता है वह है kotoba-lang/perfgate, अपने स्वयं के बिना ढीले डिफ़ॉल्ट नीति पर चलाएं। एक सीमा ढीली की गई ताकि एक रन थ्रू एक बेंचमार्क होगा जो अपनी ही सीमाओं को मापेगा।

निचली रेखा: आर्टिफैक्ट, सटीक परिणाम और नमूने सभी पांच बेंचमार्क में वास्तविक हैं। उनमें से तीन — संकलक स्टार्टअप, डेवलपर लूप और कार्यभार डोमेन — अपने शांत-होस्ट गेट में असफल रहे, इसलिए वे कुछ भी रैंक नहीं करते और अवलोकन के रूप में प्रकाशित हैं। नेटिव रनटाइम सूट ने अपना गेट पास किया और अपने 30 जोड़ों में से 19 जीतता है, हर जोड़े के दावे से कम जो इसे चाहिए था। बिल्ड स्केलिंग अपने ठंडे-शुरुआत क्रम को होस्ट पर हर तुलना के खिलाफ योग्य करता है और उसी रन में एक शुद्धता छत पाता है। इस पृष्ठ पर कहीं भी कोई सार्वभौमिक गति रैंक दावा नहीं किया गया है, और इनमें से कोई भी रन इसे लाइसेंस नहीं करता।

संकलन नमूनों का निरीक्षण करें रनटाइम साक्ष्य का निरीक्षण करें डेवलपर-लूप नमूने निरीक्षण करें कार्यभार-डोमेन नमूनों का निरीक्षण करें रनटाइम विधि की समीक्षा करें कंपाइल हार्नेस पुनः चलाएं

दावे उनके सीमाओं के साथ संलग्न

ये दावे उत्पन्न होते हैं lang/safety-claims.edn. प्रत्येक अपनी विश्वसनीय कंप्यूटिंग बेस और अवशिष्ट जोखिम को दृश्य रखता है, क्योंकि एक सुरक्षा नारा बिना सीमा के केवल विपणन है।

T1-मेमोरी

स्वीकृत घटक रनटाइम/मूल स्मृति को संबोधित नहीं कर सकते और घटक स्मृति संचालन सीमित या ट्रैप होते हैं।

विश्वसनीय कंप्यूटिंग बेस

सीमित रीडर · फ्रंटेंड प्रवेश · आर्टिफैक्ट सत्यापनकर्ता · Wasm/नेटिव रनटाइम

अवशिष्ट जोखिम

रनटाइम-इंजन कमजोरियां TCB में बनी रहती हैं
नेटिव लोडर्स को दूसरी OS पृथक्करण सीमा की आवश्यकता होती है

T2-प्रभाव

हर ट्रांजिटिव कंपोनेंट प्रभाव को उत्सर्जन से पहले घोषित और स्वीकार किया जाता है, जिसमें Kotoba-लिखित प्रदाताओं द्वारा उपयोग किए गए प्रभाव शामिल हैं।

विश्वसनीय कंप्यूटिंग बेस

प्रभाव अनुमान · क्षमता सूची · फ्रंटेंड कॉल ग्राफ

अवशिष्ट जोखिम

kotoba और कंपाइलर व्याकरण/प्रभाव समानता को लगातार तुलना किया जाना चाहिए

T3-कनफाइनमेंट

एक अनग्रांटेड क्षमता अनुपस्थित या अनबाउंड होती है और प्रदाता या नेटिव हैंडलर तक नहीं पहुँच सकती।

विश्वसनीय कंप्यूटिंग बेस

नीति छेदन · कंपाइलर आयात उत्सर्जन · निविदा आयात बाइंडिंग · होस्ट गार्ड

अवशिष्ट जोखिम

प्रदाता और नेटिव कार्यान्वयन को स्वतंत्र रूप से संसाधन दायरा मान्य करना चाहिए
उत्पादन प्रभावी अनुदान वाइल्डकार्ड स्कोप को प्रतिबंधित करना चाहिए

T4-नियतत्व

वही स्वीकृत स्रोत, लक्ष्य, नीति और लॉक वही प्रेक्षित शुद्ध परिणाम और कलाकृति बाइट्स उत्पन्न करते हैं।

विश्वसनीय कंप्यूटिंग बेस

कैनोनिकल रीडर · निर्धारक लोअरिंग · पिन्ड टूलचेन

अवशिष्ट जोखिम

होस्ट प्रभाव केवल तभी निर्धारक होते हैं जब उनकी क्षमता अनुबंध ऐसा कहती है

T5-संसाधन-सीमाएं

स्रोत, प्रवेश, निष्पादन, मेमोरी और आउटपुट स्पष्ट सीमित सीमाओं का उपयोग करते हैं।

विश्वसनीय कंप्यूटिंग बेस

प्रवेश सीमाएँ · ईंधन मीटर · रनटाइम कोटा · पर्यवेक्षक टाइमआउट

अवशिष्ट जोखिम

प्लेटफ़ॉर्म पर्यवेक्षकों के पास अभी समान उत्पादन पृथक्करण साक्ष्य नहीं है

T6-आपूर्ति-श्रृंखला

रिलीज़ प्रवेश कलाकृति पहचान, विश्वसनीय हस्ताक्षरकर्ता, वैधता और पुनरुत्पादक साक्ष्य को बांधता है।

विश्वसनीय कंप्यूटिंग बेस

हस्ताक्षर सत्यापनकर्ता · विश्वसनीय हस्ताक्षरकर्ता विन्यास · घड़ी · निरस्तीकरण सेट

अवशिष्ट जोखिम

कुंजी संरक्षण और बाहरी निरस्तीकरण वितरण परिचालन TCB बने रहते हैं

T7-BACKEND-PARITY

एक साझा पोर्टेबल घटक के लिए योग्य बैकएंड के बीच समान स्वीकृति, परिणाम और प्रभाव ट्रेस होता है।

विश्वसनीय कंप्यूटिंग बेस

साझा अनुपालन मैनिफेस्ट · बैकएंड एडेप्टर · तुलना रनर

अवशिष्ट जोखिम

केवल-कंपाइलर सुविधाएँ पोर्टेबल नहीं हैं और पोर्टेबल प्रोफाइल द्वारा अस्वीकार की जानी चाहिए

T8-होस्ट-संसाधन-स्कोप

एक घटक आयात केवल एक ठोस पोस्ट-इंटरसेक्शन संसाधन स्कोप के साथ अपने प्रदाता या मूल हैंडलर तक पहुंचता है और एक रसीद जारी करता है।

विश्वसनीय कंप्यूटिंग बेस

क्षमता छेदन · होस्ट गार्ड · प्रदाता हैंडलर · रसीद सिंक

अवशिष्ट जोखिम

प्रदाता-विशिष्ट पथ, पुनर्निर्देशन, सिमलिंक और टेनेंट जांच के लिए 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))

यह प्रोग्राम कोई होस्ट आयात नहीं मांगता; जारी किया गया मॉड्यूल कोई आयात नहीं रखता।

एआई एजेंट: निष्पादन त्वरित प्रारंभ शुरुआत गाइड खोलें CLI संदर्भ पढ़ें

सीखें, कोशिश करें, फिर गहराई से जाएं

पहले प्रोग्राम से भाषा अनुबंध, लाइब्रेरी, साक्ष्य, और तैनाती सतहों तक एक जुड़ा हुआ पथ।

सीखें

इरादे के अनुसार दस्तावेज़

स्थापना से शुरू करें, स्वीकृत भाषा सीखें, या मानक अर्थ और अनुपालन डेटा निरीक्षण करें।

खुला दस्तावेज़ मानचित्र

कोड पढ़ें

एक स्रोत, एक उत्तर

नीचे दिया गया उदाहरण ठीक वही स्रोत है जो ब्राउज़र डेमो में संकलित है—कोई जावास्क्रिप्ट पुनः कार्यान्वयन नहीं।

नमूना पढ़ें

चलाएँ

इस पृष्ठ में निष्पादित करें

एक समान-उत्पत्ति, डाइजेस्ट-बाउंड WebAssembly आर्टिफैक्ट लोड करें और इसके निर्यातित Kotoba मुख्य फ़ंक्शन को कॉल करें।

ओपन प्ले

निर्माण

लाइब्रेरी और अनुबंध

सीमित कोर नाम, मौलिक पुस्तकालय, पैकेज नियम, और उनकी वर्तमान परिपक्वता सीमा ब्राउज़ करें।

लाइब्रेरी ब्राउज़ करें

एक छोटा Kotoba प्रोग्राम, वास्तविक में चल रहा

अमू इस शुद्ध Kotoba स्रोत को wasm32-ब्राउज़र प्रोफ़ाइल में संकलित करता है। जांचे गए आर्टिफैक्ट में कोई आयात नहीं है और यह 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/व्याकरण → kotoba.grammar.highlight/tokenize → निर्माण-समय HTML। संपादक दायरा अनुबंध: source.kotoba. ब्राउज़र हाइलाइटर निर्भरता: कोई नहीं। निर्भरता निरीक्षण करें

स्थानीय रूप से संकलित करें: kotoba compile double-21.kotoba --target wasm32-browser --output double-21.wasm

PLAY · WEBASSEMBLY

सत्यापित आर्टिफैक्ट चलाएं

ब्राउज़र 344 बाइट्स प्राप्त करता है, SHA-256 सत्यापित करता है, हर आयात को अस्वीकार करता है, मॉड्यूल को इंस्टैंसिएट करता है, और main() को कॉल करता है।

अपेक्षित परिणाम: 42

तैयार। अभी तक कोई कोड नहीं चला है।

यह एक पूर्व-संकलित, अपरिवर्तनीय उदाहरण निष्पादित करता है। ब्राउज़र में मनमाना स्रोत संपादित करना अभी तक एक भेजा गया कंपाइलर सतह नहीं है।

इंटरैक्टिव डेमो: solar-helix (अतिथि-संचालित WebGPU रेंडर) · kami-survivors (एक .kotoba खेल) · gpu-clear (WebGPU स्मोक). wasm-webcomponent GitHub पेजेस सतह पर होस्ट किया गया; उपलब्धता प्रति-ब्राउज़र WebGPU/WebAssembly समर्थन पर निर्भर है।

पैकेज सीमा छुपाए बिना पुस्तकालय

Kotoba पुस्तकालय सामग्री-संकेतित ग्राफ़ हैं। नाम और GitHub रिपॉजिटरी लोगों को उन्हें खोजने में मदद करते हैं; परिभाषा और हस्ताक्षरित रिलीज़ CIDs बताते हैं कि वे वास्तव में क्या हैं।

सीमित कोर

उत्पन्न प्रतीक संदर्भ

वर्तमान सीमित मानक-लाइब्रेरी अनुबंध द्वारा स्वीकृत नाम खोजें।

कोर प्रतीकों को ब्राउज़ करें

मूलभूत

डेटा, प्रभाव, I/O, उपकरण

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 कोटोबेस — संग्रह परिवार · 35 OS और कर्नेल · 41 ड्राइवर्स और हार्डवेयर · 18 सिमुलेशन और मॉडलिंग · 31 कंपाइलर और IR · 45 रनटाइम और WebAssembly · 227 क्रिप्टोग्राफी · 45 पहचान और प्राधिकरण · 127 नेटवर्किंग और प्रोटोकॉल · 58 स्टोरेज और प्रारूप · 73 डेटाबेस और क्वेरी · 62 सामग्री पता लगाना · 49 ब्लॉकचेन और वॉलेट · 17 ग्राफिक्स, 3D & GPU · 118 ऑडियो और वीडियो · 27 यूआई और डिज़ाइन सिस्टम · 40 एआई, LLM और एजेंट · 67 EDA, CAD और विनिर्माण · 29 रोबोटिक्स और वाहन · 29 वित्त और भुगतान · 36 कानूनी और अनुपालन · 31 विज्ञान और स्वास्थ्य · 32 भू-स्थानिक · 11 डेवलपर टूलिंग · 26 दस्तावेज़, पाठ और i18n · 25

सभी 2,215 रिपॉजिटरी ब्राउज़ और फ़िल्टर करें

एक भंडार प्रकाशित पैकेज नहीं है। ठीक 1 पुस्तकालय सामग्री-संबोधित रजिस्ट्री के माध्यम से प्रकाशित होता है; इस सूची का बाकी हिस्सा खोज है। भंडार परिपक्वता लेबल 1.0 API स्थिरता, व्यापक अपनाने, या उत्पादन SLOs का संकेत नहीं देते, और 255 भंडार किसी डोमेन नियम से मेल नहीं खाते और बिना टैग के दिखाए जाते हैं बजाय निकटतम लेबल दिए जाने के।

जांच किए गए संदर्भ को खोजें

कमांड, मानक-लाइब्रेरी नाम, निदान, और रिलीज़ स्थिति खोजें। सूचकांक मशीन प्राधिकरणों से उत्पन्न होता है और इस पृष्ठ में रहता है।

Kotoba दस्तावेज़ खोजें

कोशिश करें: संकलित करें, विकल्प-कुछ, दस्तावेज़/लिंक-गायब

रिलीज़

रिलीज़ बाइंडिंग

खुला संदर्भ

cli

`kotoba id`

पासकी द्वारा नियंत्रित एक चेन-तटस्थ Kotoba प्रिंसिपल नामांकन योजना बनाएं। स्मार्ट खाते स्पष्ट CAIP-10 लिंक हैं; कोई चेन या प्रदाता पहचान मूल नहीं है।

खुला संदर्भ

cli

`kotoba run`

Kotoba प्रवेश बिंदु को कंपाइल और चलाएं।

खुला संदर्भ

cli

`kotoba compile`

Kotoba-परिवार स्रोत को लक्ष्य कलाकृति में संकलित करें। वेब .kotoba जांच किए गए KIR और प्रतिबंधित kotoba-script बैकएंड का उपयोग करता है; .cljs ClojureScript रहता है।

खुला संदर्भ

cli

`kotoba check`

Kotoba स्रोत, अनुबंध, या पैकेज मेटाडेटा को बिना चलाए मान्य करें। कंपाइलर एडाप्टर: फ्रंटेंड एडमिट + --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`

पैकेज वांछित-स्थिति को स्थानीय रसीद या मुराकुमो फ्लीट रेसाइड लक्ष्य पर योजना बनाएं और लागू करें।

खुला संदर्भ

cli

`kotoba library`

मौजूदा Kotoba कोडबेस और IPNS प्रकाशन पथ के माध्यम से एक सामग्री-संकेतित पुस्तकालय नामस्थान का निरीक्षण और प्रकाशन करें।

खुला संदर्भ

cli

`kotoba hinshitsu`

सॉफ्टवेयर गुणवत्ता जांच (साक्ष्य, गेट्स, कवरेज, दृश्य प्रतिगमन) डेटा के रूप में चलाएं।

खुला संदर्भ

stdlib