Rust से Ruby तक

• यह Rust web app crate को Ruby on Rails में ले जाने का एक व्यक्तिगत प्रोजेक्ट प्रयोग है, और लक्ष्य Tera व Axum आधारित 14,943 लाइनों का कोड है
• मौजूदा Rust सेटअप में Playwright E2E, अलग-थलग DB namespace, mocking services, और internal API crate तक की ज़रूरत पड़ती है, इसलिए testing cost काफ़ी अधिक है
• LLM तुलना में Rails का कुल स्कोर 710 रहा, जो Rust/Axum/Diesel के 480 से अधिक है, और development speed व unit testing की आसानियत इसकी मुख्य ताकत मानी गई
• Local Qwen3.6 के one-shot conversion में लगभग 30 मिनट लगे, और Ruby कोड 3,322 लाइनों तक सिमट गया, लेकिन अभी तक इसे चला कर verify नहीं किया गया है
• Rails की ताकत इसके built-in features और concise testing में है, जबकि Ruby में type safety की कमी को Sorbet या agent-आधारित type addition से कुछ हद तक पूरा किया जा सकता है

---

रूपांतरण प्रयोग की पृष्ठभूमि

• व्यक्तिगत प्रोजेक्ट के एक हिस्से, Rust web app crate, को Ruby on Rails migration के लिए चुना गया
  • पूरा प्रोजेक्ट लगभग 30,000 लाइनों का है, और migration के लिए चुना गया crate Tera और Axum से लिखे गए web app के काफ़ी क़रीब है
  • migration के दायरे वाला Rust कोड कुल 14,943 लाइनें है, और compile होने में लगभग 10 सेकंड लगते हैं
  • कोड खुद बहुत बड़ा नहीं है, लेकिन इसकी dependency structure काफ़ी भारी है
• मौजूदा Rust सेटअप में testing cost अधिक है
  • E2E testing के लिए Playwright configuration की ज़रूरत होती है
  • mocking आसान नहीं है, इसलिए isolated database namespace और mocking services चाहिए होते हैं
  • Playwright को headless mode में app के साथ interact कराने के लिए एक अलग internal API crate भी चाहिए
• Ruby और Ruby on Rails को एक अधिक concise विकल्प के रूप में देखा गया
  • Ruby में types नहीं हैं, इसलिए इसकी stability Rust से कम हो सकती है
  • Sorbet इस्तेमाल करने पर Ruby में भी type safety को कुछ हद तक बेहतर किया जा सकता है
• कई LLM instances से complexity, stability, testing ease जैसी चीज़ों की तुलना की गई, और Rails का स्कोर अधिक निकला
  • Rust/Axum/Diesel का कुल स्कोर 480, Rails का 710, और Rails + Sorbet का 695 निकाला गया
  • Rails को solo developer suitability 90, development speed 90, और unit testing ease 90 जैसे उच्च अंक मिले
  • Rust/Axum/Diesel को safety 95 और performance 95 जैसे ऊँचे अंक मिले, लेकिन unit testing ease 20 और integration testing ease 30 जैसे कम अंक मिले
  • साधारण कुल-योग के आधार पर यह निष्कर्ष निकाला गया कि Rails app 1.47 गुना बेहतर परिणाम दे सकती है

रूपांतरण के नतीजे और समीक्षा के बिंदु

• Local Qwen3.6 से अपेक्षाकृत छोटे प्रोजेक्ट का one-shot conversion किया गया
  • conversion में लगभग 30 मिनट लगे
  • इसे अभी तक चलाकर नहीं देखा गया है, इसलिए यह वास्तव में काम करता है या नहीं, इसकी पुष्टि नहीं हुई है
• सबसे बड़ा बदलाव code lines में कमी है
  • Rust files की कुल लाइनें: 14,943
  • Ruby files की कुल लाइनें: 3,322
  • लाइनों की संख्या 77% कम हुई, और Ruby की 1 लाइन लगभग Rust की 4.49 लाइनों के बराबर रही
• बदला हुआ Ruby code जितना देखा गया, उसमें साफ़ और idiomatic लगा
  • bug की संभावना अभी भी बनी हुई है
  • आगे इसे और बारीकी से review किया जाएगा
