अगर AI कोड लिखता है, तो फिर Python क्यों इस्तेमाल करें?

 (medium.com/@NMitchem)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI-सहायित डेवलपमेंट के साथ भाषा चुनने का मानदंड इंसानों की लिखने की गति से बदलकर AI की संशोधन क्षमता और runtime performance पर जा रहा है
  • 2026 में Claude Opus 4.7, GPT-5.5, Gemini 3.1, DeepSeek V4 ने SWE-bench Verified 80% पार किया
  • Rust में compiler feedback loop AI की self-correction में मदद करता है, और Go व Swift भी तेज type checking के कारण agents के लिए अनुकूल हैं
  • TypeScript compiler का Go port, Rust-आधारित C compiler, Rue, Ladybird JS engine port जैसे बड़े बदलाव पहले से चल रहे हैं
  • Python·JavaScript ecosystem भी Rust tools और wrappers पर अधिक निर्भर हो रहे हैं, लेकिन Prisma·PyTorch·छोटी भाषाओं जैसे अपवाद अब भी मौजूद हैं

AI-सहायित डेवलपमेंट ने भाषा चुनने के मानदंड कैसे बदले

  • नए प्रोजेक्ट्स के लिए लंबे समय तक डिफ़ॉल्ट विकल्प Python या TypeScript रहे
    • क्योंकि ecosystem बड़ा था, hiring pool व्यापक था, और जल्दी demo बनाया जा सकता था
    • Rust, Go, C++ 10~100 गुना performance दे सकते थे, लेकिन learning time, छोटा talent market, और जटिल build systems इसकी लागत थे
    • इसलिए पहले Python version launch किया जाता था और कहा जाता था कि “बाद में performance सुधारेंगे”, लेकिन अक्सर वही version बना रहता था
  • AI ने कठिन भाषाओं को संभालना शुरू किया, तो यह संतुलन बदलने लगा
    • अब भाषा चुनने में “क्या इंसान इसे जल्दी लिख सकता है” से ज़्यादा “क्या AI इसे अच्छे से लिख और सुधार सकता है” और runtime performance महत्वपूर्ण हो गए हैं

कठिन भाषाएँ पहले AI के लिए आसान हो रही हैं

  • 2 साल पहले GPT-4, Rust function लिखते समय मौजूद ही नहीं रहने वाले crate नाम गढ़ देता था
  • अप्रैल 2026 तक Claude Opus 4.7, GPT-5.5, Gemini 3.1, DeepSeek V4 ने कुछ ही हफ़्तों के अंतर में SWE-bench Verified में 80% पार कर लिया
  • रिसर्च लैब्स अब system work को स्पष्ट रूप से optimize कर रही हैं
    • concurrency bugs
    • race conditions
    • planning stage में दिखने वाली architectural flaws
  • CtrlAltDwayne के अनुसार 2026 में Rust की ताकत memory safety या performance से ज़्यादा compiler feedback loop में है
    • AI, C++ की तुलना में Rust बेहतर लिखता है
    • Rust compiler के error messages model की real-time self-correction के लिए signal बनते हैं
    • Rust, AI-सहायित डेवलपमेंट के लिए मानो 10 साल पहले “संयोग से डिज़ाइन” की गई भाषा की तरह काम करता है
  • यही तर्क कुछ हद तक Go और Swift पर भी लागू होता है
    • मजबूत type systems और तेज compile/check loops agents को घना iteration cycle देते हैं
    • जो system languages इंसानों के लिए कठिन थीं, वे agents के लिए उल्टा आसान लक्ष्य बन सकती हैं

