- Ruby सबसे तेज़ या सबसे ट्रेंडी भाषा नहीं है, लेकिन 15 साल से ज़्यादा समय में कई भाषाओं से गुज़रने के बाद भी जब काम का आनंद लेना हो, तो यह फिर चुनी जाने वाली भाषा बनी रहती है
- refinements, Forwardable, SimpleDelegator,
Object#then, Kernel#tap, और numbered parameters छोटे syntax convenience और पढ़ने में आसान flow देते हैं
- standard library के
Thread::Queue, json, csv और RuboCop, Ruby LSP छोटे gem और जटिल configuration के बिना भी एक व्यावहारिक development environment बनाए रखने में मदद करते हैं
- Ruby 3.x का YJIT और 4.x का ZJIT CPU-intensive कामों में अंतर कम कर रहे हैं, और एक सरल Fibonacci तुलना में Ruby with ZJIT, Go से 2~3 गुना के भीतर था
- Rust·Go·Python के लिए अधिक उपयुक्त क्षेत्र भी हैं, लेकिन web app, background processing, और internal tools में developer happiness और तेज़ iteration speed Ruby की ताकत बने हुए हैं
Ruby के सहज लगने के भाषाई कारण
- Ruby सबसे तेज़ या सबसे ट्रेंडी भाषा नहीं है, लेकिन 15 साल से ज़्यादा समय तक कई भाषाओं के बीच आने-जाने के बाद भी, जब सच में काम का आनंद लेना हो, तो यह फिर से चुनी जाने वाली भाषा बनी रहती है
- refinements सीमित scope में ही class को खोलने देते हैं, जिससे पूरे namespace को दूषित किए बिना किसी file या block के अंदर छोटे syntax convenience जोड़े जा सकते हैं
- यह test helper या बड़े codebase के internal DSL के लिए अच्छी तरह फिट बैठता है
using QuotingRefinement को जहाँ call किया गया है, केवल वहीं "hello".quote जैसे method इस्तेमाल किए जा सकते हैं
- standard library के Forwardable और
SimpleDelegator साफ delegation संभव बनाते हैं, बिना wrapper method हाथ से लिखे या अतिरिक्त gem खींचे
- अगर आप पहले से Rails इस्तेमाल कर रहे हैं, तो Active Support का
delegate ज़्यादा सुविधाजनक हो सकता है, लेकिन core Ruby version सामान्य scripts को हल्का रखता है
Object#then और Kernel#tap बीच के variables बनाए बिना operations को ऊपर से नीचे पढ़े जाने वाले chain में जोड़ने देते हैं
User.new(params).tap { ... }.then { ... }.save की तरह creation, logging, normalization, और save flow को एक साथ लिखा जा सकता है
- Ruby 2.7 के बाद के numbered parameters छोटे callback में अनावश्यक शोर कम करते हैं
items.map { _1.price * 1.1 } की तरह block arguments को अलग से घोषित करने की ज़रूरत नहीं होती
- fiber scheduler event loop जोड़ने पर ऐसा concurrent code लिखने देता है जो sequential code जैसा दिखता है
Fiber.schedule do ... end के रूप में दूसरे fiber के साथ सहयोग करने वाला code व्यक्त किया जा सकता है
tools, performance, और ecosystem की मौजूदा स्थिति
- Shopify का Ruby LSP बहुत कम configuration के साथ editor integration देता है, और gradual typing के लिए Steep या RBS के साथ अच्छी तरह काम करता है
- RuboCop दूसरे ecosystem में दिखने वाली औपचारिक प्रक्रियाओं के बिना भी style को consistent बनाए रखता है
- standard library आम कामों के लिए कई छोटे gem जोड़ने की ज़रूरत कम कर देने वाली एक शांत ताकत बनी हुई है
- अगर queue चाहिए, तो
Thread::Queue इस्तेमाल किया जा सकता है
- JSON या CSV parsing के लिए
json और csv library ज़्यादातर वास्तविक use case को बिना बड़े झंझट के संभाल लेती हैं
- Ruby 3.x के YJIT के बाद 4.x series में ZJIT आ रहा है
- ZJIT उसी आधार पर काम करने वाला अधिक aggressive JIT है, जो ज़्यादा hot execution path को प्रभावी ढंग से compile करता है
- शुरुआती आँकड़ों में CPU-intensive कामों में Ruby और उससे बड़ा अंतर दिखाने वाली भाषाओं के बीच की दूरी अर्थपूर्ण रूप से कम हुई है
- CRuby ZJIT Ruby के main repository में विकसित किया जा रहा है
- उसी मशीन पर recursive Fibonacci implementation की तुलना करने वाले एक सरल benchmark में Ruby with ZJIT Go से 2~3 गुना के भीतर था, और उस मामले में optimized Rust से भी बहुत पीछे नहीं था, जबकि Python with pypy पीछे रह गया
- microbenchmark की सीमाएँ होती हैं, लेकिन जिन warm code path पर JIT को optimize करने का समय मिलता है, वहाँ वास्तविक application को और बड़ा लाभ मिल सकता है
- Rust की तुलना में Ruby की ताकत business logic की iteration speed में है
- Rust में ऐसी चीज़ों पर भी समय लग सकता है जो runtime पर स्पष्ट हों, क्योंकि borrow checker से जूझना पड़ता है
- Go के concurrency primitives शानदार हैं, लेकिन हाल तक उसमें generics नहीं थे, और कुछ हद तक कठोर error handling के कारण साधारण script भी ज़रूरत से ज़्यादा भारी लग सकती है
- Python इसका सबसे निकट मानसिक चचेरा भाई है, लेकिन खासकर class और decorator के आसपास, वही high-level ideas व्यक्त करने के लिए उसमें अधिक boilerplate चाहिए
- model में code डालते समय token efficiency भी Ruby का एक वास्तविक लाभ बनती है
do/end या braces से block व्यक्त किए जा सकते हैं, और जहाँ readability अनुमति देती है वहाँ method call में parentheses की शायद ही ज़रूरत पड़ती है- hash और keyword arguments first-class features हैं और संक्षिप्त भी, इसलिए अधिक structural noise वाली भाषाओं की तुलना में एक ही context window में अधिक वास्तविक logic रखा जा सकता है
- Ruby की metaprogramming utilities छोटे और पढ़ने में आसान API बनाने के लिए उपयुक्त हैं
define_method, class_eval, और missing method interception जैसी सुविधाओं से code generation चरण के बिना expressive API बनाए जा सकते हैंdry-rb या aasm जैसी libraries इन सुविधाओं का संयमित उपयोग करके साफ state machine और validation layers देती हैं
- community tools और deployment flow भी परिपक्व हो चुके हैं
- byebug और
pry कई अन्य जगह इस्तेमाल किए गए debugger की तुलना में अधिक लचीले लगते हैं
- background jobs में
solid_queue और good_job इतने सरल हैं कि पूरी implementation को एक दोपहर में समझा जा सके
- Kamal ने बहुत से लोगों के लिए पुराने capistrano-शैली के process की जगह ले ली है, और यह सच में छोटे team चलाने वालों द्वारा बनाया गया tool लगता है
- इसका मतलब यह नहीं कि Ruby हर काम में Rust या Go को हरा देता है; ऐसे क्षेत्र भी हैं जहाँ Rust या Go ज़्यादा उपयुक्त हैं
- web applications, background processing, और internal tools के इस बड़े मध्य क्षेत्र में Ruby बिना अत्यधिक औपचारिकता या बार-बार context switching के लगातार developer happiness देता है
- छोटी-छोटी सुविधाएँ और भाषा का समग्र अहसास 10 साल से ज़्यादा समय बाद भी इसे पहली पसंद बनाने वाले तत्व बने हुए हैं, और नए JIT कार्य तथा लगातार भाषा सुधार इस कारण को और मज़बूत करते हैं
3 टिप्पणियां
मुझे Ruby पसंद है और मैंने इसका काफी इस्तेमाल भी किया है, लेकिन अब खास तौर पर इसे इस्तेमाल करने की कोई वजह नहीं मिलती।
Ruby दुनिया भर में काफ़ी इस्तेमाल होती है, लेकिन कोरिया में यह खास तौर पर ज़्यादा इस्तेमाल नहीं होती, यह मुझे दिलचस्प लगता है।
Lobste.rs की राय
“no ceremony RuboCop” वाली अभिव्यक्ति से सहमत होना मुश्किल है
RuboCop में कौन-से cop चुनने हैं और उन्हें कैसे tweak करना है, और हाल की updates में जुड़े नए cop चालू करने हैं या नहीं, इस पर काफ़ी चर्चा करनी पड़ती है
StandardRB कहीं ज़्यादा बिना औपचारिकता वाला approach लगता है, लेकिन आख़िर में उसमें भी एक विकल्प चुनना ही पड़ता है
जिन भाषाओं में linting language में built-in होती है, वे Ruby की तुलना में काफ़ी कम झंझट वाली होती हैं, और छोटे-मोटे style विवाद भी कम होते हैं
पाबंदियाँ उल्टा आज़ादी देती हैं
मैं आम तौर पर linter configuration के ख़िलाफ़ हूँ, और चाहता हूँ कि ऐसे फ़ैसले community defaults पर छोड़ दिए जाएँ
एक तरफ़ लगता है RuboCop के defaults काफ़ी अच्छे हैं, इसलिए coding style को और टुकड़ों में बाँटने के बजाय उन्हें मानना और साथ मिलकर evolve करना बेहतर है
दूसरी तरफ़ कभी-कभी यह बहुत ज़्यादा opinionated लगने लगता है, इसलिए standard.rb जैसी चीज़ की ज़रूरत महसूस होती है
मैंने यह बात इस नज़रिए से लिखी थी कि जो लोग Ruby सीख रहे हैं या वापस आ रहे हैं, उन्हें आराम से code लिखने के लिए ढेर सारे gem से नहीं जूझना पड़े
जब Go आया था, तब उसका एक आधिकारिक formatting system देना मुझे सच में बहुत अच्छा फ़ैसला लगा था
दिमाग़ pattern-matching machine है, इसलिए एक बार आदत पड़ जाए तो चीज़ें बस चलती रहती हैं, लेकिन options हों तो असहजता होती है और सब लोग अलग-अलग दिशाओं में खिंचने लगते हैं
समस्या यह है कि Ruby में न RuboCop और न ही Standard उस तरह की authority पा सकते हैं
वह authority core team से आनी चाहिए, लेकिन Ruby की philosophy के ख़िलाफ़ होने की वजह से शायद ऐसा कभी नहीं होगा
अपने projects में मैं RuboCop के सारे cop बंद कर देता हूँ और सिर्फ़ कुछ चुनिंदा चालू रखता हूँ
single quotes सबसे बेहतरीन हैं 😀
लगता है दूसरे लेख में भी यही बात उठाई गई है: https://caio.ca/blog/coding/my-complicated-relationship - “The Wild West of Code Formatting”
मतलब कुछ ऐसा कि “यह कोई simple built-in solution नहीं है। इसमें सैकड़ों configurable cop हैं, और कौन-से rules चालू हों इस पर अंतहीन बहस चलती रहती है”
कुल मिलाकर सहमत हूँ, लेकिन refinements को पहला example बनाना थोड़ा अफ़सोसजनक है
मुझे समझ आता है कि यह क्यों पसंद आ सकता है, लेकिन यह ज़्यादा उस तरह की चीज़ है जिसे बेहतर है कि आप सॉसेज कैसे बनती है, यह न जानें
इसकी semantics इतनी पेचीदा हैं कि आए 10 साल से ज़्यादा हो चुके हैं, फिर भी MRI में इससे जुड़े परेशान करने वाले bugs मिलते रहते हैं
उदाहरण के लिए, पिछले 2 हफ़्तों में भी https://bugs.ruby-lang.org/issues/22071 और https://bugs.ruby-lang.org/issues/22058 आए थे
performance के लिहाज़ से भी यह बहुत-सी optimizations को मुश्किल बना देता है, और अभी boxes में भी कुछ ऐसा ही फिर हो रहा है
implementation level पर भी शायद अभी बहुत-से छिपे bugs होंगे, और libraries की तरफ़ भी यही बात होगी
अब मैं Ruby ज़्यादा इस्तेमाल नहीं करता, लेकिन यह कैसे settle होगा, इसे लेकर जिज्ञासा है
दिलचस्प लग रहा है
यह लेख मेरे “Returning to Rails” लेख[1] के अनुभवों से भी काफ़ी मेल खाता है
हो सकता है यह confirmation bias हो, लेकिन ऐसा लगता है कि Rails code की ख़ूबसूरती को फिर से खोजने या नए सिरे से सराहने वाले लोग बढ़ रहे हैं
लेकिन इससे संगीत या कला की पसंद के देर-teenage से 20s में स्थिर हो जाने वाली बात भी याद आती है
शायद जिन लोगों ने Rails के “golden age” में पहली बार Ruby को जाना, वे Rails 3 और Capistrano वाले दिनों को rose-tinted glasses से देख रहे हैं
उस समय मैं Ruby “shop” में बहुत गहराई तक था और आसपास भी सब Rails developers ही थे, इसलिए लगता था Ruby हर जगह है
लेकिन lobste.rs thread[2] में यह राय देखकर कि Ruby असल में हमेशा काफ़ी niche language रही है, लगा कि उसका असर भी रहा होगा
फिर भी Ruby अब भी घर जैसी लगती है, और ऐसा लगता है कि यह मेरे दिमाग़ के काम करने के तरीक़े के साथ ही चलती है
इसमें लगभग कोई translation step नहीं है, चौंकाने वाली बातें नहीं हैं, और यह किसी औपचारिक शोध-पत्र से ज़्यादा किसी दोस्त से बातचीत जैसा लगता है
अभी तक मुझे ऐसी fit बैठने वाली दूसरी language नहीं मिली, और मुझे नहीं लगता कि यह सब सिर्फ़ “आजकल के बच्चे” वाली सोच है
जो भी हो, इसका इतने लंबे समय तक टिका रहना खुशी की बात है
और “tap / new” chain दिखाने के लिए धन्यवाद
वह structure इतना सुंदर और उपयोगी लगा कि मैं वहीं रुक गया, और अब इसे ज़रूर आज़माऊँगा
PS - यह सीधे topic से जुड़ा नहीं है, लेकिन homepage का AI avatar थोड़ा डरावना है
वह बहुत ज़ोर से “क्या यह लेख bot ने लिखा है?” वाली uncanny valley feeling देता है
हर बार ऐसा कुछ देखकर मैं एक पल के लिए सोचने लगता हूँ कि क्या मैं किसी असली इंसान से बात कर रहा हूँ
[1]=https://www.markround.com/blog/2026/03/05/returning-to-rails-in-2026/
[2]=https://lobste.rs/s/jreqtw/returning_rails_2026
बस मैं अपनी असली फोटो public नहीं करना चाहता, और वह avatar इतना मिलता-जुलता है कि जो लोग मुझे सच में जानते हैं वे पहचान लें
Ruby 3.4 में
itblock parameter जोड़ा गया है, जिसे example के_1की जगह इस्तेमाल किया जा सकता हैhttps://rubyreferences.github.io/rubychanges/3.4.html/…
itका ज़िक्र करना भूल गया थाशायद यह काफ़ी नया feature है, इसलिए iterators में
itटाइप करने की आदत हाथ में बिल्कुल नहीं बैठ रहीमुझे Ruby में code लिखना सच में बहुत पसंद था, लेकिन testing burden बहुत ज़्यादा हो गया
लगा था कि language में थोड़ी और type safety जोड़ने से मदद मिलेगी, लेकिन
#{last_job}में codebase में Sorbet डालने के बाद code लिखने की रफ़्तार और मज़ा पूरी तरह मर गयायह शायद अलोकप्रिय राय हो, लेकिन मुझे लगता है कि Sorbet जैसी चीज़ का होना ही Ruby के लिए एक bad smell के ज़्यादा क़रीब है
Ruby ख़ुद एक शक्तिशाली और मज़ेदार language है, लेकिन लोग उसे उन कामों में इस्तेमाल करने लगे जिनके लिए वह मूल रूप से design नहीं की गई थी, और उस प्रक्रिया में language की anti-features को ढकने के लिए tools ऊपर से जोड़ते गए
अब हर line उबाऊ मेहनत जैसी लगती थी, और असली code लिखने से ज़्यादा समय तरह-तरह के build, test, और lint tools का इंतज़ार करने में जाता था
ऊपर से over-engineered build और deployment process जुड़ जाएँ तो बुनियादी काम भी बहुत समय लेते हैं और काम तकलीफ़देह हो जाता है
लगभग 2012 के आसपास की Ruby दुनिया बहुत याद आती है
पीछे मुड़कर देखूँ तो वह सच में बहुत अच्छा समय था
मैंने “जिन कामों के लिए वह design नहीं की गई थी” का मतलब बड़े Rails applications समझा था
10 साल बाद Ruby में लौटा हूँ, और “AI” युग में यह उपयोगी है कि आप सामने से गुज़रते code को सच में समझ सकते हैं और LLM को steer या रोक सकते हैं
ज़्यादा verbose languages में यह और मुश्किल हो जाता है
मुझे Ruby की याद आती है, और उससे भी ज़्यादा इस बात की कि रोज़मर्रा के production में ऐसी language संभव थी
वह उम्मीद थी, बल्कि उम्मीद ख़ुद थी
कम से कम मेरे लिए तो लंबे समय तक ऐसा ही था
यह AI द्वारा जल्दबाज़ी में बनाए गए लेख जैसा पढ़ता है
हाल के दूसरे blog posts भी ऐसे ही लगते हैं
आपको कौन-से संकेतों से ऐसा लगा?
इस site पर AI-generated low-quality posts को चिन्हित करना अच्छी बात है, लेकिन false positives से बचने के लिए यह साफ़-साफ़ बताना ज़रूरी है कि ऐसा क्यों लगा
आपको ऐसा क्यों लगा?
ऐसी चेतावनियाँ देना अच्छी बात है, लेकिन मैं बहुत ज़्यादा पसंद करूँगा कि उसके साथ कारण भी बताए जाएँ
करियर की शुरुआत में Ruby के साथ काम करने की मेरी यादें अच्छी हैं
Ruby में सच में कुछ बहुत सुखद है
लेकिन शायद पिछले साल जब मैंने हाल की Ruby थोड़ी इस्तेमाल की, तो web-based standard library docs को navigate करना मुश्किल लगा
क्या यह सिर्फ़ मेरे साथ है? ruby-lang.org docs का कोई alternative है?
[1] https://rubyapi.org
[2] https://devdocs.io/ruby/
यह लेख थोड़ा अजीब लगता है
मुझे Ruby में एक project और एक SDK लिखने का मौका मिला था, लेकिन उसके बाद दोबारा Ruby इस्तेमाल करने का मन बिल्कुल नहीं हुआ