Bun के प्रयोगात्मक Rust पुनर्लेखन ने Linux x64 glibc पर 99.8% टेस्ट संगतता हासिल की

• Bun का Rust पुनर्लेखन Linux x64 glibc वातावरण में मौजूदा टेस्ट सूट का 99.8% पास कर चुका है
• कोडबेस “मूल रूप से वही कोडबेस” है, और Rust में जाने से compiler type lifecycle को enforce करता है तथा ज़रूरत के समय destructors का उपयोग संभव बनाता है
• असुरक्षित हिस्से Rust के unsafe के रूप में अधिक स्पष्ट दिखते हैं, जिससे refactoring को बढ़ावा मिलता है
• पुनर्लेखन का कारण यह था कि memory leak, crash और stability समस्याओं की चिंता करने और उन्हें ठीक करने में बहुत समय लगने से थकान हो गई थी, और ऐसी समस्याओं को रोकने के लिए भाषा से अधिक मज़बूत tools चाहिए थे
• कुल पैमाना 960,000 LOC के पुनर्लेखन के रूप में बताया गया, और Linux पर टेस्ट सूट पास करते हुए अन्य platforms को भी जल्द लक्ष्य बनाया जाएगा

---

Rust पुनर्लेखन की स्थिति

• Bun का Rust पुनर्लेखन Linux x64 glibc वातावरण में मौजूदा टेस्ट सूट का 99.8% पास कर चुका है
• कोडबेस “मूल रूप से वही कोडबेस” है, और Rust में बदलने पर compiler types के lifecycle को enforce करता है तथा ज़रूरी समय पर destructors का उपयोग करने देता है
• असुरक्षित हिस्से Rust में unsafe के रूप में और अधिक स्पष्ट दिखाई देते हैं, जिससे refactoring को बढ़ावा मिलता है
• पुनर्लेखन के पीछे यह कारण था कि memory leak, crash और stability समस्याओं की चिंता करने और उन्हें ठीक करने में बहुत समय खर्च करने से थकान हो गई थी, और ऐसी समस्याओं को रोकने के लिए भाषा से अधिक शक्तिशाली tools चाहिए थे
• कुल पैमाना 960,000 LOC के पुनर्लेखन के रूप में बताया गया, और कोड वास्तव में काम कर रहा है, Linux पर टेस्ट सूट पास कर रहा है, और अन्य platforms भी जल्द लक्ष्य होंगे

आगे प्रकाशित होने वाली बातें और build से जुड़े जवाब

• Bun के लिए इसका अर्थ, benchmarks, memory usage, भविष्य की maintainability, और वास्तविक पुनर्लेखन प्रक्रिया पर अलग ब्लॉग पोस्ट में चर्चा की जाएगी
• पुनर्लेखन प्रक्रिया केवल “claude, rewrite bun in rust. make no mistakes” कह देने भर की नहीं थी, और अंत तक काम करने वाली स्थिति तक पहुँचने का काम 6 दिन पहले शुरू हुआ था
• इसे हाथ से किया जाता तो काम की मात्रा बहुत विशाल होती
• compile time तेज़ Zig compiler का उपयोग करने वाले मौजूदा Zig version के साथ मूल रूप से समान है, और कहा गया कि यदि upstream Zig compiler का उपयोग किया गया होता तो Rust port और तेज़ compile हुआ होता
• performance पर अलग ब्लॉग पोस्ट में चर्चा की जाएगी
• libc को ही उसके Rust version frankenlibc से बदलने वाले अगले चरण के बारे में, उससे पहले स्वयं libc बनाने की बात कही गई

[GN⁺]

Hacker News की टिप्पणियाँ