• आगे की समीक्षा के मुख्य बिंदु हैं type augmentation, Rails के built-in features, और testing simplification
  • agents की मदद से types जोड़े जाएँ तो type safety की समस्या कुछ कम की जा सकती है
  • Ruby/Rails को “batteries + kitchen sink included” के काफ़ी क़रीब माना गया, और इसे 3GiB आकार की compiled dependencies से बेहतर आंका गया
  • testing के काफ़ी आसान हो जाने की उम्मीद है
• Ruby testing का उदाहरण VCR.use_cassette("llm_call") के साथ LLM call को wrap करके result size verify करने वाला छोटा रूप है

    VCR.use_cassette("llm_call") do
      result = LlmClient.match(entry, data_list)
      expect(result.results.size).to eq(data_list.size)
    end
  

• Rust testing का उदाहरण इससे लंबा है, क्योंकि उसमें mocking provider को सीधे implement करना पड़ता है
  • इसमें Arc<RwLock<Vec<Response>>>, AtomicUsize, async_trait, tokio::test आदि का उपयोग होता है
  • response list और call count को संभालने वाला MockProvider बनाया जाता है, फिर Provider trait का match implement किया जाता है, और उसके बाद test में result व call count verify किए जाते हैं
• चूँकि यह एक व्यक्तिगत प्रोजेक्ट है, इसलिए अधिक साहसी चुनाव संभव हैं, और Rust से Ruby में migration को आगे भी क़रीब से परखा जाएगा

[GN⁺]

Hacker News की राय

• इस पर यकीन करना मुश्किल है। यह कुछ ऐसा लगता है: “एक तकनीकी खुजली थी जिसे मैं खुजलाना चाहता था, और local AI ने 30 मिनट में काम पूरा कर दिया। यह चल भी रहा है या नहीं, देखने के लिए मैंने Start भी नहीं दबाया, लेकिन ब्लॉग पोस्ट लिख दी…”

  • अभी पहले पेज पर नंबर 1 होने का मतलब है कि प्रोजेक्ट का सच में काम करना ज़रूरी भी नहीं है। पाठकों ने भी शायद लेख ठीक से नहीं पढ़ा होगा
    बशर्ते इसे bots ने ऊपर न धकेला हो
  • 2016: कृपया मेरी नई JavaScript library देखिए!
    2026: कृपया वह काम देखिए जो मैंने खुद किया ही नहीं!
    2036: मैंने C नाम की प्राचीन Latin भाषा में 200 लाइनें कैसे लिखीं
  • “यकीन करना मुश्किल” से ज़्यादा, 2026 के हिसाब से यह काफी सामान्य बात के करीब है
  • हाँ, 5 घंटे review तो किया था। इसलिए ¯\(ツ)/¯

• शुरुआत में लगा यह दिलचस्प लेख होगा, लेकिन जैसे ही देखा कि conversion के लिए LLM इस्तेमाल हुआ, मेरी दिलचस्पी तुरंत खत्म हो गई। यह कुछ वैसा है जैसे, “मैं यह करना चाहता था, इसलिए मैंने अपने अधीन काम करने वाले से करवा लिया, और अब मैं उसकी कहानी सुनाऊँगा।”
  न तो उसने conversion खुद किया और न ही उस पर गहराई से सोचा, तो इसे पढ़ने की खास वजह नहीं दिखती

  • सबसे बड़ी समस्या यह है कि लेखक ने validation तक नहीं किया। मैंने कई बार देखा है कि models के मिश्रण वाले बड़े tools 6 घंटे तक conversion चलाने के बाद, अगर आप हाथ से देखें कि उन्होंने tricky calculation या logic को कैसे handle किया, तो अंदर stub या hardcoded true return मिल जाता है
    इसलिए सिर्फ smoke test चलाने पर यह सफल भी लग सकता है
  • इससे भी बड़ी समस्या यह है कि आगे software development शायद इसी दिशा में जाएगा
    craftsmanship वाले programming को छोड़ दें, तो programming language खुद उतनी महत्वपूर्ण नहीं रह जाएगी
    जैसे-जैसे LLM बेहतर होंगे, बात आखिरकार इस पर आ जाएगी कि specification किस तरह की language में generate करनी है
    मानो UML और RUP camp ने आखिर बदला ले लिया हो
  • मुद्दा यह नहीं है कि कोड खुद लिखा या नहीं, बल्कि यह है कि differences देखकर शायद ideal न होने वाले कुछ choices किए गए
    जैसा दूसरे comments में भी कहा गया, इस पर काफी व्यापक review हुआ था। यह कोई बहुत बड़ा project नहीं है, और कुछ मुश्किल हिस्सों को छोड़ दें तो ज़्यादातर एक web app ही है
    “सोचा ही नहीं” कहना मुझे अनुचित लगता है। यह सिर्फ button दबाकर YOLO कर देने जैसा नहीं था
    trade-offs और नतीजों की जांच की गई, Rust code fragments और Rails के बीच फर्क सच में बड़ा था, और Rust app की testability ऐसा विषय था जिस पर 2 महीने तक सोचा गया था
    जैसा LLM enthusiasts कहते हैं, context matters ;)

