Griffin - Clojure से बना पूरी तरह regulated API-आधारित बैंक

 (juxt.pro)
2 पॉइंट द्वारा GN⁺ 2023-08-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक banking-as-a-service प्लेटफ़ॉर्म है, जो fintech कंपनियों को account opening, payments और onboarding को सीधे bank API की तरह जोड़ने देता है; मार्च 2023 में UK banking license मिलने के बाद यह regulated bank बन गया
  • सिस्टम Clojure on Kubernetes on AWS पर चलता है, और ज़्यादातर inputs को events में बदलने वाली event sourcing architecture को FoundationDB storage के साथ जोड़ता है
  • FoundationDB एक strict-serializable key-value store है, जो transactions और concurrent writes को support करता है; Griffin ने Datascript को port करके Datomic जैसी layer बनाई है, जिससे atomic reads और writes बनते हैं
  • business logic को छोटे log processors के इर्द-गिर्द अलग किया गया है, जो Clojure map लेते हैं और Clojure map output करते हैं; external system access को protocols और dedicated procs तक सीमित रखा गया है
  • Griffin का मानना है कि Clojure की immutability और audit log-friendly nature financial services की requirements से मेल खाती है, और remote hiring के साथ मिलकर छोटे candidate pool में भी high-quality engineers खोजना आसान बनाती है

API के रूप में उपलब्ध regulated banking platform

  • Griffin एक banking-as-a-service platform है, जो fintech कंपनियों को banking capabilities तेज़ी और सुरक्षित तरीके से integrate करने में मदद करता है
  • मार्च 2023 में Financial Conduct Authority से UK banking license मिला, जिससे यह पूरी तरह regulated UK bank बन गया
  • Griffin खुद को “the bank you can build on” कहता है, और उसका लक्ष्य बैंकों के लिए AWS जैसी बुनियाद बनना है
    • customer onboarding API
    • bank account creation API
    • payments API
  • fintech कंपनियों को ये capabilities देने के लिए कानूनी तौर पर किसी bank के साथ काम करना पड़ता है, और फिलहाल अक्सर mainframe इस्तेमाल करने वाले पारंपरिक high street banks के साथ काम करना पड़ता है
  • Griffin banking license और technology platform दोनों उपलब्ध कराकर वह आधार बनना चाहता है, जिस पर future fintech अपनी services बना सकें
  • license मिल चुका था, लेकिन उस समय यह mobilization stage में था; audit पूरा होने, अतिरिक्त funding जुटाने और code writing पूरी होने के बाद यह stage समाप्त होती है
    • लक्ष्य समय उस साल का Q3 या Q4 था

Clojure चुनने की पृष्ठभूमि

  • Clojure को immutability, expressiveness, और audit logs की ज़रूरत वाली financial services से compatibility के कारण platform language के रूप में चुना गया
  • Allen Rohner ने करीब 2007 में Rich Hickey की Clojure presentation देखी और माना कि यह उनके बनाए जा रहे Lisp से बेहतर है
  • 2011 में CircleCI शुरू करने के बाद उन्होंने लंबे समय तक Clojure इस्तेमाल किया; CircleCI में भी यह अच्छी तरह चला और उन्हें लगा कि यह financial services के लिए भी उपयुक्त है
  • JVM के बारे में पहले कुछ वर्षों तक उन्होंने इसके फायदे पूरी तरह नहीं समझे, लेकिन बाद में उनका मूल्यांकन बदलकर इसे बड़ा advantage माना गया
    • अन्य niche startup languages में libraries की कमी, compiler और runtime performance issues हो सकते हैं
    • JVM इन जोखिमों को कम करने वाला आधार बनता है
  • language choice कंपनी के character को दिखाती है, और Griffin ने माना कि Python या Java की तुलना में Clojure ज़्यादा मजबूत choice है
  • niche language इस्तेमाल करने पर candidates की संख्या घट सकती है, लेकिन senior/high-quality talent का proportion बढ़ सकता है

