;; 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 पत्ते नाहीत.

सुरक्षित + जलद · AI-निर्मित सॉफ्टवेअर साठी तयार

सुरक्षित कोड. मशीन गतीसाठी तयार केलेले.

Kotoba हा सुरक्षित, अतिशय वेगवान AI-निर्मित सॉफ्टवेअर साठी डिझाइन केलेली 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 क्रमवारी उत्तीर्ण परफगेट त्याच्या अनरिलॅक्स्ड डीफॉल्ट धोरणावर — किमान 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 बॅकिंग राखतात. Arrow प्रोजेक्शन अधिकृत Kotobase तलाव मार्गाद्वारे अनकंप्रेस्ड बफर्स स्तंभीय ठेवू शकते. नेटवर्क प्रवेश, डिकंप्रेशन, GPU अपलोड, आणि अपरिवर्तनीय कायमस्वरूपी अद्यतने नावांकित कॉपी सीमांमध्ये राहतात.

अंमलात आणलेले अंशतः

बाणाच्या आकाराचा डेटा. स्पष्ट CPU SIMD आणि डिव्हाइस-नेटिव्ह GPU कर्नल्स.

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

मूलभूत

AI प्रथम. एजंट-सुरक्षित डीफॉल्टने.

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 म्हणून मंजूर-मार्गे-विस्तारलेले आहेत, आणि सेल पळून जाण्याच्या क्षणी नाकारले जातात. ref / dosync / volatile! / binding / var / alter-var-root / set! यांना कोणतीही क्षमता मॉडेल ठरवलेली नाही आणि ते नाकारलेले फेल-क्लोज्ड राहतात.
`agent, future, locking, pmap, send, send-off`	घटक वेळापत्रक आणि संसाधने तेंडर-नियंत्रित आणि मर्यादित राहणे आवश्यक आहे. व्याख्या CID किंवा प्रतिनिधीत्व अनुदान CPU किंवा वेळापत्रक मोजत नाही; इंधन प्रति-घटना आहे आणि पर्यावरणीय थ्रेड्स त्यातून बाहेर पडतील. एक संरचित-उत्पत्ती क्षमता उप-बजेटेड इंधनासह डिझाइन करता येते पण अजून ठरलेले नाही; अजून कोणताही विस्तार मार्ग नाही.
`defmacro`	सुरक्षित घटक पृष्ठभाग अंमलबजावणीपूर्वी स्थिरपणे तपासण्यायोग्य असावा. अनमुक्त: विस्तार संकलकाच्या आत कोड चालवतो (बिल्ड वेळ), आणि परिभाषा CID हॅशेस पोस्ट-डेसुगर टाइप केलेले KIR, त्यामुळे अमर्याद मॅक्रोज लवकर चालतात आणि स्रोत ओळख पुनरावलोकन करण्यायोग्य नाही. defdesugar (मर्यादित शुद्ध डेसुगर) मान्य पर्याय राहतो.
`catch, throw, try`	परिस्थिती throw/try/catch हे नोंद न ठेवलेले स्थानिक नसलेले नियंत्रण प्रवाह आहे: ते स्कोप सोडते ज्याचा अनुमानित प्रभाव रांगेत उल्लेख नाही आणि अनवाइंड जबाबदाऱ्या टाळते (डेटास्पेस फॅसेट रिट्रॅक्शनमध्ये अजून तपासलेले अनवाइंड नाही). प्रतिबंध परिस्थितीवर आहे. 2026-09-02 पासून टाइप केलेल्या abort क्षमतेने elaboration द्वारे हेड्सला मान्यता दिली: प्रभाव अनुमानित रांगेत :abort म्हणून दिसतो आणि फंक्शन [:result T E] मध्ये कमी होते, त्यामुळे elaboration नंतर परिस्थिती अस्तित्वात राहत नाही. Slice 2 (2026-09-02) ने :abort कॉल्समध्ये प्रसारित केले आणि aborting operand किंवा चाचणी A-नॉर्मलाइज्ड केली; दोन्ही invariant विस्तृत करत नाहीत, कारण प्रसारित abort कॉलरच्या रांगेवर आहे आणि A-नॉर्मलाइज्ड एक वेगळ्या स्थितीत समान elaboration आहे. जिथे अनवाइंड पूर्वशर्ती महत्त्वाची असते, abort नाकारलेले राहते -- CALL साठी आता तसेच throw साठी.