असली दुनिया में जारी हुए उदाहरण

  • Microsoft का TypeScript compiler को Go में port करना

    • Microsoft ने TypeScript 7.0 beta जारी करते हुए 10 साल पुराने TypeScript codebase को Go में port किया
    • TypeScript 7.0 beta, 6.0 की तुलना में लगभग 10 गुना तेज है
    • Anders Hejlsberg के आकलन के मुताबिक Go, engineering cost के एक हिस्से में performance का अधिकांश लाभ देता है
    • दुनिया के सबसे बड़े JS/TS संगठनों में से एक ने अपने मुख्य tool के लिए ज़्यादा कठिन लेकिन तेज भाषा चुनी, यह दिखाता है कि effort बनाम benefit का हिसाब बदल चुका है

  • 16 Claude agents से बना Rust-आधारित C compiler

    • Anthropic के शोधकर्ता Nicholas Carlini ने 16 Claude agents को parallel में orchestrate करके Rust में production C compiler लिखा
    • इसका आकार 100,000 lines है, और यह x86·ARM·RISC-V पर Linux 6.9 boot कराता है
    • इसने QEMU, FFmpeg, SQLite, PostgreSQL, Redis compile किए और Doom भी चलाया
    • कुल लागत लगभग 2,000 Claude Code sessions में 20,000 डॉलर से कम थी
    • Rust में लिखा C compiler पहले postgraduate thesis स्तर का काम माना जाता था, लेकिन अब यह केवल असाधारण काम नहीं रह गया है

  • Steve Klabnik का Rue

    • The Rust Programming Language के सह-लेखक और 13 साल के Rust veteran Steve Klabnik ने Claude के साथ मिलकर Rue नाम की नई system language सिर्फ 2 हफ़्तों में बनाई
    • नतीजा लगभग 70,000 lines of Rust था
    • उनका कहना है कि यह 2 हफ़्तों का काम उनके पुराने 1~2 महीने वाले प्रयासों से आगे गया

  • Ladybird JavaScript engine का Rust port

    • Ladybird browser के संस्थापक और C++ engineer Andreas Kling ने Claude Code और Codex को सैकड़ों छोटे prompts देकर Ladybird के JavaScript engine को C++ से Rust में 2 हफ़्तों में port किया
    • नतीजा लगभग 25,000 lines of Rust था, और इसने C++ मूल संस्करण के साथ byte-level equivalence हासिल की
    • test262 और Ladybird tests मिलाकर 65,000 से अधिक मामलों में कोई regression नहीं था
    • उनका कहना है कि यही काम हाथ से करने पर कई महीने लगते

कमज़ोर पड़ती “ecosystem” की दलील

  • Python और JavaScript के पक्ष में सबसे मज़बूत तर्क भाषा खुद नहीं, बल्कि ecosystem था
    • FastAPI, Django, PyTorch, React, Next.js, और npm के 40 लाख packages जैसे आधार मौजूद थे
    • टीमें कुछ दिनों में features इसलिए ship कर पाती थीं क्योंकि ecosystem पहले ही 90% समस्याएँ हल कर चुका था
  • पिछले 10 सालों में यह फ़ायदा निर्णायक था, लेकिन पिछले 2 सालों में यह कमज़ोर पड़ने लगा है
  • Python ecosystem के भीतर भी Rust-आधारित components पर निर्भरता बढ़ रही है
    • pydantic का पूरा validation core एक Rust library है
    • pandas का विकल्प Polars, Rust में लिखा गया है
    • Hugging Face tokenizers और orjson भी Rust में हैं
    • JetBrains 2025 Python survey के अनुसार Python binary extensions में Rust का उपयोग एक साल में 27% से 33% हो गया
  • डेवलपमेंट tools की नींव भी इसी दिशा में जा रही है
    • Charlie Marsh द्वारा 2022 में स्थापित Astral ने Rust में लिखे ruff, uv, ty जारी किए, और इन तीनों tools के monthly downloads शून्य से बढ़कर सैकड़ों मिलियन हो गए
    • 19 मार्च 2026 को OpenAI ने Astral का अधिग्रहण किया, और उसका मानना है कि uv, Codex के compute time में हर हफ़्ते लगभग 10 लाख मिनट बचाता है
    • 10 हफ़्ते पहले Anthropic ने Bun का अधिग्रहण किया
    • Bun के monthly downloads 70 लाख और GitHub stars 89,000 थे, और इसे “AI-driven software engineering के लिए essential infrastructure” कहा गया
    • Evan You की VoidZero ने Rolldown-Vite जारी किया
    • इस Rust bundler ने GitLab के 2.5 मिनट के build को 40 सेकंड तक घटा दिया और memory usage को 100वां हिस्सा कर दिया
  • Vercel में products के VP Lee Robinson ने कहा कि “JS optimization की सीमा तक पहुँच चुका है”
  • Python और JavaScript में इस्तेमाल किए जाने वाले packages अब बढ़ती मात्रा में उन भाषाओं में लिखे code के wrappers बनते जा रहे हैं जिन्हें पहले सीधे ship करना कठिन माना जाता था
    • अब अगर उन्हीं भाषाओं में सीधे ship किया जा सकता है, तो wrapper एक overhead जैसा लगने लगता है