• मुझे नहीं पता कि कोई और language या framework Ruby on Rails जितनी developer happiness को प्राथमिकता देता है या नहीं

  • Rails project पर काम करते समय जितना दुखी हुआ हूँ, उतना शायद ही कभी हुआ हूँ। साइट पर bug मिला, गलत render हो रही view ढूँढ़ने के लिए grep चलाया। उस section को render करने वाले method call तक पहुँचा, फिर method name से grep किया तो 0 results मिले
    कुछ कहीं पर compose हो रहा था, पता ही नहीं चल रहा था कि कहाँ है, और आखिरकार मुझे अपना काम रोककर एक घंटे तक documentation पढ़नी पड़ी। जो लोग पूरे दिन Rails ही इस्तेमाल करते हैं, उनके लिए यह ठीक हो सकता है, लेकिन convention over configuration मेरे लिए एक बहुत बड़ा anti-pattern है
  • Elixir और Phoenix में भी थोड़ा ऐसा ही लगता है, लेकिन वहाँ method_missing जैसा अपने ही पैर पर कुल्हाड़ी मारने वाला तंत्र नहीं है
  • भले ही यह Silicon Valley taste वाली community में आकर्षक न लगे, लेकिन Java और .NET frameworks के साथ भी मैंने काफी संतोषजनक काम किया है
    happiness हमेशा performance में नहीं बदलती। Twitter के JVM और Scala पर जाने से पहले वाले मशहूर whale logo का उदाहरण याद आता है
    Ruby on Rails ने नाम कमाया, लेकिन इससे पहले Tcl-आधारित AOLServer और Vignette में भी ऐसा ही अनुभव था
    एक Portuguese startup में उन्होंने इसका अपना variant बनाया था, और बाद में संस्थापकों ने OutSystems बनाया
    यह websites और distributed systems development के लिए शुरुआती graphical RAD tools में से एक था, और low-code/no-code तरीके से JVM या CLR infrastructure को target करता था
    फिर भी अब CRuby में default JIT आता देखना अच्छा लगता है
  • ज़्यादा से ज़्यादा यह short-term happiness है, और इसकी कीमत maintainability, performance, reliability, scalability जैसी बाकी सभी architectural characteristics से चुकानी पड़ती है

• मैंने propel_rails नाम का एक gem bundle बनाया है, जो पहले से concise Ruby on Rails code को और भी चरम तक ले जाता है। यह API controllers और concerns जैसे top-level classes बनाता है, और वहाँ से पूरे RESTful resources (models, controllers, serializers, unit tests और E2E tests) बिना boilerplate के तैयार कर देता है
  आखिर में controller में सिर्फ API द्वारा allow की गई properties की list रहती है, क्योंकि RESTful actions अपने-आप generate हो जाते हैं। इसे पूरी तरह समझाना थोड़ा मुश्किल है, लेकिन Ruby की metaprogramming ताकत वाकई कमाल की चीज़ों को आसान बना देती है

  • यह CRUD के एक refined रूप जैसा लग रहा है
    क्या यह domain model के आधार पर काम करता है?
  • rubygems पर तो मिल रहा है, लेकिन वहाँ से जुड़ा GitHub link 404 दे रहा है

