2 पॉइंट द्वारा GN⁺ 2023-11-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • fish-shell का Rust पोर्ट “काफी हद तक” पूरा हो चुका है, और गणना के तरीके के आधार पर प्रगति C++ SLOC हटाने के आधार पर 60% से लेकर Rust SLOC बनाम C++ SLOC के आधार पर 74% तक आंकी गई है
  • बचा हुआ सबसे बड़ा काम reader और input system को पोर्ट करना है; reader की 3.5k लाइनें, screen handling की 1.3k लाइनें, input की 1k लाइनें और pager की 700 लाइनें आपस में बहुत कसकर जुड़ी हुई हैं
  • सभी C++ कोड हटाए जाएंगे, और बीच में partial Rust release नहीं निकाला जाएगा; fish 4.0 जैसी release का लक्ष्य ऐसा रूप है जिसमें सिर्फ Rust हो और C++ शून्य हो
  • Windows पोर्ट कभी योजना में नहीं था, और Rust में बदलाव Windows support की समस्या का समाधान नहीं है; MSYS2/cygwin environment के users को चिंता है कि Rust में उन targets की कमी updates को रोक सकती है
  • पूरे हुए पोर्ट की performance अभी तय नहीं है; शुरुआती नतीजे उत्साहजनक हैं, लेकिन कुछ मामलों में लगभग 20% धीमा होने की संभावना भी है, और माना जा रहा है कि पहली Rust release के लिए beta की जरूरत होगी

Rust पोर्ट की प्रगति

  • fish-shell का Rust rewrite “काफी हद तक” पूरा हो चुका है
  • प्रगति इस बात पर निर्भर करती है कि किस आधार पर गिनी जाए
    • C++ SLOC हटाने के आधार पर 60%
    • Rust SLOC बनाम C++ SLOC के आधार पर 74%
  • कुछ कोड duplicate scaffolding है, जिसे आखिरी caller हटने पर हटाया जा सकता है
    • उदाहरण के लिए wgetopt पहले ही Rust में translate हो चुका है, लेकिन आखिरी C++ caller पोर्ट होने तक C++ version रखा गया है
    • सभी C++ callers में conversion code जोड़ने की तुलना में यह तरीका ज्यादा सरल है
  • आखिरी caller हटने के बाद duplicate code हटने पर कुछ हिस्से domino effect की तरह साफ हो जाएंगे

अभी बचा बड़ा काम

  • सबसे बड़ा बचा हुआ component reader और input system है
  • संबंधित कोड आपस में बहुत कसकर जुड़ा हुआ है
    • reader: 3.5k लाइनें
    • screen handling: 1.3k लाइनें
    • input: 1k लाइनें
    • pager: 700 लाइनें
  • उसके बाद कुछ बचा हुआ code और build system का C++ से बाहर निकलना बाकी रहेगा
    • cmake हटाना
    • cargo को जरूरी सभी काम संभालने के लिए बदलना
    • documentation और completion files को build और install करना भी cargo को ही संभालना होगा
  • fish build में सिर्फ Rust code compile करना ही नहीं, बल्कि कई auxiliary artifacts भी शामिल हैं, इसलिए यह आसान migration नहीं है
  • यह काम “drive-by contribution” के लिए उपयुक्त किस्म का काम नहीं है

Release plan और version flow

  • fish-shell partial Rust release जारी नहीं करने की योजना में है
  • उदाहरण के लिए fish 4.0 पूरी तरह सिर्फ Rust से बना होगा और उसमें C++ शून्य होगा
  • आम तौर पर beta और release candidates बंद कर दिए गए थे, लेकिन इस बदलाव को beta निकालने लायक बदलाव माना जा रहा है
    • पहले beta और release candidates को पर्याप्त testing नहीं मिलती थी, इसलिए उन्हें बंद किया गया था
  • Rust version पर जाने से पहले C++ आधारित 3.7.0 intermediate release भी चाहिए
    • ताकि उन platforms के लिए बेहतर starting point हो जो Rust version को handle नहीं कर सकते
    • 3.7.0, 3.6.1 में कुछ changes backport किए गए रूप में होगा
  • 3.7.0 पर काम Integration_3.7.0 branch में चल रहा है
    • एक preliminary CHANGELOG भी है
    • मुख्य changes में key-combination timeout, history-pager सुधार, rendering glitches fix और तेज glob शामिल हैं

बचे हुए files और खास scope

  • 1 दिसंबर 2023 तक बची हुई files की सूची यह है