patch से port की ओर आसान होता बदलाव

  • मौजूदा open source ecosystem का virtuous cycle patch-centric था
    • Python आसान है, इसलिए उसे चुना जाता है
    • dependency में bug मिलता है
    • उसे ठीक करके upstream में भेज दिया जाता है
    • ecosystem और स्वस्थ हो जाता है
  • agents अब contribution की इकाई को patch से port की ओर ले जा रहे हैं
  • Flask के संस्थापक Armin Ronacher ने जनवरी में agents का इस्तेमाल करके Rust library MiniJinja को Go में port किया
    • कुल execution time 10 घंटे था
    • इनमें 3 घंटे supervision में और 7 घंटे unattended चले
    • वास्तविक human time सिर्फ 45 मिनट था
    • API cost 60 डॉलर थी
  • अगर किसी library को भाषाओं के बीच port करना 45 मिनट का काम बन जाए, तो किसी और की library में fix भेजने की दलील कमज़ोर हो जाती है
    • सवाल “जब patch कर सकते हो तो fork क्यों नहीं?” से बदलकर “जब fork कर सकते हो तो patch क्यों?” हो जाता है
  • Armin Ronacher का मानना है कि value code से हटकर tests और documentation की ओर जा रही है
    • एक अच्छा test suite, code से भी ज़्यादा मूल्यवान हो सकता है
  • PyPI और npm को बनाने वाला loop अभी भी काम कर रहा है, लेकिन 2028 में भी वैसा ही रहेगा या नहीं, यह स्पष्ट नहीं है

अपवाद अभी भी मौजूद हैं

  • हर बदलाव एक ही दिशा में नहीं जा रहा
  • कुछ मामलों में पुराने विकल्प अब भी सही हैं
    • Prisma ने अपना Rust query engine हटाया और TypeScript/WASM core पर शिफ्ट किया
    • bundle size 85% कम हुई
    • queries अधिकतम 3.4 गुना तेज हुईं
    • native Rust binaries serverless runtimes के लिए प्रतिकूल हो सकती हैं
  • PyTorch अभी भी deep learning research का लगभग 85% हिस्सा रखता है
    • model weights किस भाषा में wrap किए गए हैं, इससे बहुत प्रभावित नहीं होते, इसलिए इसकी स्थिति जल्दी बदलना कठिन है
  • AI सभी system languages को समान रूप से अच्छी तरह नहीं संभालता
    • Zig, Haskell, Gleam जैसी छोटी भाषाओं में AI generation quality अभी Rust या Go जैसी नहीं है
    • training data तय करता है कि models किस हद तक मदद कर सकते हैं
    • Rust और Go, GitHub पर पर्याप्त मात्रा में मौजूद होने के कारण लाभ में हैं
    • Zig, Haskell, Gleam अभी उस curve के कमज़ोर हिस्से में हैं