• 4 दिन पहले भी इस बारे में एक पोस्ट थी: https://news.ycombinator.com/item?id=48019226
  Bun के एक डेवलपर ने कहा था कि यह उसकी अपनी branch है, उस समय वाला thread अभी काम न करने वाले कोड पर ओवररिएक्शन था, अभी rewrite को लेकर कुछ तय नहीं हुआ था, और यह भी काफी संभव था कि पूरा कोड फेंक दिया जाए
  वह देखना चाहता था कि काम करने वाला version कैसा दिखता है, performance और maintainability कैसी है, और Bun test suite पास कराना कितना मुश्किल है, ताकि Rust version और Zig version की साथ-साथ तुलना की जा सके

  • जब उसने वह संदेश लिखा था, तब cargo check में 16,000 से ज़्यादा compiler errors आ रहे थे, और न तो version number प्रिंट हो रहा था, न JavaScript चल पा रहा था
    यह इतनी जल्दी काम करने लगेगा, या performance इतनी competitive होगी, यह उसने भी नहीं सोचा था; विस्तार से एक blog post आने वाली है
  • लगता है उन्होंने maintainability, performance, और test suite checks देखकर फैसला लिया है
  • अगर ऐसा है, तो अब तक यह एक experiment के रूप में बहुत सफल रहा है
  • कुछ दिन पहले उसने यह भी कहा था: “open source शायद उलटी दिशा में जाएगा। मानव योगदान निषिद्ध। slop 2025~2026 की nostalgia भरी विरासत बन जाएगा”
    Anthropic द्वारा अधिग्रहण के बाद यह उम्मीद करनी चाहिए थी, फिर भी निराशाजनक है। मैं large language model तकनीक के अपने-आप में खिलाफ नहीं हूँ, लेकिन जिस तरह ये “AI” कंपनियाँ software industry और पूरे समाज को निगलते हुए ताकत हासिल कर रही हैं, वह घिनौना है, और बहुत अस्वस्थ निर्भरता पैदा कर रहा है
    हमें कुछ कदम आगे सोचकर slop-मुक्त software stack और community की तैयारी करनी चाहिए। इसमें Zig और उसका ecosystem भी शामिल है। भले हम और आने वाली पीढ़ियाँ पूरी तरह slop के बिना न रह सकें, लेकिन freedom as in liberty वाली टिकाऊ computing culture को सुनिश्चित करना पहले से कहीं ज़्यादा ज़रूरी है