• मैं भी लगभग ऐसी ही स्थिति में हूँ
  मुझे Go और Rust दोनों पसंद हैं, और दोनों ही अपनी खूबियों और कमियों के साथ शानदार languages हैं। लेकिन अफसोस, मैं इनमें से किसी में भी SaaS app नहीं बना पाया। जैसे चौकोर खूंटी को गोल छेद में फिट करने की कोशिश हो
  हो सकता है मैं पूरी तरह गलत हूँ, लेकिन SaaS tools के साथ बहुत सारा built-in सामान आता है, और मैं उसे फिर से invent नहीं करना चाहता
  RoR “काफी अच्छा” है। जब चाहें types ला सकते हैं, तेज़ी से बना सकते हैं, और tooling भी ठीक-ठाक है
  मेरा पहला पेशेवर काम PHP में था, और उसमें pitfalls बहुत थे। Ruby थोड़ी ज़्यादा e-commerce की तरफ झुकी हुई लगती है, जो मुझे दिलचस्प लगा, और अगर यह Shopify के लिए काफी है, तो मेरे लिए भी ठीक है

• अगर Rust से Ruby पर जाना समझदारी लगता है, तो शुरुआत में Rust चुनना ही गलती थी

  • यह इस लेख का बहुत अच्छा सार है, और यही वजह है कि मैंने इसे साझा करने का फैसला किया

• जो लोग सोचते हैं कि Ruby, Rust से धीमी है, वे यह जानकर हैरान हो सकते हैं कि Ruby अब असल में Python से तेज़ है, जबकि Go या Rust से धीमी है

  • आम तौर पर speed से ज़्यादा memory usage महत्वपूर्ण रहा है। ज़्यादातर Ruby applications की speed Ruby नहीं, बल्कि database सीमित करता है
    लेकिन जब कई background workers हों और हर एक 2GB से ज़्यादा memory खाने लगे, तो यह बहुत जल्दी जुड़ता जाता है
    मैंने production में एक Rust service लिखी थी, और speed से भी ज़्यादा प्रभावशाली बात यह थी कि वह 30MB memory में चल रही थी
  • अगर कोई पहले से मानता है कि Ruby, Rust से धीमी है, तो उसे यह जानकर हैरानी क्यों होनी चाहिए कि Ruby Python से तेज़ है? इन दोनों बातों का आपस में क्या संबंध है?

• यह उकसाने वाली बात है, लेकिन अपने आसपास के आम लोगों को 900+ IQ दिखाने के लिए भले अच्छी हो, बहुत से बुद्धिमान और प्रतिभाशाली developers को Rust खास पसंद नहीं है। कुछ लोग Rust की एक लाइन लिखने के बजाय अपनी programming language और compiler खुद बनाना पसंद करेंगे
  Jonathan Blow के Jai और Ginger Bill के Odin याद आते हैं
  ऐसे और भी लोग हैं जिनकी creativity और depth साबित हो चुकी है, जिन्होंने खूबसूरत और व्यापक रूप से इस्तेमाल होने वाली libraries और frameworks बनाए हैं, लेकिन यहाँ जगह बर्बाद नहीं करना चाहता
  बस इतना कि Rust का एक शानदार macho club और बेहद जुड़ी हुई brotherhood ज़रूर है

  • Rust community “macho club” से जितना संभव हो उतनी दूर है

• Claude, Rails apps पर वाकई बहुत अच्छा काम करता है। जैसा इस लेख के लेखक ने भी कहा, Ruby कम code में बहुत कुछ करा देती है, और Rails convention over configuration अपनाता है, इसलिए Rails apps और भी concise हो जाते हैं
  Claude के Rails apps पर अच्छा काम करने की एक परिकल्पना token efficiency है
  मैंने पहले एक project देखा था जो अलग-अलग projects की token efficiency मापकर compare करने की कोशिश करता है, और Rails ने वहाँ काफी अच्छे results दिखाए
  https://felipemrvieira.github.io/SyntaxTax/dashboard/

• कभी-कभी project का आकार देखकर मैं हैरान हो जाता हूँ। 30,000 lines का codebase छोटा है? मुझे पता है ceiling काफी ऊँची होती है, लेकिन 30,000 lines में बहुत सारी जानकारी और व्यवहार की बारीकियाँ समा सकती हैं
  शायद यह मेरे background की वजह से भी है, जहाँ मेरा फोकस Go वाले backend/networking काम पर रहा है। 10,000 से 15,000 lines पार होते ही आम तौर पर पूरे codebase का model दिमाग में बनाए रखना मुश्किल हो जाता था, और वह काफी भारी लगने लगता था

  • यह काफी हद तक इस पर निर्भर करता है कि आप क्या बना रहे हैं। कई frontends वाला SaaS app आसानी से 30,000 lines तक पहुँच सकता है