यह बदलाव टिकाऊ क्यों हो सकता है

  • Python और TypeScript के पक्ष में पुरानी defense असल में developer experience की defense थी
    • इन्हें इसलिए चुना जाता था क्योंकि ये इंसानी आइडिया और ship हुए product के बीच friction कम करते थे
    • Rust runtime में धीमी भाषा नहीं थी, बल्कि रात 2 बजे shipping करनी हो तो धीमी भाषा थी
  • अब agents कठिन हिस्से संभालने लगे हैं
    • इंसानों की भूमिका “code लिखने” से “system design और output review” की ओर जा रही है
    • इस ढाँचे में Python की syntactic convenience हर branch पर कम महत्वपूर्ण हो जाती है
    • कठिन भाषाओं के runtime advantages, production में चलने वाले हर दिन के साथ जुड़ते जाते हैं
  • Armin Ronacher ने फ़रवरी के लेख A Language For Agents में कहा कि coding cost तेज़ी से गिर रही है और ecosystem की चौड़ाई कम महत्वपूर्ण हो रही है
  • पिछले 20 सालों की language choice इस बाधा के इर्द-गिर्द बनी थी कि “इंसान code लिखते हैं, और इंसान low-level languages में धीमे होते हैं”
    • यह बाधा अब हटनी शुरू हो गई है
  • Stack Overflow 2025 survey में Rust लगातार 10वें साल सबसे admired language रही और 72% पर पहुँची
    • Gleam 70%
    • Elixir 66%
    • Zig 64%
    • पसंद पहले से मौजूद थी, अब tools उस पसंद के पीछे चल रहे हैं