हे lang/surface-status.edn मधील नावांकित सुरक्षा बंधने आहेत, रोडमॅपमधून हरवलेली वैशिष्ट्ये नाहीत.

03 पुरावा

पुरावा, सीमा जोडलेली

Kotoba अंमलबजावणी पुरावा बाजारातील आकर्षणापासून वेगळा करतो आणि प्रत्येक सुरक्षा दाव्याजवळ उरलेला धोका ठेवतो.

33 कोर

आतील उत्पादन डॉगफूडिंग

विस्तृत Kotoba स्टॅक अंतर्गत 33 अनुमान कोर चालवतो. हे सिद्ध करते की संघ स्वतःचा स्टॅक चालवतो; हा ग्राहक आकर्षण, पैसे दिलेले स्वीकार किंवा महसूल नाही.

8 दावे

सीमा मशीन-वाचनीय आहेत

सुरक्षा दावे त्यांच्या विश्वासार्ह संगणकीय आधार, नकारात्मक पुरावे, आणि उरलेला धोका यांचा उल्लेख करतात, 'अहॅक करण्याजोगे नाही' अशा घोषवाक्यात न विघटित होतात.

डीफॉल्टने नकार

कोणतीही अनुदान नाही, कोणताही होस्ट परिणाम नाही

रिक्त धोरण कोणतीही फाइलसिस्टम, नेटवर्क, प्रक्रिया, घड्याळ, मॉडेल, किंवा गुप्त प्राधिकरण देत नाही. प्रदात्यांनी ठोस संसाधन क्षेत्र देखील पडताळले पाहिजे.

आतील उत्पादन वापर फक्त डॉगफूडिंग पुरावा आहे. याचा अर्थ बाह्य ग्राहक, पैसे दिलेले पायलट, किंवा महसूल नाही.

पाच बेंचमार्क. पाच वेगवेगळे प्रश्न.

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

बिल्ड स्टार्टअप · रँक अर्हताप्राप्त नाही

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

Kotoba 40.998 ms · रस्ट 126.422 ms · C 146.324 ms · JVM 961.248 ms मध्यम.

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 नमुने प्रति मोजलेले टप्पे · लोड1 20.84 → 24.49 · आवश्यक ≤ 1

बिल्ड स्केलिंग · छत सापडले

8 स्रोत आकार

त्याच प्रोग्रामचे एक फंक्शन ते 2048, प्रत्येक टूलचेनने होस्टवर तयार केले आणि नंतर चालवले. जारी केलेल्या बायनरीचा येथे सर्वात कमी थंड-प्रारंभ खर्च आणि अचूकता आहे 128 फंक्शन्सच्या वर छत.

घड्याळ थांबल्यानंतर तपासलेल्या कलाकृती · load1 2.73 → 2.73 · आवश्यक ≤ 1 · 2026-08-31

कामाचा भार डोमेन · रँक अर्हताप्राप्त नाही

6 डोमेन × 6 रनटाइम मार्ग

स्ट्रिंग्ज, संग्रह, वाटप, फाइल I/O, चार-कर्मचारी समवर्तीता, आणि विनंती-प्रवेश धोरण अनुप्रयोग कर्नल यांची अचूकता तपासली जाते.

7 नमुने दोन्ही प्रक्रिया-थंड आणि अमोर्टाइज्ड मार्गांमध्ये · लोड1 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

judahnoMac-mini.local (Apple M4) वर मोजलेले 2026-08-31. K म्हणजे तयार केलेल्या फंक्शन्सची संख्या; Kotoba स्रोत 9 ते 14338 ओळी चालतो. लक्ष्ये, ABI, ऑप्टिमायझेशन स्तर आणि रनटाइम करार वेगवेगळ्या लेनमध्ये असतात, त्यामुळे हे विकसक अभिप्राय विलंबाबद्दल विचारते, समतुल्य कामाबद्दल नाही. होस्ट-लोड गेट अयशस्वी (लोड1 2.73–2.73, आवश्यक ≤ 1), त्यामुळे हे या धावणीचे निरीक्षण आहेत, पोर्टेबल आकडे नाहीत. कारण लेन्स इंटरलीव्हड आहेत, क्रमवारी स्वतंत्रपणे पात्र ठरवली जाते.

कोणते क्रम आवाज चाचणी टिकवतात