• यह इतनी जल्दी हो गया, यह बहुत प्रभावशाली है। मैं भी कुछ ऐसा ही TypeScript को Rust में port करने वाला प्रोजेक्ट 5 महीने से कर रहा हूँ, लेकिन मेरे पास Mythos और unlimited token access नहीं है
  फिर भी मैं लगभग 100% pass rate के करीब पहुँच गया हूँ, और लिखते समय यह 99.6% है: https://tsz.dev
  Rust, large language model से code लिखवाने के लिए बहुत उपयुक्त है। इसकी strict type system की वजह से दूसरी भाषाओं में होने वाली बहुत बेवकूफाना गलतियाँ कम हो जाती हैं
  लेकिन सिर्फ large language model से code लिखवाने से वह design vision और trade-off judgment खत्म नहीं हो जाती जो किसी project को बनाने में चाहिए। इसी वजह से Jarred और उनकी team ऐसे लोग हैं जो large language model से बहुत बड़ी मात्रा में code का सही इस्तेमाल कर सकते हैं

  • Rust में compile time पर invariant enforcement, large language model को तेज feedback देकर पीछे लौटने का मौका देता है, इसलिए working code बनाना आसान होता है
    लेकिन Rust एक complex language भी है, इसलिए छोटे बदलाव भी दूर-दराज़ के code में refactoring avalanche ला सकते हैं। अगर शुरुआती architecture खराब या अधूरा हो, तो large language model के आम incremental तरीके से codebase बढ़ाने पर उसके spaghetti बन जाने का जोखिम काफी बढ़ जाता है
    अंत में डर यह रहता है कि कहीं ऐसा program न बन जाए जो compile भी हो और run भी करे, लेकिन इंसान उसके code को पढ़ या maintain न कर सके
  • इसी तरह मैं multithreaded Postgres पर भी काम कर रहा हूँ। 1 महीने में pg regression tests का 96% पास कर लिया और 823K LOC तक पहुँच गया
    Mythos के बिना, बस $200/महीना वाले Codex account के 8 instances ही उपलब्ध थे
    Rust का फायदा वहाँ भी दिखा, और Postgres के अनुभव के आधार पर मुझे लगता है कि लोग जिन हिस्सों में लंबे समय से pg में संघर्ष करते रहे हैं, वहाँ अच्छे design decisions लिए जा सकते हैं। AI की वजह से ऐसे complex software improvements अब ज़्यादा practical लग रहे हैं जो पहले नहीं थे
    [0] https://github.com/malisper/pgrust
    [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
  • जब Microsoft ने इसे Go में दोबारा लिखा था, तो leads में से एक ने Rust की जगह Go चुनने की वजह paradigm similarity बताई थी। Garbage collection वगैरह मिलते-जुलते हैं, और Rust ज़्यादा कठिन होता तथा कई workarounds चाहिए होते—आपने खुद यह किया है, तो आपका अनुभव क्या रहा?
  • Rust शानदार है, लेकिन बड़े projects में large language model के साथ Rust software बनाना चाहो तो चीज़ें मनचाहे तरीके से टूटने लगती हैं
    साफ boundaries बनाए रखना या स्थापित करना भी flow state की जगह दर्दनाक review बन जाता है, और आखिर में आदमी टालमटोल mode में चला जाता है
  • Opus को Rust idioms नज़रअंदाज़ करने से रोकना और जितना संभव हो उतना अजीब Rust लिखने से बचाना मुश्किल रहा। कोई tips?

• यह बहुत ठोस आधार पर नहीं है, लेकिन अब मैं Bun से जुड़ना नहीं चाहता। यह ज़्यादा gut feeling है, पर मैं इस पर भरोसा भी नहीं कर पा रहा हूँ और इसे support भी नहीं करना चाहता
  LLM rewrite का इस्तेमाल करने के लिए Zig को fork किया गया, और Zig team जिस non-deterministic compilation को साफ तौर पर नहीं चाहती थी, वैसी चीज़ें बनाई गईं
  अब यह रोना-धोना करते हुए Rust में LLM rewrite कर रहा है। हो सकता है Zig की design philosophy ने कठिन लेकिन सही फैसले लेने को मजबूर किया हो और उसी से यह यहाँ तक पहुँचा हो, और यह भी संभव है कि Rust rewrite ही गिरावट की शुरुआत साबित हो
  यह तकनीकी से ज़्यादा राजनीतिक फैसला है, लेकिन Bun ऐसा लगता है जैसे Claude के सहारे पूरी तरह खड़ा है। अगर Anthropic की अगली marketing line यह हो कि “Claude Mythos ने अग्रणी 950K LOC JS runtime को Rust में rewrite किया,” तो मुझे हैरानी नहीं होगी

  • समझ नहीं आता कि अपने repository में code लिखने वाला developer रोता-बिलखता बच्चा है, या Hacker News पर उसकी शिकायत करने वाला व्यक्ति
  • मैंने Jarred को रोते-धोते नहीं देखा; लगता है गुस्सा गलत दिशा में जा रहा है
    linked Twitter thread में स्पष्ट technical justification दी गई है
  • मैं Bun में व्यक्तिगत रूप से इतना invested नहीं हूँ, लेकिन समझ नहीं आता कि यह इतनी बड़ी बात क्यों है। क्या लोग अपनी दूसरी dependencies की भी ऐसी ही जाँच करते हैं?
    JS/NPM ecosystem में काम करना वैसे भी unverified dependencies पर काफी हद तक pure faith पर निर्भर करता है, और LLM rewrite से पहले और बाद में कोई बुनियादी फर्क नहीं दिखता। अगर original goals और API contracts पूरे हो रहे हैं, तो फर्क क्या है? यह भी शक है कि लोग पहले वाले source code को भी सच में ध्यान से पढ़ते थे या नहीं
  • सहमत। Bun की design philosophy शुरू से साफ थी। runtime, bundler, test suite, package manager—जो कुछ चाहिए, सब कुछ करना, और हर हफ्ते टूटने वाले patches निकालना इसका तरीका था
    हर बार यह दावा कि मौजूदा competitors को और बेहतर, तेज़, मजबूत तरीके से पछाड़ देगा, लेकिन Keep It Simple Stupid वाला रास्ता कभी नहीं चुनेगा—यह बहुत साफ था
    यह भी साफ था कि निकट भविष्य में इसे असली production environment में वही जगहें अपनाएँगी जहाँ accelerator डालकर जलाए जा रहे YC startups हों। अब लगता है कि यह non-return point पार कर चुका है
  • Bun लगभग मर चुका है
    Anthropic ने अपनी “performance” समस्या सुलझाने की कुछ हद तक मूर्खतापूर्ण कोशिश में Bun को खरीदा। शायद उन्हें पता ही नहीं था कि मूल समस्या शुरू से ही खराब code थी
    फिर भी, उन्होंने वास्तव में सक्षम developers को साथ लिया है, तो कुछ मदद हुई होगी
    लेकिन इस प्रक्रिया में Bun एक public project से Anthropic के internal tool जैसा ज़्यादा बन गया है, और अब AI funding की वजह से overprotected होकर काफी focus खो चुका है
    उम्मीद है कि bubble फूटने पर भी Bun पर लगी मेहनत का कुछ हिस्सा बचाया जा सके। Anthropic इसे लंबी अवधि तक maintain करेगा, ऐसा नहीं लगता। वह runtime support बेचने वाली कंपनी नहीं है, और न ही उसके पास Google जैसी scale है कि side project की तरह runtime maintain करती रहे

• AI की भूमिका को थोड़ी देर के लिए अलग रखें, तो मुझे यह अच्छा बदलाव लगता है
  Zig इस्तेमाल करते हुए Bun में crashes और memory bugs बहुत ज़्यादा थे, और यह Rust-आधारित Deno से अलग दिखता था
  बेशक, अगर Bun के Rust port में unsafe बहुत ज़्यादा है तो सब कुछ जादू की तरह ठीक नहीं हो जाएगा, लेकिन फिर भी स्थिति बेहतर होनी चाहिए

  • क्या Bun में crashes और memory bugs बहुत ज़्यादा होने के कोई आँकड़े या source हैं? मैं यह नहीं कह रहा कि आप गलत हैं
    जो बदसूरत हिस्से unsafe के रूप में ज़्यादा साफ दिखते हैं, और इस तरह refactoring को बढ़ावा मिलता है—इसमें सिर्फ language नहीं, Bun की अपनी बनावट का भी कुछ दोष लगता है
  • क्या आपका मतलब यह है कि Zig इस्तेमाल करने से “crashes और memory bugs बहुत ज़्यादा हो जाते हैं”?
    अगर हाँ, तो क्या इसका मतलब नहीं कि ऐसे tools से high-quality software बनाना लगभग असंभव है? C/C++ में भी बहुत-सा quality software बना है, तो सवाल है कि Zig आखिर क्या गलत कर रहा है
  • unsafe के रूप में साफ चिह्नित होने से इन्हें ढूँढना आसान हो जाता है, और इससे ठीक किए जाने वाले मुद्दों की एक स्वाभाविक सूची बनती है

• इसे करने में 6 दिन लगे। भले इसका अंतिम नतीजा अर्थपूर्ण निकले या न निकले, यह दिखाता है कि अभी और आगे tokens और workload का रिश्ता कैसा रहने वाला है
  जिन व्यक्तियों या कंपनियों के पास ज़्यादा computing resources होंगे, उनसे प्रतिस्पर्धा करना मुश्किल होता जाएगा। वे बस वे काम कर पाएँगे जो मैं नहीं कर सकता

  • अच्छी test suite वाले project को एक भाषा से दूसरी भाषा में translate करना, large language model की सबसे सफल use cases में से एक माना जाता है
    अगर एक तैयार codebase उदाहरण के रूप में हो और test suite से validate किया जा सके, तो मनचाहे लक्ष्य की ओर iterate करना बहुत आसान हो जाता है। Model पहले से देख सकता है कि लक्ष्य क्या है और एक बार वह कैसे implement किया गया था, इसलिए specification से शुरू करने की तुलना में यह कहीं आसान समस्या है
  • यही बात steam power या electricity के बारे में भी कही जा सकती थी। यह सिर्फ सतही analogy नहीं है। इन चीज़ों का जादू general-purpose information engine होने में है
    पूँजी लगाओ, अच्छी तरह समझी गई scalable technique से बनाओ, बिजली जोड़ो और value निकलती है
    मूल बात यह है कि जैसे आधुनिक दुनिया में बिजली ने “जिनके पास है और जिनके पास नहीं” वाला स्थायी विभाजन नहीं बनाया, वैसे ही यहाँ भी ज़रूरी नहीं कि वैसा हो
  • बात इतनी साफ नहीं है। बेहतरीन products आम तौर पर एक-दो चीज़ें बहुत अच्छे से करके बनते हैं, बहुत सारी चीज़ें करके नहीं
    अभी तक जो दिख रहा है वह कुछ ऐसा है: “वाह, अब मैं 10x engineer हूँ!” और फिर बिना स्पष्ट दिशा या taste के ज़्यादा code उगलना। अभी के large language model आधारित काम का बड़ा हिस्सा सिर्फ noise जैसा लगता है
  • नहीं। ऐसे agents को local पर चलाना लगातार आसान होता जा रहा है
    पता नहीं आपने Qwen 3.6 27b इस्तेमाल किया है या नहीं, लेकिन अपने size के हिसाब से वह पागलपन की हद तक सक्षम है। अगर context management ठीक रखें, तो छोटे projects में 100% vibe coding भी संभव है
    ये models भी अंततः compute की तरह price competition के साथ नीचे आएँगे
  • अगर इसे Anthropic की standard pricing पर चलाया गया होता, तो डॉलर में इसका खर्च कितना आता? क्या कोई लगभग अनुमान लगा सकता है?

• बहुत लोग इसे सीधे-सीधे स्वीकार कर रहे हैं, लेकिन इसका बड़ा हिस्सा पहले से बनाए गए असाधारण रूप से व्यापक और comprehensive test suite की वजह से संभव हुआ है

  • फिर भी यह प्रभावशाली उपलब्धि है, क्योंकि सबसे सक्षम engineers को भी यह करने में बहुत ज़्यादा समय लगता
    बाद में जब इसका marketing किया जाए, तो अच्छा होगा अगर उस test suite को design और curate करने में लगी मानवीय मेहनत का भी उल्लेख हो जिसने यह रफ़्तार संभव की
    test suite मौजूदा पीढ़ी के large language model के लिए लगभग आदर्श environment की तरह काम करती है। पर्याप्त comprehensive test suite agent के लिए ऐसी specification बन जाती है जिसके अनुसार वह implementation कर सकता है, और यहाँ वह लक्ष्य Rust था
    Bun जैसे project में अगर tests इतने अच्छे से बने हों, तो कुछ मामलों में शायद original source code पूरी तरह हटा कर सिर्फ tests की पहुँच देकर भी शुरुआत से पूरा implementation फिर से कराया जा सकता है
  • अगर यह test suite दूसरे projects की तुलना में इतनी “असाधारण” है कि इसी ने अकेले यह काम संभव बनाया, तो फिर यह बात कैसे साथ बैठती है कि Bun दूसरे Zig programs की तुलना में असामान्य रूप से unstable है और इसलिए rewrite की ज़रूरत है?
    अगर कुछ जिम्मेदारी test suite पर भी आती है, तो Rust port के लिए इसका क्या मतलब होगा, यह भी सोचने लायक है
  • तो बस यह देखो कि 6 दिनों में यह हो गया
    और उस मूल architecture तथा test suite में लगे लाखों घंटों को नज़रअंदाज़ कर दो जिसने इसे संभव बनाया?

• AI के सहारे Rust porting के लिए इसे एक चेतावनी भरे उदाहरण की तरह देखा जा सकता है
  https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

  • tests पास कर लेना यह नहीं साबित करता कि चीज़ सच में काम करती है
    Claude code C compiler ने gcc tests 100% पास किए, लेकिन hello world तक नहीं चला पाया
  • उन उदाहरणों से मिलने वाला सबक थोड़ा अलग है। large language model वही बनाता है जिसकी feedback loop आप उसे देते हैं
    अगर आप सिर्फ logic tests देंगे, तो वह speed की परवाह ही नहीं करेगा। अगर आप speed नापने वाले tests शामिल करें और performance target दें, तो वह वह भी करने लगेगा
    यह large language model की दूसरी गलतियों जैसा ही है। जिन चीज़ों को इंसान महत्वपूर्ण मानता है, उनके बारे में इसे common-sense context नहीं होता। अगर boundaries लागू नहीं करेंगे, तो वह उन्हें अनदेखा करेगा
  • अगर रुचि हो, तो इस पर यहाँ चर्चा हुई थी: LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - मार्च 2026, 422 टिप्पणियाँ

• हम सच में अद्भुत समय में जी रहे हैं
  industry और profession की बुनियादी dynamics इतने कम समय में, मानो रातोंरात, बदल गई हैं
  कुछ दिनों में मैं इस बात से उत्साहित हो जाता हूँ कि अब मैं कितना कुछ कर सकता हूँ। जो चाहो, लगभग तुरंत बना सकते हो, और software के ज़रिए जिन चीज़ों का सपना था, उनका 100% वास्तविक हो सकता है
  कुछ दिनों में job market को लेकर डर लगता है कि अब क्या होगा
  अचानक बहुत कम संसाधनों से बहुत ज़्यादा हासिल करना संभव हो गया है, और दुनिया को जितना software चाहिए उसकी भी कोई सीमा है
  क्या वे सारी कंपनियाँ खत्म हो जाएँगी जिनका मुख्य business model software बेचना है?
  अगर सबसे अच्छे models तक सिर्फ कुछ कंपनियों या सरकारों की पहुँच रही, तो क्या होगा?

  • ticketing system जैसे software business के बारे में सोचो
    क्या 1 अरब tokens वाली 100 कंपनियाँ, 1000 अरब tokens वाले किसी specialized vendor से बेहतर product बना पाएँगी?
    “logo generator” जैसे software vendors और SaaS तो शायद पहले ही मर चुके हैं, लेकिन जब तक अगली पीढ़ी के large language model में ticketing system built-in न आ जाए, ticketing system vendors ठीक रहेंगे। headcount घट सकती है, लेकिन यह पक्का नहीं है
  • dot-com crash के आसपास भी software industry को लेकर काफी बातें होती थीं कि यह “बहुत saturated” हो चुकी है, और students व job seekers से कहा जाता था कि इस क्षेत्र में मत आओ
    तर्क यह था कि आने वालों की संख्या के मुकाबले बाँटने लायक काम कम है, और crash ने इस narrative को और मजबूत किया
    लेकिन तब भी, अगर आप student थे, तो समझ सकते थे कि software का दायरा लगभग असीम है। हम जो लगभग हर cognitive काम हाथ से करते हैं, उसे software से किया जा सकता है। मैंने एक बार ऐसी चीज़ों की सूची बनानी चाही थी, लेकिन जल्दी समझ आ गया कि करने को काम बेहिसाब है
    और यह भी समझ आया कि जैसे-जैसे आप काम नए तरीकों से करते हैं, वैसे-वैसे और भी नए काम सामने आते हैं जिनकी आपने कल्पना भी नहीं की होती। संभावनाएँ गिनती से बाहर थीं, और “saturation” वाला narrative साफ तौर पर software क्या हो सकता है, इसकी कल्पना और समझ की कमी से पैदा हुआ था
    इसलिए मुझे पता था कि यह क्षेत्र कभी saturated नहीं होगा। software से बनाए जा सकने वाले लक्ष्यों की कमी होना असंभव था
    लेकिन अब बात अलग लगती है। हम आगे भी नया software बनाते रहेंगे, पर अब सवाल यह है कि क्या software लिखे जाने की गति, हमारे नए कामों की कल्पना करने की गति से आगे निकल सकती है
  • कंपनियों और सरकारों को आम लोगों की तुलना में बेहतर models की पहुँच होगी। Mythos पहले से इसका उदाहरण है
    आम लोग भी frontier से पीछे वाले models के सहारे अपनी मदद कर पाएँगे

• कम से कम ऐसी कोशिश को होते देखना दिलचस्प है
  सबसे पहला सवाल मेरे मन में यह आता है कि आखिर test suite की व्यापकता और गुणवत्ता कितनी है। मैं सिर्फ कमियाँ निकालने की कोशिश नहीं कर रहा, लेकिन अगर हर platform पर 100% भी आ जाए, तब भी Bun team migration को लेकर कितनी आश्वस्त होगी, यह जानना दिलचस्प होगा

• पिछले हफ्ते Ubuntu coreutils वाली घटना के बाद 99.8% test-compatible Rust rewrite सुनकर ही मेरी धारणा बहुत खराब हो गई थी
  यहाँ linked tweet खोलते ही सिहरन हुई, और अब ऐसी चीज़ें देखकर मेरे अंदर बिल्कुल उलटी प्रतिक्रिया होती है। लगभग exit ढूँढने जैसा महसूस होता है