src/fish_indent_common.cpp
src/fish_indent.cpp
src/fish_key_reader.cpp
src/builtins/bind.cpp
src/builtins/commandline.cpp
src/fish_tests.cpp
src/pager.cpp
src/reader.cpp
  • यह सूची बचे हुए C++ porting scope को file-level पर दिखाती है

गलतफहमियों का सुधार और constraints

  • सभी C++ code हटाए जाएंगे
  • Windows port योजना में नहीं था, और पहले भी कभी योजना में नहीं रहा
    • C++ भी Windows पर अच्छी तरह supported है, इसलिए Rust अपने-आप Windows port की समस्या हल नहीं करता
    • Windows port की समस्या language नहीं, बल्कि यह है कि Windows, Unix नहीं है
  • नाम और mascot नहीं बदले जाएंगे
  • tagline में “written in Rust” जोड़ने की संभावना कम है
    • fishshell.com पर यह बात बताई जा सकती है कि यह Rust में लिखा गया है
    • सितंबर 2024 की अतिरिक्त चर्चा में tagline में “written in rust” न डालने का रुख फिर से पुष्टि किया गया
  • पूरे हुए port की performance अभी पता नहीं है
    • शुरुआती नतीजे उत्साहजनक हैं
    • कुछ मामलों में लगभग 20% धीमा होने की संभावना भी है
    • शुरुआती port खत्म हो जाने पर भी project खत्म नहीं होगा, और अभी बहुत काम बाकी रहेगा

Windows और MSYS2/cygwin users की चिंताएं

  • एक user ने बताया कि वे MSYS2 environment में fish इस्तेमाल करते हैं, और MSYS2 POSIX utilities देता है इसलिए fish अच्छी तरह चलता है
  • Rust cygwin या MSYS2 targets provide नहीं करता, इसलिए उन्हें चिंता है कि Rust rewrite के बाद fish को cygwin या MSYS2 target के रूप में compile नहीं किया जा सकेगा
  • इस user का मानना है कि Rust में बदलाव कुछ Windows fish users को updates लेने से रोक सकता है
  • यह चिंता काम या language की आलोचना के रूप में नहीं, बल्कि इस constraint की याद दिलाने के रूप में रखी गई कि Windows, Unix नहीं है