अनुपात म्हणजे क्रमवारी नाही. परफगेट कोणत्याही ऑर्डरिंगला नाकारते ज्याचा अंतर दोन हातांच्या स्वतःच्या पसरलेल्या भागात येतो, अनुपात कितीही मोठा दिसला तरी, आणि खूप कमी नमुन्यांसह हात नाकारतो किंवा जास्त आवाज. हे येथे त्याच्या स्वतःच्या डीफॉल्ट धोरणावर चालते, आरामशीर नाही — एक या चालू होण्यासाठी सैल केलेली मर्यादा म्हणजे मोजमाप करणारा बेंचमार्क त्याचे स्वतःचे मर्यादा. कारण लेन्स एका होस्टवर इंटरलीव्ह केलेले आहेत, एक अंतर हा चाचणी पार करणारा होस्ट व्यस्त असतानाही टिकतो.

प्रत्येक तुलनात्मकासाठी Kotoba CLI प्रकाशित केले, प्रत्येक आकारावर जिथे ते वैध मॉड्यूल अजूनही प्रकाशित करते
आकार	तुलना केली	Kotoba जलद?	गॅप विरुद्ध एकत्रित प्रसार	का नाही, जर नाही
K=1	C / Clang · स्थानिक होस्ट	होय, पात्र	17.1 ms विरुद्ध 1.0 ms	—
K=1	JVM / javac · JVM वर्ग	होय, पात्र	160.8 ms विरुद्ध 5.4 ms	—
K=1	रस्ट / rustc · स्थानिक होस्ट	होय, पात्र	44.2 ms विरुद्ध 0.6 ms	—
K=1	Rust / rustc · WebAssembly	होय, पात्र	27.1 ms विरुद्ध 0.5 ms	—
K=32	C / Clang · स्थानिक होस्ट	नाही	5.3 ms विरुद्ध 1.0 ms	सुधारणा-थ्रेशोल्डखाली
K=32	JVM / javac · JVM वर्ग	होय, पात्र	161.9 ms विरुद्ध 1.2 ms	—
K=32	रस्ट / rustc · स्थानिक होस्ट	होय, पात्र	26.7 मिलीसेकंद विरुद्ध 0.7 मिलीसेकंद	—
K=32	Rust / rustc · WebAssembly	होय, पात्र	9.8 ms विरुद्ध 0.6 ms	—
K=128	C / Clang · स्थानिक होस्ट	नाही	75.8 मिलीसेकंद विरुद्ध 1.2 मिलीसेकंद	सुधारणा-थ्रेशोल्डखाली
K=128	JVM / javac · JVM वर्ग	होय, पात्र	126.2 ms विरुद्ध 2.2 ms	—
K=128	रस्ट / rustc · स्थानिक होस्ट	नाही	29.3 मिलीसेकंद विरुद्ध 1.4 मिलीसेकंद	सुधारणा-थ्रेशोल्डखाली
K=128	Rust / rustc · WebAssembly	नाही	45.8 ms विरुद्ध 1.1 ms	सुधारणा-थ्रेशोल्डखाली

improvement-below-threshold म्हणजे Kotoba मार्ग त्या आकारावर कधीही जलद नव्हता. फायदा खरा आहे आणि थंड सुरुवातीला पात्र आहे, आणि C विरुद्ध K=32 आणि रस्ट विरुद्ध K=128 वर तो गेला आहे. तो क्रॉसओव्हर निकाल आहे, त्यामुळे तो दाखविला जातो, संक्षेपित केला जात नाही.

दोन अपयश जे एकसारखे नाहीत

या धावणीत तीन Kotoba लेन काम करणे थांबवले, आणि त्यांना एकत्र प्रकाशित करणे ओळ चुकीची असती. एक दोष आहे. इतर दोन घोषित आहेत मर्यादा अचूकपणे लागू करणे आणि त्या दोष म्हणून नोंदवणे याचा अर्थ कंपायलरऐवजी मर्यादा मोजणे होईल.

