- हाल में AI एजेंट को अपनाने में बढ़ोतरी के साथ Go भाषा आधारित hybrid stack के उपयोग का रुझान बढ़ रहा है
- एजेंट की विशेषताएँ हैं लंबा execution time, उच्च लागत, और बार-बार होने वाला input/output wait
- Go हल्के goroutine, केंद्रीकृत cancellation mechanism, और channel-आधारित messaging जैसे high-performance concurrency model प्रदान करता है
- इसकी standard library बहुत व्यापक है, और profiling tool
pprof से memory और thread leak को ट्रैक करना आसान होता है
- हालांकि, Go की सीमाएँ भी हैं, जैसे machine learning ecosystem की कमी, बहुत उत्कृष्ट peak performance का अभाव, और अन्य भाषाओं की तुलना में कम third-party support
एजेंट क्या है
- एजेंट वह process है जो एक iterative loop में चलता है और अगला execution step खुद तय कर सकता है
- यह workflow की तरह पहले से तय path पर नहीं चलता, बल्कि condition (जैसे: “test pass”) या maximum iteration count के आधार पर तय करता है कि कब रुकना है
- वास्तविक service में एजेंट कुछ सेकंड से लेकर कई घंटों तक लंबे समय तक चल सकते हैं, और LLM call, browser manipulation आदि के कारण इनकी लागत अधिक होती है
- इन्हें user input (या किसी दूसरे agent के input) को process करना होता है, इसलिए input/output (I/O) wait time काफी होता है
Go भाषा एजेंट के लिए उपयुक्त क्यों है
high-performance concurrency
- Go के goroutine सिर्फ 2KB memory के साथ हज़ारों से लेकर दसियों हज़ार lightweight thread को एक साथ चला सकते हैं
- हर goroutine multi-core का उपयोग करके parallel processing करता है, इसलिए I/O और wait state वाले agent भी बिना अतिरिक्त बोझ के चलाए जा सकते हैं
- channel-based communication के ज़रिए shared memory की जगह message passing से synchronization लागू किया जा सकता है (Mutex का उपयोग न्यूनतम)
- यह उन agent के लिए उपयुक्त है जो asynchronous तरीके से message भेजते-लेते हुए state manage करते हैं
केंद्रीकृत cancellation mechanism
- Go में context.Context का उपयोग करने पर अधिकांश library और API cancellation signal को support करते हैं, इसलिए चल रहे execution को रोकना बहुत आसान होता है
- Node.js और Python में कई तरह के cancellation pattern मिश्रित मिलते हैं, लेकिन Go में एक consistent तरीके से safe cancellation और resource cleanup संभव है
समृद्ध standard library
- Go की standard library बहुत व्यापक है और HTTP/web, file, network I/O जैसे लगभग सभी क्षेत्रों को support करती है
- सभी I/O को goroutine के भीतर blocking operation मानकर business logic को सीधी रेखा वाले flow में लिखा जा सकता है
- Python में asyncio, threading, process जैसे कई concurrency pattern साथ होने के कारण जटिलता बढ़ती है
profiling और diagnostic tool
- Go के pprof जैसे built-in tool से memory leak और goroutine (thread) leak को real time में ट्रैक किया जा सकता है
- लंबे समय तक और concurrent रूप से चलने वाले agent में होने वाली leak समस्याओं का निदान करने में यह मजबूत है
LLM coding support बेहतर
- Go की सरल syntax और समृद्ध standard library की वजह से LLM Go-शैली का native code अच्छी तरह लिख पाता है
- framework dependency कम होने से LLM को version या pattern की चिंता कम करनी पड़ती है
Go की सीमाएँ
- third-party library और ecosystem, Python और TypeScript की तुलना में कमज़ोर हैं
- machine learning को सीधे implement करने के लिए यह उपयुक्त नहीं है (performance और support की सीमाएँ हैं)
- जहाँ सर्वोच्च performance की ज़रूरत हो, वहाँ Rust और C++ बेहतर हैं
- जो developer error handling में अधिक ढील पसंद करते हैं, उन्हें यह कुछ असुविधाजनक लग सकता है
2 टिप्पणियां
Java से बेहतर Go, और Go से बेहतर Rust :)
Hacker News राय
यह बात रेखांकित की गई कि ज़्यादातर एजेंट सिस्टम्स में सबसे बड़ा latency factor आखिरकार LLM calls ही होते हैं। लेख में बताए गए फायदे किसी एक खास language के पक्ष में नहीं जाते; असलियत यह है कि ज़्यादातर समय लंबे इंतज़ार, महंगे resource usage, user या दूसरे agents से input, और I/O wait में जाता है। इसलिए server execution speed या efficiency से ज़्यादा, Python जैसी language के विशाल AI libraries और support कहीं अधिक महत्वपूर्ण लाभ हैं। यह भी कहा जाता है कि Python में
asyncioया multithreading libraries पर सोचना पड़ता है, लेकिन वास्तव में agent development इतना कठिन नहीं है, और क्योंकि किसी ने पहले ही संबंधित workflow विकसित किया होता है, इसलिए शुरुआत करना आसान हैGo में agent बनाते समय concurrency और backpressure management patterns का अच्छी तरह स्थापित होना एक बड़ा फायदा लगा। Agents में अक्सर धीमी external services के साथ transactions शामिल होते हैं, और ऐसे कामों में Go के concurrency patterns बहुत उपयोगी होते हैं। बेशक, language उतनी निर्णायक नहीं है, और लगता है कि JavaScript सबसे ज़्यादा इस्तेमाल होती है। लेकिन code generation के मामले में Go और LLM का संयोजन अच्छा synergy देता है
Go की अलग पहचान इसकी बेहतरीन concurrency handling और आसान deployment है। Go में सिर्फ static binary deploy करनी होती है, इसलिए Python के environment और dependency issues से मुक्ति मिलती है
Agents orchestration layer की भूमिका निभाते हैं, और इसके लिए Go, Erlang, Node खास तौर पर उपयुक्त लगते हैं। AI-संबंधित libraries की बहुत बड़ी संख्या हमेशा ज़रूरी नहीं होती; I/O-heavy कामों को domain-specific tool interfaces के पीछे abstract करके ज़रूरत के मुताबिक किसी भी भाषा में subsystem बनाया जा सकता है
इस तरह के workload में Go का बड़ा लाभ नहीं है, क्योंकि ज़्यादातर समय I/O wait में जाता है। Go का type system सीमित है, और कई सुविधाएँ जो modern languages में built-in मिलती हैं, Go में workaround से करनी पड़ती हैं। TypeScript AI के लिए एक बेहतरीन glue language है, और Python के साथ इसका library support भी बहुत अच्छा है। मुझे Python से ज़्यादा TypeScript इसलिए पसंद है क्योंकि उसका type system कहीं ज़्यादा शक्तिशाली और mature है। Python भी तेज़ी से बेहतर हो रहा है। Node.js और Python में long-running jobs को interrupt करना बहुत मुश्किल है—इस दावे के पक्ष में पक्का आधार नहीं दिखता। ज़्यादातर tools यह सुविधा पहले से support करते हैं, और मुख्य भाषाएँ Python और JS ही हैं
Elixir और BEAM-आधारित agent frameworks के साथ प्रयोग किया, और फिलहाल BEAM + SQLite का संयोजन agents के लिए सबसे आदर्श लगता है। Agents को application redeploy किए बिना सुरक्षित तरीके से बदला जा सकता है, और BEAM की concurrency इस काम के लिए पर्याप्त से भी अधिक है। Stateful या ephemeral agents बनाना भी बहुत आसान है। आगे Python, Typescript, Rust में base agents बनाकर, भाषा-प्राथमिकता के अनुसार complex agent development संभव करने के लिए MCP servers भी बनाने की योजना है
Extism project और Elixir SDK की सिफारिश की गई। इस संयोजन से Elixir में core services, routing, message passing बनाया जा सकता है, BEAM/OTP के फायदों का लाभ लिया जा सकता है, और दूसरी भाषाओं में लिखे छोटे व हल्के Wasm modules के रूप में agents को plugins की तरह embed भी किया जा सकता है
Extism
Elixir SDK
यह जानने की उत्सुकता है कि BEAM के built-in data store
mnesiaकी जगह SQLite चुनने का कोई खास कारण है या नहींmnesia docs
Agent का अधिकांश समय LLM responses का इंतज़ार करने और external services (API, DB) calls में जाता है। Language runtime की performance का वास्तविक प्रभाव लगभग नहीं के बराबर है। अगर agent performance और scalability के लिए कोई language feature सच में महत्वपूर्ण है, तो वह JSON serialization और deserialization performance होगी
इसलिए native रूप से JSON संभालने वाली TypeScript जैसी language इस्तेमाल करना बेहतर लगता है। TypeScript का type system Go से भी कहीं ज़्यादा शक्तिशाली है
अनुभव के आधार पर, LLM calls के अलावा agents में सबसे महंगा काम asynchronous editing (
merge,diff,patch) conflict resolution होता है। यह काम low-level libraries को सौंपा जा सकता है, लेकिन serialization की तरह इसे optimize करना भी कठिन हैयह ampcode.com की agent building guide याद दिलाती है। Python अपनी dynamic language प्रकृति के कारण decorators के ज़रिए methods को सीधे tool calls में बदलने, tool function iteration से lists बनाने, और JSON schema में तेज़ी से बदलने जैसे कामों के लिए बहुत स्वाभाविक है। दूसरी ओर, कई external triggers (जैसे user input, Gmail mail, Slack messages आदि) से नए agent runs शुरू कराने वाली संरचना Go में channels और
switch for loopके साथ कहीं अधिक intuitive लगी। Python में कई queues और threading अलग से बनानी पड़ती हैं, जिससे जटिलता बढ़ती हैलेख के तर्क से देखें तो Elixir agents के लिए आदर्श है
Go का सीमित और कमजोर type system लगभग हर application के लिए अनुपयुक्त है। वास्तव में Go की सबसे बड़ी कमी खुद भाषा है। भाषा के बाहर की चीज़ें ही उल्टा वह कारण हैं जिनकी वजह से Go को स्वीकार किया जाता है
कई साल Go में programming करने के बाद भी मैं type system की समस्याओं से सहमत हूँ। LLM क्षेत्र के लोग लगभग सिर्फ Python या JavaScript ही इस्तेमाल करते दिखते हैं। मुझे लगता है कि सभी को modern languages की ओर जाना चाहिए, लेकिन Python/JavaScript के बिखरे हुए imports और package समस्याओं की तुलना में Go फिर भी अपेक्षाकृत बेहतर विकल्प हो सकता है
मैं विस्तार से सुनना चाहूँगा कि Go type system की सीमाएँ agent बनाने में किस तरह बाधा बनती हैं
वास्तविकता यह है कि Go में static type system इसलिए डाला गया क्योंकि performance requirements पूरी करने का दूसरा तरीका नहीं मिला। इसे dynamic typing language की तरह इस्तेमाल किया जाता है—यही कहना ज़्यादा सही है, और भाषा-डिज़ाइन के उद्देश्य को गलत समझने का परिणाम भी यही है। कोई यह दावा कर सकता है कि dynamic typing languages सामान्य रूप से अनुपयुक्त हैं, लेकिन व्यवहार में Python, Erlang, Elixir जैसी dynamic typing languages का सक्रिय उपयोग उल्टा यह दिखाता है कि dynamic typing इस problem domain के लिए अधिक उपयुक्त है
कई return values अच्छी तरह compose नहीं होतीं, error support exceptions से बेहतर ज़रूर है लेकिन बहुत verbose है, channels में गलती करना आसान है, और enum types निराशाजनक लगते हैं। फिर भी interfaces हैरान करने वाले ढंग से अच्छा काम करते हैं, और packaging system काफी smooth है। Rust सीखते समय पता चला कि उसका file structure Go की तुलना में कहीं अधिक जटिल है। भाषा सरल होने के कारण तरह-तरह के linters और code generation tools बनाना भी आसान है। लंबे समय तक Go code का maintenance करना Python/JS की तुलना में कम चिंताजनक लगता है
अगर Go में compile होने वाली कोई LISP/Scheme dialect अच्छी तरह maintained हो, तो वह सच में बहुत अच्छा होगा
लंबे इंतज़ार और ऊँची execution cost वाले processes में यह कमी है कि process मर जाए तो सारा काम खो जाता है। इंतज़ार के दौरान state को database में serialize करना ज़्यादा सुरक्षित हो सकता है, लेकिन ऐसा आसान बनाने वाली कोई language नज़र नहीं आती। Checkpoint-based state machines लिखना आसान नहीं है
समझाया गया कि checkpoint-based state machines, Hatchet(hatchet.run) और Temporal(temporal.io) जैसे platforms की मुख्य सुविधा हैं। वे workflow के भीतर function execution history को store करते हैं और interrupt होने पर उसी history को अपने आप replay करते हैं। यह तर्क दिया गया कि memory snapshots की तुलना में output-unit progress history कहीं अधिक efficient होती है। (Hatchet founder)
goroutine, threads, और long-running chains को अंततः atomic work units में तोड़ना पड़ता है, और state serialization अनिवार्य है। इससे failure recovery, error tracing, result re-reference, और multi-node distribution जैसी ज़रूरतें पूरी होती हैं। Elixir framework Oban(github.com/oban-bg/oban) इसी तरीके का है, और asynchronous job persistence के महत्व पर Oban article भी सुझाया गया। (Oban author)मैं golang-आधारित agent library विकसित कर रहा हूँ, और लगा कि पर्याप्त logging हो तो agent state कभी भी restore की जा सकती है। सिर्फ timestamps और parent runs जानकर child/branch execution tree बनाया जा सकता है। Maps और DB को साथ इस्तेमाल करके sessions manage किए जा सकते हैं और ज़रूरत पड़ने पर दोबारा reconstruct भी किए जा सकते हैं। अलग-अलग objects को सीधे पकड़े रखने के बजाय, stateless objects को map में id से lookup किया जाता है, और previous actions, steps, context को state object में रखा जाता है। Agent/workflow consistency भी results को hash करके हल की जाती है। अभी तक सिर्फ basic agents/tools बनाए हैं; logging, restore, और cancellation logic अभी विकसित नहीं हुई है
Temporal long-running process checkpointing के लिए काफी उपयोगी है, और language-neutral भी है
मैं भी job queue के बारे में सोचते हुए Postgres में एक rudimentary queue बनाने पर विचार कर रहा हूँ। इसके फायदे हैं servers के बीच workload distribution, process बंद होने पर tasks का loss न होना, और बेहतर visibility। लेकिन इसके बदले code complexity बहुत बढ़ सकती है, इसलिए architecture को सरल रखना कठिन लगता है
AI engineers JavaScript का उपयोग करने से बेहद कतराते हैं। TensorFlow for Swift का बंद हो जाना AI language diversity के अंत जैसा था
मुझे नहीं लगता कि JavaScript से परहेज़ सिर्फ AI engineers तक सीमित है। 30 साल से ज़्यादा JS coding कर चुके व्यक्ति के रूप में मैं भी इससे सहमत हूँ
JS एक भाषा के रूप में बहुत खराब है, और इसे backend तक लाना गलती थी। TypeScript भी आखिरकार नीचे मौजूद JS की समस्याओं को हल नहीं कर पाती। JS या TS का उपयोग करने से बचना चाहिए, और Go, Rust, Python, Ruby, Elixir, F# जैसे दूसरे विकल्प पसंद करने चाहिए
यह जानना दिलचस्प होगा कि agents के लिए JS को खास तौर पर अच्छा क्यों माना जाता है
ML क्षेत्र में बेहतर concurrency model की ज़रूरत महसूस होती है। Go में ML करने की कोशिश की, लेकिन library support की कमी और external gRPC calls या wrappers पर निर्भरता के कारण यह व्यवहारिक रूप से लगभग असंभव है। Python की अपनी सीमाएँ हैं, और C++ इतना verbose है कि productivity पर बुरा असर पड़ता है