FoundationDB से बनाई गई data layer

  • Griffin architecture Clojure, Kubernetes और AWS पर चलती है, और लगभग पूरी तरह event sourcing से बनी है
  • database के रूप में FoundationDB इस्तेमाल होता है
  • FoundationDB transactions support करने वाला strict-serializable key-value store है
    • इसकी शुरुआत Silicon Valley startup के रूप में हुई
    • 2015 में Apple ने इसे acquire किया
    • करीब 2018 में Apple ने इसे फिर से open source किया
    • Apple इसे iCloud production में इस्तेमाल करता है
  • Apple ने FoundationDB के लिए लगभग 10 लाख transactions per second पर चलने वाला benchmark किया है
  • strict serializable database consistency में सबसे ऊंचे स्तर के बराबर है
  • basic API get a key, set a key जैसी है; यह SQL नहीं है
  • Griffin ने Datascript को FoundationDB पर port करके Datomic जैसी layer बनाई है
    • strict-serializable data store के ऊपर atomic queries संभव हैं
    • transaction-based reads और writes support होते हैं
  • FoundationDB single writer नहीं है; यह concurrent writes support करता है
  • Griffin को प्रति सेकंड 1,000 से अधिक transactions की ज़रूरत है, और यह आवश्यकता पूरी हो रही है

Event sourcing और log processor

  • Griffin system के सभी inputs events बन जाते हैं
    • API request
    • third-party webhook
  • events message log में जाते हैं; Griffin में event एक Clojure map होता है, जिसमें type field, key/value और spec होता है
  • पूरा system events पर reactions से बना है
  • छोटे log processors को proc कहा जाता है
    • proc इस तरह काम करता है: “message type A को listen करो, और response में B या C emit करो”
    • हर proc की अपनी private state होती है
  • message flow को graph के रूप में बनाया जा सकता है, और event terminal node तक पहुंचने तक चलता है
  • उदाहरण के लिए, web server HTTP event लेता है, payment request record करता है, फिर payment created या payment rejected event का इंतज़ार करके client को response देता है
    • यह flow Netty asynchronous HTTP handler का इस्तेमाल करता है
  • सभी events FoundationDB में record होते हैं
    • हर log processor के पास FoundationDB के अंदर अपने namespace जैसी private data होती है
    • proc किसी specific event type के record होने को watch करता है और अपने events वापस FoundationDB में record करता है
  • FoundationDB DB key changes को watch करने की capability देता है, जिससे reactive system efficient बन सकता है
  • database और अलग messaging system साथ इस्तेमाल करने पर race condition की संभावना बनती है
    • उदाहरण के लिए, ऐसी स्थिति जहां एक message disk पर और दूसरा network पर जा रहा हो, observer दोनों को अलग order में देख सकता है
    • Griffin single path से simplify करने के लिए FoundationDB में record करने वाला तरीका इस्तेमाल करता है

Monorepo और business logic isolation

  • Griffin monorepo इस्तेमाल करता है
  • फिलहाल efficiency के लिए कई log processes एक ही JVM में run होते हैं
    • प्रत्येक independent है, इसलिए इन्हें अलग JVM process के रूप में भी चलाया जा सकता है
    • अभी low hundreds scale के procs एक single JVM में run होते हैं
  • business logic को जितना संभव हो simple और clean रखा जाता है
    • individual log processor namespaces लगभग पूरी तरह pure Clojure हैं
    • third-party libraries लगभग नहीं हैं
    • side effects भी बहुत कम हैं
  • log processor एक function जैसा है, जो Clojure map input के रूप में लेता है और एक या अधिक Clojure maps लौटाता है
  • proc state में protocol होता है, इसलिए दूसरी तरफ की implementation जानना ज़रूरी नहीं होता
    • testing के दौरान in-memory database के रूप में इस्तेमाल किया जा सकता है
    • actual execution के दौरान FoundationDB में इस्तेमाल किया जा सकता है
  • बाहरी दुनिया के साथ interface को जितना संभव हो छोटा रखा जाता है
  • ज़्यादातर procs केवल अपनी internal state में write कर सकते हैं और messages emit कर सकते हैं
    • network calls नहीं
    • AWS calls नहीं
    • कोई अन्य external action नहीं
  • जब external systems से communication करना हो, तो dedicated dispatch handler वाला special proc रखा जाता है
    • AWS से communication करने वाला proc
    • clearing bank से communication करने वाला proc
    • अन्य API से communication करने वाला proc