काय थांबले, आणि त्याचा अर्थ काय
निरीक्षण	वाचन
प्रकाशित केलेल्या kotoba CLI ने एक मॉड्यूल उत्सर्जित केले आहे जे 128 फंक्शन्सपेक्षा जास्त कंपाइल होणार नाही	एक दोष, आणि हार्नेसमध्ये वैधता करण्याचे कारण. K=129 वर कॉलला फंक्शन निर्देशांक 128 वाहून नेणे आवश्यक आहे, जो पहिला मूल्य आहे ज्याला दोन LEB128 बाइट्स लागतात, आणि उत्सर्जक एक लिहितो. बाइट्स सांगतात की तो गहाळ एन्कोडर नाही तर वापरात नसलेला आहे: local.set 128 80 01 लिहिलेले आहे, आणि call 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 11.753 ms मध्ये K=1 प्रक्रिया-थंड तयार करते, कलाकृती चालविली आणि उत्तर तपासले — येथे मोजलेल्या कोणत्याही मार्गातील सर्वात जलद प्रथम निकाल.
जाहीर केलेल्या बायनरीने किती मोठा मॉड्यूल तयार करू शकतो?	128 पर्यंत फंक्शन्स. त्याहून अधिक म्हणजे तो धीमा नाही, तो चुकीचा आहे, आणि हा हार्नेस तो जलद मार्गाऐवजी अपयशी मार्ग म्हणून नोंदवतो.
स्रोत वाढल्यावर बिल्ड वेळ स्पर्धात्मक राहतो का?	K=128 द्वारे, वरच्या तक्त्यात Rust आणि C विरुद्ध रिलीज केलेल्या CLI चे मापन केले जाते. त्या बिंदूपासून, एकमेव Kotoba कंपाइलर जो अजूनही योग्य मॉड्यूल तयार करतो तो Amu आहे, जो रिलीज केलेल्या बायनरीऐवजी nbb वर चालतो, आणि प्रत्येक मोजलेल्या आकारावर सुमारे एक क्रमांकाने मंद गतीने चालतो — त्यामुळे मोठ्या आकारांवर बिल्ड स्पीड सध्या Kotoba ताकद नाही, आणि ही पृष्ठ याउलट काहीही दावा करणार नाही.
एखादा स्रोत पूर्णपणे किती मोठा तयार झाला आहे?	K=1023 Amu द्वारे — 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 क्रमाने फिरवते, त्यामुळे समान Amu कलाकृती प्रत्येक कार्यभारासाठी एकदा वेळ घेतली जाते आणि नंतर प्रत्येकी आर्मशी तुलना केली जाते. या पृष्ठावरील इतर चार बेंचमार्क्सच्या विपरीत, या होस्ट-गेटने यशस्वी (पात्र-होस्ट-लोड) केले, त्यामुळे हे या होस्टसाठी आकडे आहेत, फक्त निरीक्षण नाहीत. मर्यादित जलद दावा अजूनही सर्व 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 तपासलेली समता स्पष्ट 16-बाइट NEON किंवा SSE2 तुलना वापरते, हँडल आणि कॅनॉनिकल UTF-8 प्रमाणीकरणानंतर.	ऑप्टिमाइझ्ड असेंब्ली आणि दोन्ही स्थानिक ISA सेमांटिक व्हेक्टर तपासलेले. विंडोज स्वतंत्रपणे पिन केलेले आहे; विलंब रँक प्रलंबित आहे.
असिंक्रोनस इनपुट/आउटपुट क्षमता	मुळ-सीमित शेवटी वाचन/लेखन/यादी/अस्तित्व/हटविणे 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	सापेक्षElapsed वेळ
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

कोटोबा 0.7.3 · RUSTC 1.97.1 · होमब्रू क्लँग आवृत्ती 22.1.7 · जावाक 24.0.2. Kotoba, रस्ट, आणि C वास्म उत्सर्जित करतात; जावाक वर्ग फाइल उत्सर्जित करतो. वेगवेगळे लक्ष्य आणि संकलक कार्य हे एक प्रारंभिक निरीक्षण आहे, सार्वत्रिक क्रमवारी नाही. नोंदवलेले होस्ट-लोड गेट अयशस्वी झाले, त्यामुळे तक्ता पात्र वेग क्रमवारी नाही.

आश्रितता-मुक्त लहान-प्रकल्प विकासक-लूप मध्यवर्ती; 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
गो · 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 वर्ग	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 स्थानिक AOT · arm64 macOS स्थानिक AOT	2236.962 ms	N/A	11995.489 ms	2707.907 ms	375.7 ms	12391.54 ms

प्रत्येक उत्सर्जित कलाकृतीने नवीन प्रक्रियेत 42 तयार केले. लक्ष्ये आणि रनटाइम करार वेगळे आहेत; N/A कधीही शून्य नाही. होस्ट-लोड गेट अयशस्वी झाला, त्यामुळे हे पुनरुत्पादनीय निरीक्षणे आहेत, क्रॉस-भाषा गती रँकिंग नाही.

सहा क्षेत्रे, बाजूने बाजूने

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

स्ट्रिंग

C / Clang 1.463 ms
रस्ट 1.907 ms
जा 1.974 ms
JVM / Java 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 / Java 31.42 ms
जावास्क्रिप्ट / नोड.जेएस 31.818 ms