agents के लिए आसान भाषाओं की ओर अगला कदम

  • Karpathy ने फ़रवरी में कहा कि LLM software की पूरी constraint landscape बदल रहे हैं
    • उनका मानना है कि C से Rust porting की लहर में इसके संकेत दिखते हैं
    • उन्होंने यह भी जोड़ा कि LLM के target language के रूप में Rust भी शायद अंतिम optimal विकल्प नहीं है
  • आज के विजेता सिर्फ शुरुआत हो सकते हैं; अंतिम रूप अभी और दूर हो सकता है
  • @RealRichomie ने 24 अप्रैल को कहा कि programming का भविष्य इंसानों के लिए सबसे आसान भाषा नहीं, बल्कि agents के लिए सबसे आसान भाषा की ओर जाएगा
    • engineers ने Rust या Tauri को बिल्कुल जाने बिना Mac apps ship किए
    • नतीजे Electron version के मुकाबले लगभग 10वां आकार रखते थे और runtime performance बेहतर थी
    • इंसानों को Rust सीखे बिना भी वह परिणाम मिल गया
  • अगला प्रोजेक्ट ज़रूरी नहीं कि Python को डिफ़ॉल्ट मानकर शुरू हो

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • अगर आप इस दावे से सहमत हैं कि LLM coding tools को non-deterministic compiler की तरह देखा जा सकता है, तो जितना हो सके उतनी performant language चुनना काफ़ी समझदारी लगती है
    बेशक library या language-specific native फ़ायदों जैसे कई अपवाद हैं, लेकिन पिछले लगभग एक महीने में C++ में काम करके देखा तो language choice की वजह से धीमी हुई एकमात्र चीज़ compile time थी

  • शुरुआती comments पढ़कर हैरानी हुई कि training data की बात दिखी ही नहीं। Python code training data में बहुत ज़्यादा है
    AI से Brainfuck भी लिखवाया जा सकता है, लेकिन मेरा मानना है कि Python जैसा नतीजा नहीं मिलेगा
    आगे का सवाल यह है: अब जब AI है, तो ज़रूरत पड़ने तक language की परवाह क्यों करनी चाहिए?

    • 5 साल बाद फिर से Perl इस्तेमाल करने का मन हुआ, और Go में बन रहे proxy को उठाकर कई integration tests लिखने का बहुत सरल तरीका चाहिए था
      ज़्यादातर चीज़ें Claude Code से लिखवाईं, और Claude ने Perl को सच में बहुत अच्छी तरह संभाला। मैंने कहा CPAN को मत छुओ, सिर्फ Perl standard library इस्तेमाल करो, और उसमें HTTP client, TLS, JSON सब built-in निकला; जो काम मैं आमतौर पर shell script से करता, उसे इसने बहुत स्थिर और आसान तरीके से बदल दिया
      Perl ज़्यादा बदला नहीं है और training data भी काफ़ी है, इसलिए Claude उन स्थितियों में Perl काफ़ी अच्छी तरह इस्तेमाल करता लगता है जहाँ आम तौर पर shell script याद आती है
    • हैरानी की बात है कि agentic coding tasks में LLM, दूसरी आम programming languages की तुलना में Python reasoning कहीं ख़राब करता है
      डेटा यहाँ है: https://gertlabs.com/rankings?mode=agentic_coding
    • बस Go इस्तेमाल करो। LLM ने Go बहुत देखा है, इसे अच्छी तरह लिखता है, यह लगभग तुरंत compile हो जाता है, और typed compiled language के सारे फ़ायदे भी देता है
      मैंने AI से एक बड़ा Python codebase बनवाया, और LLM बार-बार arguments या dictionary shapes ग़लत अनुमान लगाता रहा। Unit tests या pydantic जैसे tools मदद करते हैं, लेकिन ऐसी runtime errors को शुरू से टालना ज़्यादा बेहतर है
    • सिर्फ training data से पूरा जवाब नहीं मिलता। LLM दूसरे programming languages में translate करने का काम सच में बहुत अच्छा करता है। यह text translation systems से निकला है, तो यह स्वाभाविक भी है
      जिन languages का public code अपेक्षाकृत कम है, उनमें भी नतीजे शानदार रहे। बड़ा अवरोध यह है कि LLM target language के आम idioms की नकल करता है, और Java या C# जैसी “enterprise-like” languages में बेकार का boilerplate code तुरंत बहुत बढ़ सकता है। तब output usable context window size से आगे निकलने लगता है और quality गिरने का ख़तरा बढ़ जाता है
    • अगर आप AI से open loop में code generate करवा रहे हैं, तो training data मायने रख सकता है। Python में संभावना ज़्यादा है कि किसी ने पहले से आपकी माँग जैसा code लिखा हो
      लेकिन अगर agent code बनाता है, compile करने की कोशिश करता है, detailed error messages देखता है, और फिर उन्हीं messages के आधार पर code को refine करता है, तो नतीजा ज़्यादा high quality होता है। rustc diagnostics बहुत अच्छे हैं, और चाहे Python या JavaScript/TypeScript कहीं ज़्यादा हों, अब online Rust code भी काफ़ी मौजूद है

  • Python क्यों? क्योंकि मैं इसे 10 साल से ज़्यादा समय से इस्तेमाल कर रहा हूँ, मुझे debug करना आता है, और agent code लिखकर 10 सेकंड में कोई बड़ी गड़बड़ी करने जा रहा है या नहीं, यह मैं अंदाज़े से पकड़ सकता हूँ
    दूसरी languages में ऐसा नहीं है और बहुत कुछ दोबारा सीखना पड़ेगा। AI भले ही तेज़ी से code उगल दे, फिर भी मुझे Python में कुछ हद तक control होने का एहसास रहता है। Go या Rust में करता तो यह AI-assisted programming कम और पूरे product को YOLO मोड में धकेल देने वाली “vibe coding” ज़्यादा लगती

    • मैंने agent era में Rust इस्तेमाल करना शुरू किया, और दूसरी languages से आया अनुभव फिर भी काम आया; code smell और खराब architecture पहचानने में मदद मिली
      Memory safety वाले हिस्से में क्या “सही” है, यह न जानने के कारण सीखना पड़ा, लेकिन बाकी सब काफ़ी smooth रहा
      Syntax धीरे-धीरे background में चला जाता है और आप ऊँचे स्तर की चीज़ों पर ध्यान देने लगते हैं, नए रास्ते explore करते हैं। एक बार कोशिश करें, आपको सुखद आश्चर्य हो सकता है कि कितना अनुभव transferable है
    • मेरा अनुभव भी ऐसा ही रहा। AI-generated Python code में कुछ ही lines देखकर पता चल जाता है कि यह बकवास है या नहीं, इसलिए मैं ज़्यादातर projects में अब भी Python ही इस्तेमाल करता हूँ

  • अगर AI लिख देगा तो दिमाग़ का इस्तेमाल क्यों करें?

    • यह हँसने वाली बात नहीं है। Models पिछले महीने की तुलना में काफ़ी बेहतर हुए हैं और token cost भी घटी है। LLM दिमाग़ के लिए compiler जैसा है
      /s

  • AI से Rust ही क्यों लिखवाना? अगर सब कुछ vibe coding है और अब code review भी नहीं करना, तो LLM से ऐसी ultra-concise, ultra-dense language design करवा लो जो सिर्फ token usage को minimum रखने और speed के लिए बनाई गई हो
    इस comment के अंत में आंशिक रूप से ही सही, एक /s लगा हुआ है

    • code लिखने पर ही क्यों रुकना? हम सबको custom ASIC chips बनानी चाहिए, और अगर chip fab नहीं है तो कम से कम FPGA तो करना ही चाहिए

  • थोड़ा off-topic है, लेकिन समझ नहीं आता कि लोग अब भी Medium पर क्यों लिखते हैं
    reading experience भयानक है। Full-screen popups सचमुच उस sentence को ढक देते हैं जिसे आप पढ़ रहे होते हैं, इसलिए मैं यह लेख भी पूरा नहीं पढ़ सका
    क्या कोई ऐसा incentive है जो मुझे दिख नहीं रहा?

    • Browser में पढ़ी जाने वाली कोई भी चीज़ सबको एक जैसी, ultimate, शानदार reading experience नहीं दे सकती। Modern web model ही उससे टकराता है
      बिना CSS का साधारण HTML page लगभग perfect reading experience है। समस्या यह है कि लगभग कोई उसे उस तरह publish नहीं करता। Web ऐसा publishing platform बन चुका है जहाँ authors ध्यान के लिए compete करते हैं। User control वाले plain-text protocols “सबके लिए सबसे अच्छा reading experience” के ज़्यादा क़रीब हैं। Web भी ऐसा हो सकता था, लेकिन ज़्यादातर मामलों में ऐसा नहीं है
      मैंने browser में long-form text पढ़ने की कोशिश करना छोड़ दिया है। जब मैं आसानी से संबंधित plain text, यहाँ तक कि structured text भी निकालकर अपने editor में पढ़ सकता हूँ, तो browser में क्यों पढ़ूँ? Fonts, colors, navigation वगैरह पर मेरा control रहता है। Browser delivery mechanism है, reading environment नहीं। उसे वैसे इस्तेमाल करना आदत है, मजबूरी नहीं
      बहुत पहले से मैं तीन शब्दों से लंबी कोई भी चीज़ editor के बाहर लिखना बंद कर चुका हूँ। Spell check, thesaurus, etymology lookup, translation, मेरे सारे notes की access, LLM integration—जो चाहिए सब पहले से मौजूद है। कभी आज़माकर देखिए, बेहद मुक्त महसूस होगा। फिर browser में लंबा लेख पढ़ना भी छोड़ सकते हैं

    • Medium writers को पैसे देने की काफ़ी गंभीर कोशिश करता रहा है। इसका model Substack से अलग है, लेकिन वजह वही है
      मैं इसे अख़बार के paywall की तरह देखता हूँ। पसंद नहीं है, लेकिन यह क्यों मौजूद है, समझ आता है

    • सबसे plausible अंदाज़ा inertia है। कुछ लोग brand loyalty बहुत मज़बूती से निभाते हैं, और दूसरों के तरीके के अनुसार ही चलते हैं
      असल में कहाँ publish हुआ, यह मायने नहीं रखता; URL दे दो, वही काफ़ी है, लेकिन सब लोग ऐसे behave नहीं करते

    • यह writer-friendly blogging platform की नवीनतम evolution जैसा लगता है। WordPress की तुलना में newsletter format में बाँधना आसान है, और paid tiers से monetize करना भी आसान

    • Medium के alternative frontend Scribe का इस्तेमाल करें, काफ़ी बेहतर है:
      https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code...

      https://sr.ht/~edwardloveall/Scribe/
      https://libredirect.github.io/

  • Python का ecosystem Rust से कहीं ज़्यादा mature है, ख़ासकर AI/machine learning में
    मुझे एक Rust crate मिला जो दावा करता था कि वह एक ख़ास machine learning algorithm implement करता है, लेकिन वह ठीक से काम नहीं करता था। फिर भी Claude से उसका replacement implementation लिखवाया जा सकता था
    AI के साथ मुझे लगता है कि type system के स्तर पर correctness enforce करना अच्छा विचार है, इसलिए मैं Python की बजाय अक्सर C# या Rust जैसी languages चुनता हूँ। फिर भी कुछ कामों के लिए Python साफ़ तौर पर सही tool है

    • मैं लगभग हमेशा Rust चुनता हूँ। हाल ही में Go में लिखी किसी चीज़ के लिए plugin बनाया
      Rust इस्तेमाल कर सकता था, लेकिन लगा कि अगर नतीजा अच्छा हुआ तो दूसरे लोगों को एक ही toolchain इस्तेमाल करने से ज़्यादा value मिलेगी, इसलिए Go सही लगा
      मुख्य कारण यह है कि ज़रूरत पड़ने पर उसे पढ़ पाना चाहिए। और receiving ecosystem की अपनी expected language होती है। कुछ data science communities R, MatLab, Julia, Python, Mojo चुनती हैं, यह तकनीकी श्रेष्ठता से कम और peers क्या इस्तेमाल करते हैं, उससे ज़्यादा तय होता है
    • मेरे हिसाब से इसका एकमात्र उपयोग low-level C++ libraries, जैसे machine learning libraries, को wrap करना है। ऐसी चीज़ों को दोबारा बनाना सच में बहुत कठिन है
    • AI के साथ type system enforcement अच्छा होने के कुछ कारण हैं
      मेरा अंदाज़ा है कि typed languages के language servers अक्सर तेज़ और बेहतर होते हैं, इसलिए tool use के ज़रिए code को ज़्यादा कुशलता से बदला जा सकता है
      और जब इंसान को बीच में आकर code inspect या modify करना पड़े, तब strong typing की वजह से spaghetti code में रास्ता ढूँढना काफ़ी आसान हो जाता है
    • AI/machine learning library support के पक्ष में बात तो बनती है। फिर भी इन दिनों backend काम के लिए मैं अक्सर Rust/TypeScript की ओर जाता हूँ। Django बहुत पसंद होने के बावजूद
    • अगर Python ecosystem से बाहर जाना है और AI पर dependency management या polyfill छोड़ना है, तो Rust की बजाय सीधे OCaml/F# तक जाना बेहतर होगा
      तब आपको garbage collection और strong types—दोनों के फ़ायदे मिलेंगे

  • फ़िलहाल वजह वही है जो इंसान द्वारा सीधे लिखे जाने पर Python चुनने की होती है। Zig जैसी language की तुलना में Python जानने वाले लोग ज़्यादा हैं, इसलिए इंसानों के लिए code पढ़ना और modify करना आसान है
    लेख का point समझता हूँ, लेकिन अभी हम उस stage तक नहीं पहुँचे हैं

    • automation ऐसी languages में लिखी जाए जिन्हें इंसान समझ ही न सकें—यह दुनिया मुझे पूरी तरह अंधेरी Chinese automated factory जैसी लगती है। इंसान वहाँ भटके हुए और उलझे हुए हैं, लेकिन robots उसमें पूरी तरह सहज हैं

  • “ऐसी app जो टीम में कोई नहीं जानता उस language में ship हुई” — शानदार। बहुत दूर नहीं, हम पीछे मुड़कर इस चीज़ को देखेंगे

    • AI से पहले भी ऐसा होता था। 10 साल पहले किसी ने किसी random language में core tool लिख दिया था, और बाकी लोगों को उसे maintain करना पड़ा। फिर भी जैसे-तैसे हो गया
    • शायद यह दुनिया की इकलौती ऐसी चीज़ होगी जो उस Electron app से भी ज़्यादा डरावनी हो सकती है जिसे यह replace कर रही थी
    • बस 12–18 महीनों में नौकरी बदल लो। फिर यह किसी और की समस्या होगी

  • “Anthropic researcher Nicholas Carlini ने 16 parallel Claude agents को coordinate करके Rust में production C compiler लिखा” — यह सच नहीं है
    उस compiler ने gcc/clang की तुलना में बहुत घटिया code generate किया, इसलिए वह लगभग बेकार है