इस्तेमाल किया जाने वाला Clojure ecosystem

  • business logic के अंदर libraries लगभग इस्तेमाल नहीं होतीं
  • API web server या service gateway जैसे बाहरी दुनिया से जुड़े क्षेत्रों में ये इस्तेमाल होते हैं
    • ring
    • netty
    • reitit
  • Clojure spec का व्यापक रूप से इस्तेमाल होता है
  • AWS integration के लिए Cognitect aws-api library इस्तेमाल होती है
  • application configuration और resource management के लिए closeable blog post पर आधारित तरीका इस्तेमाल होता है
    • यह approach है कि Component या Integrant के बिना with-open काफी है
    • lexical scope मिलता है, और binding declaration order configuration order को enforce करता है
    • Closeable implement न करने वाले state objects या stateless objects को with-open block में declare करने के लिए छोटा helper इस्तेमाल होता है

Hiring और team composition

  • Griffin का मानना है कि Clojure hiring में candidates कम होते हैं, लेकिन अच्छे candidates का proportion अधिक होता है
    • Java hiring में 1,000 CV आने पर भी अच्छे candidates 10 हो सकते हैं
    • Clojure hiring में 13 CV आने पर भी अच्छे candidates 10 हो सकते हैं, ऐसा वे कहते हैं
  • छोटे hiring pool में remote work महत्वपूर्ण है
    • geographic constraints घटाने पर worldwide, 3 time zones के भीतर, Europe आदि जैसे बड़े pools बनाए जा सकते हैं
  • कम समय में 100 engineers hire करने की स्थिति को वे anti-pattern मानते हैं
  • कंपनी का कुल headcount लगभग 70 है
  • Engineering team में लगभग 22–24 लोग हैं
    • लगभग दो-तिहाई UK में हैं
    • लगभग एक-तिहाई EU में हैं
    • Germany में 4, Sweden में 4, Ireland में 1 व्यक्ति के स्तर पर
    • headquarters London में है, लेकिन अधिकांश developers London के बाहर UK में हैं

Banking-grade operational resilience testing

  • Griffin को bank के रूप में operationally resilient होना चाहिए, और इसे वे downtime न होने जैसी requirement के करीब मानते हैं
  • पैसे से जुड़े होने के कारण, समस्या आने पर भी customer money नहीं खोएगा—यह बात वास्तव में prove करनी होती है
  • उनकी testing direction FoundationDB team के तरीके जैसी है
    • FoundationDB team ने database simulator बनाया
    • करीब 20 process types, यानी cluster के अंदर roles, को single-threaded C++ app के रूप में लिखा
    • C++ के ऊपर actor-model concurrency compiler बनाया
    • सभी system calls और network calls को protocol के जरिए किया, ताकि errors inject किए जा सकें
    • multi-threading भी message sending-based actor model के जरिए handle की गई
  • इस environment में errors deterministically inject किए जा सकते हैं
    • message A और B भेजे गए, लेकिन दूसरी तरफ B, A order में पहुंचे
    • message processing के दौरान disk write error आ गया
  • इसे test.check की generative testing जैसा माना जा सकता है, जहां system की सारी nondeterminism को एक controllable random number से seed किया जाता है
  • वे जिन चीज़ों को control करना चाहते हैं वे हैं disk errors, network errors और message reordering
  • मौजूदा समस्या यह है कि Java threading libraries, NIO और disk write के behavior को control करने का तरीका नहीं है
  • Jepsen जैसी spirit साझा है, लेकिन फर्क भी है
    • Jepsen को वे कई VMs रखकर processes kill करने जैसे brute force के करीब मानते हैं
    • database state को अंदर से inspect करना कठिन है, इसलिए coverage जानना मुश्किल है
    • पूरी तरह controllable environment में system calls या message interleaving को enumerate किया जा सकता है, और in-memory होने से बहुत तेज़ verification हो सकता है
  • FoundationDB team ने ऐसा testing environment शुरुआती दौर में बनाया था, और यह FoundationDB पर trust पैदा करने वाला factor है
  • Griffin hiring कर रहा है, और जानकारी Griffin careers page पर देखी जा सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-30