वाटप

C / Clang 1.353 ms
रस्ट 1.943 ms
जा 1.962 ms
JVM / Java 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 / Java 38.685 ms
जावास्क्रिप्ट / नोड.जेएस 94.124 ms
Kotoba / Wasm + टाइप केलेला JS होस्ट N/A — या लक्ष्याच्या करारात नाही —

साम्यकालिकता

C / Clang 2.916 ms
रस्ट 3.328 ms
जा 3.377 ms
JVM / Java 34.828 ms
जावास्क्रिप्ट / नोड.जेएस 55.105 ms
Kotoba / Wasm + टाइप केलेला JS होस्ट N/A — या लक्ष्याच्या करारात नाही —

खरा अनुप्रयोग

C / Clang 1.294 ms
जा 1.964 ms
रस्ट 2.047 ms
JVM / Java 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	N/A	N/A	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 / Java	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	N/A	N/A	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 / Java	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 चे शुद्ध 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	प्रत्येक उपलब्ध टप्प्यासाठी सात नमुने प्रकाशित केले जातात; लक्ष्य फरक आणि अयशस्वी होस्ट-लोड गेट सार्वत्रिक क्रमवारी प्रतिबंधित करतात
नेटिव्ह स्थिर-स्थिती कार्यान्वयन	अमू नेटिव्ह विरुद्ध रस्ट, क्लँग / C11, झिग, गो c-शेअर्ड, स्विफ्ट	सर्व 30 अर्थपूर्ण तुलना सेल पूर्ण आहेत; शांत-होस्ट गेट अयशस्वी झाल्यामुळे वेग क्रमवारी राखली
स्ट्रिंग्ज, संग्रह, वाटप, इनपुट/आउटपुट, समकालीनता, आणि वास्तविक अॅप	Kotoba, रस्ट, C, Go, JVM, आणि जावास्क्रिप्ट रनटाइम मार्ग	अचूक चेकसम आणि प्रक्रिया-थंड तसेच अमोर्टाइज्ड नमुने प्रकाशित केले आहेत; स्वतंत्र Kotoba I/O आणि थ्रेड्स N/A आहेत, तर त्याचा शुद्ध विनंती-प्रवेश अनुप्रयोग मोजला जातो; अयशस्वी लोड गेट रँकिंग थांबवतो

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

प्रत्येक अंमलबजावणी स्वतंत्रपणे तपासलेले ज्ञात उत्तर परत करते. सूट प्रत्येक इंजिन जोड्याला 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-स्मृती

मान्य घटक रनटाइम/स्थानिक स्मृती आणि घटक स्मृती ऑपरेशन्स हाताळू शकत नाहीत, आणि ऑपरेशन्स मर्यादित किंवा अडवले जातात.

विश्वसनीय संगणकीय आधार

मर्यादित वाचक · फ्रंटएंड प्रवेश · कलाकृती पडताळणी · वास्म/स्थानिक रनटाइम

शिल्लक धोका

रनटाइम-इंजिनच्या असुरक्षितता TCB मध्ये राहतात
मूलभूत लोडर्सना दुसऱ्या OS वेगळेपणाची सीमा आवश्यक आहे

T2-परिणाम

प्रत्येक संक्रमणात्मक घटक परिणाम जाहीर आणि मान्य केले जातात, ज्यात Kotoba-ने लिहिलेले प्रदाते वापरलेले परिणामही समाविष्ट आहेत.

विश्वसनीय संगणकीय आधार

परिणाम अनुमान · क्षमता सूची · फ्रंटएंड कॉल ग्राफ

शिल्लक धोका

kotoba आणि compiler grammar/effect parity सतत तुलना केली पाहिजे

T3-निर्बंधन

अनमंजूर क्षमता अनुपस्थित किंवा अनबाउंड आहे आणि ती प्रदाता किंवा स्थानिक हँडलरपर्यंत पोहोचू शकत नाही.

विश्वसनीय संगणकीय आधार

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

शिल्लक धोका

प्रदाता आणि नेटिव्ह अंमलबजावणी स्वतंत्रपणे संसाधन व्याप्ती सत्यापित करणे आवश्यक आहे
उत्पादन प्रभावी अनुदानांनी वाइल्डकार्ड स्कोप मनाई करावी

T4-निर्धारकता