1 टिप्पणियां

 
GN⁺ 2023-11-27
Hacker News की रायें
  • अगर मैंने सही समझा है, तो C++ से Rust में gradual rewrite करते हुए भी आखिर तक working state बनाए रखना हैरान करने वाला है
    प्रगति भी बहुत तेज है, और अगर आपने अभी तक fish नहीं आज़माया है तो ज़रूर आज़माएँ। इसके defaults अच्छे हैं, इसलिए customize किए बिना भी यह इस्तेमाल में आसान shell है, और कुछ साल पहले bash से shift करने के बाद वापस जाने का मन नहीं हुआ
    बोनस के तौर पर, bash के उस for-loop syntax को हर बार Google नहीं करना पड़ता, जिसे कम ही इस्तेमाल करते हैं और जो intuitive भी नहीं है

    • लगता नहीं कि यह gradual तरीके से हो रहा है
      वे “partially Rust मिला हुआ release नहीं करने की योजना” में हैं, और मसलन fish 4.0 को पूरी तरह Rust, C++ 0% के रूप में release करने का सोच रहे हैं। बीच में C++-only 3.7.0 भी निकालकर उन platforms के लिए बेहतर starting point बनाना चाहते हैं जो Rust version संभाल नहीं पाएँगे
      https://github.com/fish-shell/fish-shell/discussions/10123#d...
    • scripts अब भी Bash में लिखता हूँ या सीधे Python/Perl निकाल लेता हूँ, लेकिन terminal usage के लिए Fish निश्चित रूप से बेहतर है
    • याद रखने में आसान Bash loop के उदाहरण के तौर पर, incrementing index को for ((i = 0; i < 10; i++)); do echo $i; done की तरह लिख सकते हैं
      array iteration के लिए foo[0]=a, foo[1]=b रखने के बाद for i in ${foo[@]}; do echo $i; done वाला रूप इस्तेमाल किया जा सकता है
  • rewrite की motivation और विस्तार से दी गई है
    https://github.com/fish-shell/fish-shell/pull/9512#issuecomm...

    • maintainer की पोस्ट mature और logical है, साथ में ठीक-ठाक humour भी है और decisiveness भी; इससे मेरा मन, जो अब तक बस Fish आज़माने की सोच रहा था, इस ओर बदल गया कि शायद मैं एक शानदार project miss कर रहा था
    • C++17 पर port करना “बहुत झंझट” मानना, लेकिन नई language में सब कुछ फिर से लिखना ठीक समझना, काफी कुछ बताता है
      आखिरकार पूरे development जगत में नई और चमकदार चीज़ों के पीछे भागने वाली बात को नकारना मुश्किल है। फिर भी मैं Fish इस्तेमाल नहीं करता, लेकिन उम्मीद है यह सफल हो
  • Fish को लगभग 4 operating systems पर रोज़ इस्तेमाल करने और पसंद करने वाले के तौर पर, यह rewrite वाकई exciting है और codebase के size और complexity को देखते हुए इसकी progress हैरान करने वाली है
    लगता है कि मेरे समेत बहुत से लोगों के लिए contribute करना आसान हो जाएगा। एक कम चर्चा में रही, लेकिन अधिक exciting बात यह है कि भविष्य में fish को wchar_t के बजाय UTF-8 इस्तेमाल कराने की योजना है। UCS2 और UTF-16 software के लिए सिरदर्द रहे हैं, और Rust में UTF-8 handle करना कहीं आसान है

    • एक ही codebase में कई compilers support करने हों तो complexity और बढ़ जाती है
      sizeof(wchar_t) MSVC में 2 bytes होता है, इसलिए UTF-16 है, और gcc में 4 bytes होता है, इसलिए UTF-32 है
  • Fish एक underrated shell है
    यह POSIX compatibility छोड़ने जैसे strong choices करता है, और नतीजे में बहुत अच्छा shell बनता है। 10 साल से ज़्यादा समय से इस्तेमाल कर रहा हूँ और अब भी पसंद है
    Fish shell scripting भी इस्तेमाल में बहुत सुविधाजनक है, ergonomic bash जैसा लगता है। किसी भी project में कमियाँ होती हैं, लेकिन इसने कभी सचमुच मुझे वह काम करने से नहीं रोका जो मैं करना चाहता था

  • zsh + spaceship इस्तेमाल करने वाले के तौर पर, जानना चाहता हूँ कि Fish को main shell बनाने से क्या फायदे होंगे
    bash scripts मैं ज़्यादा इस्तेमाल नहीं करता, इसलिए scripting वाला हिस्सा कम महत्वपूर्ण है

    • अगर आपने zsh पहले से अपनी पसंद के मुताबिक set कर रखा है, तो शायद बहुत बड़े फायदे नहीं होंगे
      Fish की बड़ी खूबी यह है कि यह बिना setup के सीधे ideal shell के काफी करीब है। autocompletion तुरंत काम करता है, history search आसान है, history-based command completion भी है, और prompt चुनना browser खोलने जितना आसान है। zsh की तरह इसे गहराई से customize किया जा सकता है, लेकिन defaults भर से भी यह काफी अच्छा shell बन जाता है
    • 2017 में zsh के बजाय Fish चुनने की वजह यह थी कि मनचाहे features default में शामिल थे, और महसूस में यह कहीं तेज था
      उसके बाद shell configuration maintenance पर लगभग समय नहीं लगाना पड़ा, जो अच्छा लगा
    • वजह speed है
      Fish कई ऐसे काम default में कर देता है जिनके लिए zsh में plugins चाहिए होते थे। zsh plugins धीमे थे, जिससे shell start होने में 3 seconds से ज़्यादा लगते थे, जबकि Fish plugins डालने पर भी कहीं तेज start होता है
    • जब पहली बार सही directory में fish_prompt.fish file बनाई, उसके अंदर fish_prompt function लिखा और string को standard output में भेजकर अपना shell prompt खुद बनाया, तो zsh हटाने ही वाला था
      $PS1 में तरह-तरह की चीज़ें ठूँसकर सब ठीक चले इसकी उम्मीद करने वाले तरीके पर लौटना मुश्किल हो जाता है। कुछ दिन ही सही, इसे आज़माने की सलाह दूँगा। क्योंकि तब दिखता है कि जिन चीज़ों को आप obvious मानते थे, उनमें से कौन-सी shell-specific features हैं। सबसे खराब स्थिति में भी आप कह सकते हैं “मेरी पसंद का नहीं है” और bash/zsh या अपने पसंदीदा shell पर लौट सकते हैं
    • कुछ साल पहले zsh से Fish पर आया और features लगभग समान हैं, लेकिन Fish configuration file zsh config के करीब 10% size की है
      जो चीज़ें चाहिए उनमें से अधिकांश default में मिलती हैं, और अब सिर्फ fzf.fish plugin इस्तेमाल करता हूँ
  • सबसे तेज shells में से एक के और तेज होने की संभावना है
    zsh से Fish पर आने के बाद terminal productivity काफी बढ़ी

    • मैं उस पर दाँव नहीं लगाऊँगा
      link के मुताबिक, पूरा port performance में कैसा होगा यह असल में पता नहीं है। शुरुआती results उत्साहजनक हैं, लेकिन कुछ मामलों में लगभग 20% धीमा होने की भी पूरी संभावना है
    • C++ और Rust के बीच performance difference इतना बड़ा नहीं लगता
      शायद दोनों लगभग बराबरी पर होंगे और कोई साफ winner नहीं होगा
    • उत्सुकता है कि shell performance किस workflow में bottleneck बनती है
      आम तौर पर इसे काम दूसरे हिस्सों को सौंपने वाले glue code जैसा समझता था। शायद pipe efficiency का मामला हो, या bash में पूरा program लिखने वाले अजीब लोगों की वजह से हो, लेकिन Fish में quality-of-life improvements बहुत हैं, फिर भी speed को core advantage बताना थोड़ा अलग लगता है
    • C, C++, Rust और दूसरी languages का फर्क मायने रखे इतना तेज तो कोई type और काम manage नहीं करता होगा; जानना चाहता हूँ कि Fish और क्या देता है
  • Fish को 1 साल से इस्तेमाल कर रहा हूँ
    यह बात पसंद नहीं कि यह standard compatibility तोड़ देता है, जिससे gvm, nvm जैसी कुछ scripts नहीं चलतीं, लेकिन zsh में जो features आम तौर पर खुद configure करने पड़ते थे, वे सब इसमें मौजूद हैं। कई machines पर zsh setup करने की कोशिश करके हार मान ली और सबको default Fish पर बदल दिया
    यह पहले से ही अच्छा काम कर रहा है, इसलिए Rust में port करने से क्या मिलेगा, यह ठीक से समझ नहीं आता। अगर वजह security है, तो लगता है कि Fish के साथ malicious छेड़छाड़ कर सकने वाली कोई चीज़ पहले से ही system पर मौजूद होगी

    • जैसा कि मूल Rust discussion में आया था, Rust में ले जाने की कई वजहें हैं
      मुख्य रूप से यह contributors जुटाने और maintainers के लिए भरोसेमंद async/parallel mode जोड़ने के बारे में है
      [1] https://github.com/fish-shell/fish-shell/pull/9512
  • Fish अच्छा है
    ZSH+Prezto से सीधे सिर्फ Fish इस्तेमाल करने पर आ गया, और किसी चीज़ की कमी नहीं लगती, बल्कि यह काफी तेज़ है। servers पर हर जगह bash है और bash scripts भी अभी इस्तेमाल करता हूँ, लेकिन रोज़मर्रा के terminal कामों के लिए Fish काफी है

  • Fish को लेकर हमेशा curiosity रही, लेकिन POSIX-incompatible होने की वजह से हिचकिचाहट थी
    जानना चाहता हूँ कि क्या कोई इस हिस्से में आई problems और workaround share कर सकता है

    • Fish bash/shell scripts का replacement नहीं है, बल्कि इसे interactive shell के तौर पर इस्तेमाल करने के लिए बनाया गया है, इसलिए POSIX compliance असल में बड़ी समस्या नहीं है
      कमी बस इतनी है कि थोड़ा context switching चाहिए। खासकर अगर आपने पूरी जिंदगी bash/zsh इस्तेमाल किया हो तो ऐसा और लग सकता है। shell को user interface की तरह इस्तेमाल करने और bash/sh को interpreter की तरह इस्तेमाल करने के बीच फर्क करना मेरे लिए निजी तौर पर आसान है, लेकिन यह सभी को intuitive नहीं लग सकता
      साथ ही, POSIX-compatible shell को daily shell की तरह इस्तेमाल करना छोड़ने के बाद से, जिन scripts को पहले शायद bash में हल करता, उन्हें अब ज्यादा जल्दी general-purpose language में promote कर देता हूँ
    • Bash/zsh scripts को बस Bash/zsh से चलाएँ: bash script.sh
      शुरुआत में Fish इस्तेमाल करते समय POSIX incompatibility अटकी थी, लेकिन थोड़ा अलग syntax सीखकर उससे बाहर आने के बाद लगता है कि Fish का ज्यादा sane syntax उस मेहनत के लायक है। अब terminal इस्तेमाल करना कहीं ज्यादा मज़ेदार लगता है
      ऊपर से 90% समय POSIX compatibility बनाए रखने की जरूरत नहीं होती, और आजकल कई scripts या extensions भी Fish support करते हैं। enterprise environment में standard Bash/zsh ही इस्तेमाल करता हूँ
  • जानना चाहता हूँ कि Rust में क्यों बदला जा रहा है
    क्या C++ codebase संभालना मुश्किल होता जा रहा था?