Hacker News राय

  • Griffin के मौजूदा VP of Engineering James Trunk ने Clojure तकनीक का परिचय देने वाली अब तक देखी सबसे स्पष्ट और मज़ेदार प्रस्तुति दी थी। सिफारिश करता हूं
    https://youtu.be/C-kF25fWTO8?si=PnjMNLdBLJ8zqSu-

  • अभी समस्या यह है कि आधार में मौजूद Java threading library, NIO और disk write व्यवहार को नियंत्रित करने का कोई तरीका नहीं है, और ऐसे सिस्टम की प्रकृति देखते हुए आगे भी शायद यह संभव नहीं होगा
    गैर-निर्धारित request order या task scheduling इस्तेमाल करने वाले सिस्टम में deterministic execution नहीं मिल सकता। कई OS threads हमेशा इस्तेमाल करने पर, या tests में अलग-अलग processes कई बार चलाने पर यही स्थिति बनती है
    जबरन deterministic बनाया जा सकता है, लेकिन application state machine के हर transition में ऐसे synchronization points लगाने पड़ेंगे जिन्हें test नियंत्रित कर सके, इसलिए यह बहुत कठिन है
    व्यवहार में लगता है कि सिस्टम के core को पूरी तरह synchronous डिजाइन करना और run time पर ऊपरी layers में concurrency जोड़ना ही तरीका है

    • मुश्किल है, लेकिन संभव है। सबसे महत्वपूर्ण है application की surface area घटाना। हमारा business logic लगभग पूरा pure functions है, और procs में Clojure protocol (Java interface) के पार होने वाली चीज़ों को छोड़कर side effects नहीं हैं
      इसलिए testing के दौरान सभी side effects को stubs से बदला जा सकता है। हमारे “user” code को threading library तक पहुंच नहीं होती, और threading “kernel” code में होती है
      असल में इस तरीके के लागू होने का एक अच्छा उदाहरण पहले से https://www.youtube.com/watch?v=4fFDFbi3toc में देखा जा सकता है
    • मैं यह नहीं कहूंगा कि बिल्कुल नहीं हो सकता। Clojure/ClojureScript के लिए structured concurrency DSL और process supervision लागू करने वाले missionary को संशोधित किया जाए तो शायद संभव हो
      missionary के अपने tests के लिए पहले से ही missionary flows को instrument करके state transitions verify किए जा रहे हैं

  • यह काफी अच्छी बात है कि दोनों founders ने मिलकर Learning ClojureScript नाम की किताब लिखी थी
    https://www.packtpub.com/product/learning-clojurescript/9781...

    • देखा कि किताब के तीसरे लेखक Allen Rohner हैं। Compass Labs में उनके साथ काम किया था, वे बेहद प्रतिभाशाली developer थे। उन्होंने CircleCI भी शुरू किया था

  • “हम मज़ाक में खुद को banking licence वाली technology company कहते हैं” वाला वाक्य, अगर कुछ गलत हो जाए तो बाद में बहुत खराब दिखने वाला quote बन सकता है

    • ऐसे attitude वाले bank का इस्तेमाल शायद नहीं करूंगा। technology company के label के साथ अक्सर यह अनुचित अहंकार जुड़ जाता है कि code लिखने भर से वे सब कुछ अच्छी तरह कर लेते हैं
      मेरे employer ने खुद को software के जरिए research outcomes को commercialize करने वाली education research company कहा था, और मुझे यह कहीं ज्यादा समझ में आता था तथा इससे culture भी बेहतर बना
    • fintech से सीखी गई बातों में से एक यह है कि banks जो COBOL code चलाते हैं, वह पुराना और maintain करना कठिन जरूर है, लेकिन उसमें काफी मूल्यवान ज्ञान है जिसे rebuild करने पर फिर से सीखना पड़ेगा
      banking में ऐसे ज्ञान को फिर से सीखने की कीमत बहुत महंगी हो सकती है

  • गंभीर सवाल है और कठोर लहजे के लिए माफ़ी, लेकिन मैं जो service इस्तेमाल करता हूं वह किस language में लिखी गई है, इसकी मुझे परवाह क्यों करनी चाहिए? Clojure में लिखी है, यह क्यों महत्वपूर्ण है? पेशे से Clojure developer होने के नाते ऐसी चीज़ों को Clojure में लिखा देखना अच्छा लगता है, लेकिन मुझे समझ नहीं आता कि मुझे इसकी परवाह क्यों करनी चाहिए
    community में यह उन चीज़ों में से एक है जो मुझे सच में नापसंद है। Clojure एक शक्तिशाली language है और मैं भी इसे खुशी से इस्तेमाल करता हूं, लेकिन community में ऐसा लगता है जैसे कोई impostor syndrome है कि किसी project में इस language का इस्तेमाल करने की बात दूसरों को बतानी और justify करनी ही है, जो अजीब है

    • यह एक Clojure company का blog post है जिसमें वह दूसरी Clojure company का interview कर रही है और tech stack पर focus है। किसी भी language ecosystem में ऐसे लेख uncommon नहीं हैं, और स्वाभाविक है कि इन्हें वे लोग लिखते और पढ़ते हैं जिन्हें उस technology में रुचि है
      आपकी बात समझ नहीं आई। क्या यह सभ्य समाज में अनुपयुक्त व्यवहार हो गया?
      यह काफी अनभिज्ञ लगता है। अगर “दिलचस्पी नहीं है” तो शामिल न हों, और लेखक को जो लिखना है लिखने दें
    • आमतौर पर ऐसी कहानियां उन languages के लिए सबसे महत्वपूर्ण हो जाती हैं जिन्हें अभी पर्याप्त acceptance नहीं मिला है, इसलिए उनके इस्तेमाल की अनुमति को लेकर चिंता करनी पड़ती है
      90s में PHP और Python developers को “Microsoft ASP क्यों नहीं इस्तेमाल करते” जैसे business questions का जवाब देने के लिए ऐसे examples share करते हुए याद करता हूं
    • अगर architecture ऐसा है कि server-side transaction के अंदर चलने वाला code भेजा जा सकता है, तो उस API का इस्तेमाल करने के लिए developers को भी Clojure में develop करना पड़ सकता है
      या फिर यह अपनी company में आने वाले developers को attract करने की कोशिश भी हो सकती है

  • ऐसे API बैंक हमेशा UK में ही क्यों होते हैं? मैं कई सालों से curl से बैंकिंग करना चाहता था, लेकिन अमेरिका में कोई भी यह सुविधा नहीं देता

    • अमेरिकी बैंकिंग हैरान करने वाली हद तक पीछे है, और तकनीक या innovation के नज़रिए से दशकों से दुनिया का नेतृत्व नहीं कर पाई है
      इसके उलट UK ने नए बैंकों और नई तकनीक को सक्रिय रूप से बढ़ावा दिया है। निजी खातों के बीच instant मुफ्त ट्रांसफर लगभग 20 साल पहले से मौजूद हैं, contactless payment कम से कम 10 साल से, mobile banking दशकों से, और सरकार द्वारा अनिवार्य किए गए बैंक API को लगभग 5 साल हो चुके हैं
      संक्षेप में, UK में बैंकिंग मानकों के हिसाब से तेज़ी से innovation करने वाला बहुत सक्रिय banking sector है, और और तेज़ innovation के लिए माहौल और ecosystem अच्छी तरह विकसित है
      अमेरिका में ऐसा लगता है कि बैंकों ने दशकों पहले technical innovation छोड़ दिया और fees तथा ग्राहकों के साथ दंडात्मक व्यवहार में innovation करना पसंद किया। इसलिए वहां नया innovation environment नहीं है, और मौजूदा बैंकों के लिए competition करने के बजाय competitors को दबा देना कहीं आसान है
      UK में भी हाल तक स्वतंत्र बैंकों की संख्या हैरान करने वाली हद तक कम थी; वहां वही चीज़ क्यों नहीं हुई, इसकी वजह शायद ऐसे कानूनों और regulations की प्रकृति है जो ग्राहकों के अधिकारों की काफी गारंटी देते हैं और उन्हें न मानने वाले बैंकों को सक्रिय रूप से दंडित करते हैं
    • अमेरिका में नया bank charter पाना मुश्किल है, लेकिन UK में challenger bank बनने का रास्ता तुलनात्मक रूप से साफ़ है। Jarvis भी Griffin शुरू करने के लिए SF से वापस London चले गए थे
      अमेरिका में जिन बैंकों के पास API हैं, वे बड़े fintech partnerships पर focus करते हैं, इसलिए simple API भी सामान्य bank account की तुलना में महंगा होगा। उदाहरण के लिए, अमेरिका का Grasshopper Bank उन गिने-चुने बैंकों में से एक है जो सामान्य commercial bank account के ऊपर API देता है
      मैं Treasury Prime में काम करता हूं, जो API देने वाले कई अमेरिकी बैंकों को support करता है
    • 2008 की financial crisis और उसके बाद आए banking scandals के बाद, taxpayer के पैसे से कई जाने-माने बैंकों को बचाना पड़ा, और उस समय UK government ने छोटे बैंकों को बढ़ावा देने के लिए कई कदम शुरू किए
      personal accounts की तरफ Monzo और Starling तथाकथित challenger banks में सबसे जाने-माने हैं[1]
      [1]: https://en.wikipedia.org/wiki/Challenger_bank
    • UK में सरकार ने बैंकों पर API requirements अनिवार्य कीं। अमेरिका में इसे “free market” पर छोड़ा गया है, जिसका असल मतलब है कि आपको Yodlee या Plaid जैसे भरोसे लायक न लगने वाले third parties पर भरोसा करना पड़ता है
    • अब https://column.com मौजूद है। पिछले साल यहां भी इसे cover किया गया था
      Column – developers के लिए chartered bank
      https://news.ycombinator.com/item?id=31109170

  • “एक और proprietary technology है जिसे open source करना चाहिए। Datascript को FoundationDB पर port किया है” — कृपया इसे public कर दें
    Datomic alternative के रूप में यह कैसे काम करेगा, यह जानने की उत्सुकता है

    • पूरा लेख “मज़े के लिए किसी project को over-engineer कैसे करें” वाली guide जैसा पढ़ा गया

  • “कानूनी तौर पर fintechs को ऐसा काम करने के लिए बैंकों के साथ काम करना पड़ता है, और आज इसका मतलब mainframe इस्तेमाल करने वाले पारंपरिक बड़े बैंक हैं। Griffin वह bank और technology platform है जिस पर भविष्य के सभी fintechs बनेंगे” — यह वाक्य ऐसा लगता है जैसे 2016 में लिखा गया हो
    बाजार पहले ही आगे बढ़ चुका है। Griffin अच्छा लगता है, लेकिन कई जगहों से कुछ साल पीछे है, और ClearBank जैसे स्थापित players पहले से ही bank API अच्छे से दे रहे हैं
    और players के आने की गुंजाइश है, इसलिए Griffin का market में आना अच्छा है, लेकिन काश pitch इतनी कमजोर न होती

    • बाजार में अभी भी बहुत ज्यादा options नहीं हैं। ClearBank सच में अच्छे product वाले तीन बैंकों में से एक है
      और सिर्फ अच्छा API होना काफी नहीं है। customer base के मुताबिक पूरा operating model चाहिए, और इसे बनाना कहीं ज्यादा मुश्किल है
    • “भविष्य के सभी fintechs जिस पर बनेंगे” वाला expression single point of failure जैसा लगता है, और लगता है कि competition के भ्रम बन जाने वाली late capitalism की समस्या को साफ़ दिखाता है

  • अभी नहीं। इसमें लिखा है: “जब हम audit पूरा कर लेंगे, और funding जुटा लेंगे, और code लिखना खत्म कर लेंगे, तब training wheels हटा देंगे। यह इस साल Q3 या Q4 के आसपास होगा”

  • जब कोई लेख “startups में सबसे शक्तिशाली language का उपयोग करना चाहिए, और वह Clojure है” से शुरू होता है, तो मुझे सच में बहुत बुरा लगता है
    यह बस आपकी राय है। startups में वह language इस्तेमाल करनी चाहिए जिससे team सबसे जल्दी MVP बना और launch कर सके, ताकि पहला customer या investment मिल सके। सामान्य startup के लिए यह low-code या no-code platform भी हो सकता है, हालांकि fintech में शायद नहीं
    अगर कहना ही हो तो LLMs और machine learning की वजह से Python को सबसे शक्तिशाली language भी कहा जा सकता है, और मैं आम तौर पर PHP developer हूं। Python शायद Mojo की वजह से और शक्तिशाली हो जाए, जो supposedly Python को 36000 गुना तेज़ बनाता है
    लेकिन मैं कभी नहीं कहूंगा कि कोई language X startups में इस्तेमाल की जाने वाली इकलौती और सबसे शक्तिशाली language है। यह पूरी तरह झूठ है और बस राय है

    • जाहिर है यह राय ही है। जब भी कोई कुछ कहता है, वह उसकी राय होती है
      उदाहरण के लिए, मेरी राय में मैं उस राय से सहमत हूं :-) मेरा solo-founder business Clojure और ClojureScript के बिना संभव नहीं होता, और यह इस language की “power” दिखाता है
      क्योंकि यह एक developer को सालों तक complex apps लिखने और maintain करने देता है, इसलिए मैं इस language को “powerful” मानता हूं। यह मुझे शक्ति देता है
    • यह वाक्य इस बात को देखते हुए कहीं ज्यादा समझ आता है कि JUXT, Nubank को छोड़कर, Clojure-specialist companies में सबसे प्रसिद्ध है और Clojure विषय से थोड़ा भी जुड़ी लगभग हर conference के नीचे उसका logo होता है
      Clojure की community काफी inward-looking है, जिसका overlap Python या PHP जैसी ज्यादा लोकप्रिय languages की तुलना में दूसरे Lisps से ज्यादा है। इसलिए Clojure सबसे शक्तिशाली language है वाला cliché कुछ हद तक सच होने के बावजूद, जो लोग इसे इस्तेमाल नहीं करते उनके लिए चौंकाने वाला लग सकता है
      हम Clojure developers इसके आदी हो चुके हैं, और अब superiority को मानकर बात करना लगभग greeting जैसा हो गया है
    • Python, खासकर 2023 के हिसाब से, सच में बहुत powerful है। लेकिन अजीब तरह से मैं LLMs और diffusion models को Clojure से orchestrate करता हूं
      LLM output को handle करने में भी मुझे Clojure ज्यादा पसंद है। बेशक जहां Python बिल्कुल fit बैठता है, वहां मैं अभी भी Python इस्तेमाल करता हूं