त्याच मान्यताप्राप्त स्रोत, लक्ष्य, धोरण आणि लॉकमुळे त्याच निरीक्षणीय शुद्ध निकाल आणि कलाकृती बाइट्स तयार होतात.

विश्वसनीय संगणकीय आधार

कॅनॉनिकल वाचक · निश्चित कमी करणे · पिन केलेला टूलचेन

शिल्लक धोका

होस्ट परिणाम केवळ तेथे निर्धारक असतात जिथे त्यांचा क्षमता करार तसे सांगतो

T5-संसाधन-मर्यादा

स्रोत, प्रवेश, अंमलबजावणी, स्मृती आणि आउटपुट स्पष्ट मर्यादांसह वापरले जातात.

विश्वसनीय संगणकीय आधार

प्रवेश मर्यादा · इंधन मीटर · रनटाइम कोटा · पर्यवेक्षक वेळमर्यादा

शिल्लक धोका

प्लॅटफॉर्म पर्यवेक्षकांकडे अजूनही समान उत्पादन पृथक्करण पुरावा नाही

T6-पुरवठा-शृंखला

रिलीज प्रवेश कलाकृती ओळख, विश्वासार्ह स्वाक्षरी करणारा, वैधता आणि पुनरुत्पादक पुरावा बांधतो.

विश्वसनीय संगणकीय आधार

स्वाक्षरी तपासक · विश्वासार्ह स्वाक्षरीकर्ता संरचना · घड्याळ · रद्दीकरण संच

शिल्लक धोका

की कस्टडी आणि बाह्य रद्द वितरण कार्यरत TCB राहतात

T7-BACKEND-PARITY

एक सामायिक पोर्टेबल घटक पात्र बॅकएंड्समध्ये समान स्वीकृती, निकाल आणि परिणाम ट्रेस ठेवतो.

विश्वसनीय संगणकीय आधार

सामायिक अनुरूपता मॅनिफेस्ट · बॅकएंड अडॅप्टर्स · तुलना धावक

शिल्लक धोका

फक्त कंपाइलर वैशिष्ट्ये पोर्टेबल नाहीत आणि पोर्टेबल प्रोफाइलद्वारे नाकारली पाहिजेत

T8-HOST-RESOURCE-SCOPE

घटक आयात त्याच्या प्रदात्याकडे किंवा स्थानिक हँडलरकडे केवळ ठोस पोस्ट-इंटरसेक्शन संसाधन व्याप्तीसह पोहोचते आणि पावती जारी करते.

विश्वसनीय संगणकीय आधार

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

शिल्लक धोका

प्रदाता-विशिष्ट मार्ग, पुनर्निर्देशन, सिमलिंक आणि भाडेकरू तपासणीसाठी Q5 किट्स आवश्यक

पात्रता प्रश्न 1, तारीख 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 संदर्भ वाचा

शिका, प्रयत्न करा, नंतर खोलात जा

पहिल्या प्रोग्रामपासून भाषा करार, लायब्ररी, पुरावे, आणि तैनाती पृष्ठभागांपर्यंत जोडलेला मार्ग.

शिका

उद्देशानुसार दस्तऐवज

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

उघड दस्तऐवज नकाशा

कोड वाचा

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

खालील उदाहरण ब्राउझर डेमोमध्ये संकलित केलेले अचूक स्रोत आहे—जावास्क्रिप्ट पुनरावृत्ती नाही.

नमुना वाचा

चालवा

या पृष्ठावर चालवा

समान-उत्पत्ती, डाइजेस्ट-बाउंड 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

प्ले · वेबअसेंब्ली

सत्यापित कलाकृती चालवा

ब्राउझर 344 बाइट्स आणतो, SHA-256 सत्यापित करतो, प्रत्येक आयात नाकारतो, मॉड्यूल तयार करतो, आणि main() कॉल करतो.

अपेक्षित निकाल: 42

तयार. अजून कोड चाललेला नाही.

हे पूर्व-संकलित, अपरिवर्तनीय उदाहरण चालवते. ब्राउझरमध्ये मनमानी स्रोत संपादित करणे अद्याप संकलक पृष्ठभाग म्हणून वितरित झालेले नाही.

परस्परसंवादी डेमो: solar-helix (अतिथी-चालित WebGPU रेंडर) · kami-survivors (एक .kotoba खेळ) · gpu-clear (WebGPU धूर). wasm-webcomponent GitHub Pages पृष्ठभागावर होस्ट केलेले; उपलब्धता प्रति-ब्राउझर 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 UI आणि डिझाइन प्रणाली · 40 AI, 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