हमें फिर से शुरुआत करनी होगी: Atom से Zed तक

 (zed.dev)
2 पॉइंट द्वारा GN⁺ 2024-02-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Atom बनाने वाली टीम Zed में उसी लक्ष्य को फिर से साध रही है: हल्का लेकिन IDE-स्तरीय फीचर्स वाला एडिटर, जिसे Rust·GPU-accelerated UI·CRDT·Tree-sitter के आधार पर बनाया जा रहा है
  • 2017 में Atom की सीमाएँ टीम की क्षमता से ज़्यादा Electron और JavaScript में memory और rendering control की कमी के रूप में सामने आईं, और यहीं से यह निष्कर्ष निकला कि “हमें फिर से शुरुआत करनी होगी”
  • Rust, Zed को shared memory और multithreading को अधिक सुरक्षित तरीके से संभालने में मदद करता है, और copy-on-write B-tree तथा Arc आधारित rope structure की बदौलत background tasks के लिए O(1) snapshots संभव होते हैं
  • Zed, GPUI, Tree-sitter extensions, editor crate, multi-buffer, और SumTree जैसी core layers को खुद own करता है; इसके बदले उसे fine-grained control मिलता है, लेकिन development speed और onboarding cost की कीमत चुकानी पड़ती है
  • उपयोगकर्ताओं के लिए सबसे महत्वपूर्ण नतीजा एक तेज़ एडिटर है, और Rust तथा cargo आधारित संरचना open source contributors के लिए build और changes आज़माना आसान बनाती है तथा merge reliability बढ़ाती है

Atom की vision किस तरह Zed तक पहुँची

  • Zed का लक्ष्य, Atom की शुरुआती vision का एक अधिक परिष्कृत रूप है
    • हल्का, minimal, और text editor जैसा महसूस होने वाला टूल
    • ज़रूरत पड़ने पर IDE-स्तर की सुविधाएँ देने वाला, लेकिन UI और user experience में धीमा या भारी न लगने वाला टूल
    • extensible और scriptable editor
  • Emacs की extensibility ने शुरुआती vision को प्रभावित किया था, लेकिन सिर्फ character-by-character manipulation से आगे बढ़कर text representation को अधिक समृद्ध रूप में संभालने की दिशा चाहिए थी
  • Tree-sitter वह आधार है जो text को character की बजाय structural रूप में संभालने देता है, और Zed अभी scriptable नहीं है, लेकिन उसी दिशा को लक्ष्य मानता है
  • Atom web technologies पर आधारित होकर शुरू हुआ था; उस समय Rust मौजूद नहीं था, और C या C++ में native editor बनाना भी कठिन माना गया था

2017 में “फिर से शुरुआत” का फैसला क्यों लिया गया

  • Atom ने 2017 में Teletype जारी करने के बाद महसूस किया कि टीम की अनुभवहीनता से ज़्यादा platform constraints ही बड़ा bottleneck बन रहे थे
  • JavaScript arrays, object pointers की array की तरह behave करती थीं, इसलिए iteration के दौरान pointer chasing cost आती थी, और memory layout तथा garbage collector pauses को सीधे नियंत्रित करना मुश्किल था
  • line layout को तेज़ बनाने की कोशिश में iframe, Canvas और text measurement API को घुमा-फिराकर जोड़ना पड़ता था, और cursor position या line placement जैसे साधारण दिखने वाले काम भी जटिल हो जाते थे
  • Electron, Atom बनाने के लिए पैदा हुआ था, लेकिन code editor की ज़रूरत के स्तर का control देना उसके लिए मुश्किल था
    • इसे अधिक साधारण apps में इस्तेमाल किया जा सकता है, लेकिन memory footprint बड़ा होने की कमी रहती है
    • code editor में rendering, input और text processing पर अधिक direct control चाहिए होता है
  • 2017 में किसी बिंदु पर यह निष्कर्ष निकला कि Atom के साथ मनचाहे स्तर तक पहुँचना संभव नहीं होगा, और यहीं से यह विचार शुरू हुआ कि core को Rust में लिखा जाए लेकिन presentation layer के रूप में Electron बना रहे

Rust और GPU acceleration की ओर जाने की प्रक्रिया

  • Zed के technology choices शुरू से तय किसी fixed blueprint का हिस्सा नहीं थे, बल्कि एक-एक करके constraints हटाते हुए बने
    • पहले core को Rust में लिखने की दिशा पर विचार किया गया
    • फिर Electron को छोड़कर अपना UI framework बनाया गया
    • Pathfinder का इस्तेमाल किया गया, लेकिन वह बहुत धीमा निकला, इसलिए अपने shaders और signed distance field सीखकर लागू किए गए
  • GPU acceleration का चुनाव “GPU-accelerated editor” जैसे नारे से नहीं, बल्कि इस समझ से हुआ कि अगर स्क्रीन के हर pixel का रंग parallel में calculate करने वाले hardware का सीधे इस्तेमाल किया जाए तो यह तेज़ हो सकता है
  • Zed ने DOM nodes को manipulate करने के बजाय rendering को उस स्तर के क़रीब से control करने का रास्ता चुना जहाँ तय किया जाता है कि स्क्रीन के pixels कैसे draw होंगे
  • performance improvement के एक उदाहरण में find-all-matches पहले लगभग 1 सेकंड लेता था, जबकि Sublime Text लगभग 200ms के आसपास था; लेकिन internal API को call करने वाले high-level code भर से release build में इसे 4ms तक घटा दिया गया
  • Rust का compile time अब भी एक शिकायत का विषय है, लेकिन high-level abstractions के ऊपर भी performance की उम्मीद की जा सकती है — यह Zed के development में उपयोगी साबित हुआ

JavaScript/C++ boundary और Rust की multithreading

  • Atom में भी C++ का बहुत उपयोग हुआ था, लेकिन JavaScript application code और C++ library code के बीच की boundary बहुत महँगी पड़ती थी
    • काम को background threads पर ले जाने के लिए जुड़े subsystem को C++ में उतारना पड़ता था
    • shared memory इस्तेमाल करने के लिए C++ layer बनानी पड़ती थी और फिर उसके ऊपर JavaScript API डिज़ाइन करनी पड़ती थी
    • साथ ही उसे JavaScript-जैसा दिखाना और मौजूदा properties बनाए रखना भी ज़रूरी था
  • Rust का design multithreading-friendly है, इसलिए वह Zed की ज़रूरतों के ज़्यादा अनुकूल बैठता है
  • शुरुआत में parent pointers वाले mutable splay tree को Rust में implement करने की कोशिश borrow checker से टकरा गई, और एक समय तो यह भी संदेह हुआ कि क्या इस भाषा में वास्तविक system बनाया जा सकता है
  • बाद में copy-on-write B-tree बनाया गया जिसमें Arc का उपयोग हुआ, और यह structure स्वाभाविक रूप से multithreading के लिए उपयुक्त निकला
  • Zed की बुनियादी text storage structure, यानी rope, background threads को snapshots देने के समय सिर्फ Arc reference count बढ़ाने भर से काम चला सकती है

पूरे stack को खुद own करने का विकल्प

  • Zed ने parsing के लिए Tree-sitter से लेकर GPU-accelerated UI framework GPUI तक, बड़े blocks को खुद own करने का रास्ता चुना
  • इस तरह का ownership, ज़रूरी behavior को खुद तय करने और implement करने की आज़ादी देता है
    • जब language extensions में WASM इस्तेमाल करना था, तब Tree-sitter में वह capability जोड़ी जा सकी
    • text editor के लिए महत्वपूर्ण text rendering behavior को किसी बाहरी UI framework पर छोड़ने की ज़रूरत नहीं पड़ी
  • GPUI की शुरुआत 2019 में हुई, और उस समय मौजूद UI frameworks या तो Zed की ज़रूरतें पूरी नहीं करते थे, या टीम उन्हें पर्याप्त गहराई से नहीं समझती थी
  • नीचे के primitives को सीधे समझकर system बनाना, GPUI के मामले में लगभग survival strategy जैसा था
  • इसकी लागत भी साफ़ है
    • खुद बनाने में बहुत समय लगता है
    • development speed धीमी हो जाती है
    • widely known framework न इस्तेमाल करने की वजह से नए लोगों को लगभग 300,000-line codebase शुरू से सीखना पड़ता है
  • साथ ही, वह code लिखने वाले लोग टीम के भीतर मौजूद हैं और नए सदस्यों को समझा सकते हैं; टीम का मानना है कि समय के साथ direct ownership की cost घट सकती है और उसके फायदे जमा होते जाते हैं
  • loungy जैसे apps के उदाहरण भी सामने आए हैं जो GPUI के ऊपर बनाए गए

कहाँ polish बढ़ानी है और कहाँ जल्दी आगे बढ़ना है

  • Zed टीम का मानक यह है कि केवल वही बनाया जाए जो ज़रूरी है, और उस दायरे के भीतर जितना संभव हो उतना अच्छा बनाया जाए
  • भविष्य में शायद काम आए ऐसी चीज़ों का अनुमान लगाकर समय लगाने के बजाय, जो चीज़ वास्तव में ज़रूरी हो जाए उसी को इरादे और सावधानी से implement किया जाता है
  • polish का स्तर इस बात पर निर्भर करता है कि code किस layer में है
    • GPUI जैसी layer, जिस पर पूरा app निर्भर करता है, उसमें उच्च स्तर की polish चाहिए
    • SumTree जैसी data structure, जो codebase भर में इस्तेमाल होती है और performance-critical है, उसे भी बहुत सावधानी से संभाला जाता है
    • किनारों पर मौजूद कुछ specific performance fixes को ज़रूरत से ज़्यादा polish करने के बजाय लक्ष्य पूरा करने लायक स्तर पर रखा जाता है
  • SumTree edge cases की जाँच के लिए random testing का उपयोग करता है
  • perfectionism, learning के रास्ते में रुकावट नहीं बनना चाहिए; और जब कोई टीम लंबे समय तक अपने बनाए code को चलाकर, compromises झेलकर, फिर उसे दोबारा लिखती है, तब उस rewrite के पीछे सीखी हुई बातों का ठोस आधार होता है

CRDT और buffer structure से मिली सीख

  • Atom का शुरुआती buffer JavaScript strings की array, यानी lines की array था
  • Zed का buffer multithread-friendly और snapshot-friendly copy-on-write B-tree है, जो ज़रूरत के कई items को index करता है
  • CRDT शुरुआत से कोई स्वाभाविक चुनाव नहीं था; कई papers पढ़ने वाली research अवधि के बाद मौजूदा approach तय हुई
  • CRDT implementation दो-तीन बार फिर से लिखी गई, लेकिन समग्र approach लगभग बनी रही
  • पहले code editor Atom में तेज़ और rough “worse is better” approach अपनाई गई थी, और उसी अनुभव से पता चला कि असली pain points कहाँ हैं
  • अगर फिर से शुरुआत करनी हो तो buffer को simple line array के रूप में नहीं बनाया जाएगा, क्योंकि अतीत की धीमी मिसालों और edge cases ने अधिक जटिल design की माँग पैदा कर दी है

Zed में जिन layers पर खास मेहनत की गई

  • GPUI ऐसा क्षेत्र है जहाँ पूरे सिस्टम को फिर से लिखने के अनुरूप उच्च polish हासिल करने की कोशिश की गई
  • editor crate में कई layers शामिल हैं जो raw buffer text को स्क्रीन पर lines में बदलती हैं
    • tab expansion
    • soft wrapping
    • block decorations insertion
    • folding handling
  • इन transformation layers के पास property-based random testing पर आधारित एक सुसंगत testing strategy है
  • multi-buffer एक ऐसी structure है जो अलग-अलग buffers के हिस्सों को एक साथ जोड़ती है, और इसे भी core स्तर पर संभाला जाता है
  • 2021 में random testing से मिले edge cases को कम करने और debug करने में कई पूरे दिन लगाए गए थे
  • Rust में लिखी यह layer अगर गलत हो जाए तो सिर्फ editor के किसी कोने में stack trace नहीं दिखेगी, बल्कि program panic के साथ बंद हो सकता है, इसलिए correctness बहुत महत्वपूर्ण है
  • बड़े files खोलते समय user को बिना किसी feedback के इंतज़ार में न रहना पड़े, इसके लिए ज़्यादा streaming-friendly input और loading improvements पर भी चर्चा हुई, और संबंधित optimizations preview में आने वाली हैं

उपयोगकर्ताओं और contributors के लिए बचा हुआ अंतर

  • अंतिम उपयोगकर्ता के लिए सबसे अहम सवाल यही होता है कि editor तेज़ है या नहीं
  • developer tools और editors में इस बात की संभावना ज़्यादा होती है कि user खुद codebase में contribute करे, इसलिए implementation language और build system, contribution की संभावना को प्रभावित करते हैं
  • अगर Zed, C++ में लिखा गया होता तो शायद कम users सीधे इसमें बदलाव करने की कोशिश करते
  • Rust और cargo, project को build करना और changes आज़माना आसान बनाते हैं, और CMake या Gyp सीखने की ज़रूरत कम करते हैं
  • Rust compiler की सख्ती, बाहरी contributions स्वीकार करने के संदर्भ में merge reliability बढ़ाने में मदद करती है
  • Zed frames को 3ms से नीचे रखना चाहता है, और इसी performance requirement की वजह से उसने CPU rasterization के बजाय GPU-accelerated UI framework चुना
  • Zig में भी रुचि है, लेकिन server और frontend दोनों के लिए Rust वाली single-language structure के अपने फायदे हैं

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

1 टिप्पणियां

 
GN⁺ 2024-02-19
Hacker News की राय

  • Zed का custom UI framework अभी दिलचस्प लग सकता है, लेकिन जैसे ही यह एहसास होगा कि accessibility लागू करनी है, मामला बदल जाएगा
    performance से समझौता किए बिना custom framework में accessibility लागू करने के लिए platform-दर-platform बहुत सारा उलझा हुआ काम करना पड़ता है। Zed खुद को सिर्फ ऐसा editor नहीं मान रहा जिसे चाहो तो न इस्तेमाल करो, बल्कि एक collaboration tool के रूप में position कर रहा है, इसलिए यह ज़रूरी है कि टीम का हर developer इसे इस्तेमाल कर सके
    screen reader user होने के नाते, मैं उन Rust-आधारित “modern” tools से थक चुका हूँ जिनमें VoiceOver को सिर्फ खाली window दिखती है। कुछ buttons पर aria labels लगा देने और focus ठीक कर देने वाले web app के मुकाबले, custom UI में हर control को हर OS पर expose करना कहीं ज़्यादा कठिन है
    अच्छी बात यह है कि https://accesskit.dev/ जैसे AccessKit आने से काम थोड़ा आसान हो सकता है, लेकिन editor जैसे बड़े app के लिए यह कितना उपयुक्त है, पता नहीं

    • Zed docs में accessibility की व्याख्या लगभग बस इतनी ही है: अभी कई themes में accessibility की कमी है, Zed 1.0 के लिए एक नया accessible theme system तैयार किया जा रहा है, और Zed में accessibility पर काम 1.0 के बाद तक चलने वाला लंबा प्रोजेक्ट है
      क्योंकि GPUI को शुरू से बनाया गया है, इसलिए Swift या web-based apps में मिलने वाले accessibility features को वैसे का वैसा इस्तेमाल नहीं किया जा सकता, और Zed की तरफ के काम के साथ GPUI features का विस्तार भी ज़रूरी है
      लेकिन accessibility discussion के लिए दिया गया https://github.com/zed-industries/zed/pull/1297 लिंक तो back/forward buttons से जुड़ा GitHub issue है, इसलिए बेकार है। शायद वे https://github.com/zed-industries/zed/discussions/6576 लिंक करना चाहते थे
      संबंधित दस्तावेज़: https://zed.dev/docs/themes
      accessibility के बारे में सोचा गया है, लेकिन अभी इसे वास्तव में लागू नहीं किया गया है
    • ज़्यादातर Rust GUI का accessibility-friendly न होना चौंकाने वाली बात नहीं है। वजह यह है कि अभी ऐसा कोई standard GUI library नहीं है जिसे परिपक्व कहा जा सके
      कुछ समय पहले तक या तो पुराने C frameworks के bindings थे, या फिर proof-of-concept स्तर की GUI libraries। आगे चलकर स्थिति बेहतर होगी, लेकिन accessibility features पर निर्भर लोगों की निराशा भी समझ में आती है
      फिर भी, कई projects शायद पहले एक मजबूत GUI library बनाना चाहेंगे और उसके बाद accessibility features जोड़ेंगे
    • product नज़रिए से देखें तो performance, accessibility और user experience के मामले में किसी दिन native rendering layer के बराबर पहुँचने वाली चीज़ के लिए पहिया फिर से बनाना आमतौर पर जोखिम भरा फैसला होता है
      कई startups ऐसी चमकदार सुविधाओं पर resources खर्च करके असफल हुए हैं जो असल में उनकी differentiation भी नहीं थीं
      non-native UI के साथ सफल हुए products आम तौर पर web technologies या Qt जैसे परिपक्व frameworks का इस्तेमाल करते हैं, या फिर 30 साल पुराने Blender जैसे अपवाद हैं। Apple ने iTunes में भी कुछ ऐसा ही किया था, लेकिन Windows के लिए iTunes बहुत खराब अनुभव था, और लोगों ने उसके बावजूद iTunes का इस्तेमाल किया
      GPUI जैसा framework बनाने का आकर्षण समझ में आता है, लेकिन लेख यह नहीं बताता कि इसका Zed जिस समस्या को हल करना चाहता है उससे क्या संबंध है
    • मैं इस चिंता को कम करके नहीं दिखाना चाहता, लेकिन लगता है कि आधुनिक machine learning से बेहतर accessibility tools बनाने का मौका हो सकता है
      यानी ऐसे tools जो सिर्फ pixels देखकर इंसानों की तरह समझें और OCR से text parse करें
    • सोच रहा हूँ कि क्या AI-आधारित समाधान अधिक सामान्य स्तर पर assistive features दे सकता है, बिना window structure और असली text को गहराई से जाने
      मेरी समझ में VoiceOver जैसी तकनीकें असली window definitions और elements को programmatic स्तर पर जानती हैं और उसी का उपयोग करती हैं
      जो projects GPU rendering speed चाहते हैं और इसलिए VoiceOver को “खाली window” जैसे दिखते हैं, उनमें शायद यह तरीका कम-से-कम एक वैकल्पिक उपाय बन सकता है
      फिर यह भी सोचता हूँ कि क्या इसका मतलब है कि games की तरह GPU से render होने वाला सारा content inaccessible है
      मैंने iPhone पर “GPT Explains” नाम का एक Apple shortcut बनाया है, जिसमें फोन के पीछे दो बार tap करके screenshot लिया जाता है, उसे OpenAI को भेजा जाता है, और बदले में जो दिख रहा है उसका विवरण, non-English text का English अनुवाद, meme claims के rebuttals वगैरह मिलते हैं
      API key हटाई हुई कॉपी यहाँ है: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...

  • इस नए text editor trend पर कूदने से पहले, users को जिस license से सहमत होना पड़ता है उसे एक बार देख लेना चाहिए
    “Solution के उपयोग के दौरान बनाई गई user content से बना Customer Data, User Content के रूप में वर्गीकृत किया जाता है। User Content केवल तब user environment से transmit होता है जब आप Editor में project sharing चुनकर दूसरे Zed users के साथ collaborate करते हैं।”
    “[...] ऐसे User Content तक Zed की पहुँच debugging और Solution सुधारने तक सीमित है।”
    मैं अलग से कोई व्याख्या नहीं दूँगा, हर कोई खुद अपना निष्कर्ष निकाल सकता है

    • बल्कि मैं व्याख्या सुनना चाहूँगा। देखने में तो यह बिल्कुल तर्कसंगत लगता है, समझ नहीं आ रहा कि समस्या क्या है
      अगर आपने collaboration के लिए project को दूसरे लोगों के साथ share करने का चुनाव किया है, तो उस project का content आपकी मशीन के बाहर transmit होना स्वाभाविक है। वरना यह काम कैसे करेगा?
    • यह काफ़ी तर्कसंगत लगता है

  • इस लेख की वजह से मैंने Zed आज़माया, और यह काफ़ी promising लगा। लेकिन यह remote host/devcontainer को support नहीं करता, इसलिए मैं इसे इस्तेमाल नहीं कर सकता।
    VSCode में यह feature मेरे workflow का core हिस्सा है। सच कहूँ तो मैं Mac पर सीधे development नहीं करना चाहता; मैं Mac को बस उस portal की तरह इस्तेमाल करना चाहता हूँ जिससे मैं अपने coding VM और containers में जाता हूँ।
    यह projects को अलग रखने में बहुत मदद करता है, और actual host machine पर development environment या dependencies न रखने की वजह से security के लिहाज़ से भी बेहतर है।

    • मैं भी projects और clients को अलग रखने के लिए development VM इस्तेमाल करता हूँ, लेकिन हर VM के अंदर editor को सीधे चलाता हूँ।
      मुझे जानना है कि सामान्य remote session की तुलना में VSCode के remote host/devcontainer का क्या फ़ायदा है।
    • मुझे VSCode में यह feature सच में बहुत पसंद है। अच्छा होता अगर PyCharm भी code को बाहर भेजकर process किए बिना इसे इतनी आसानी से कर पाता।
    • अगर आप नया editor आज़माना चाहते हैं, तो Lapce यह feature support करता है।
    • मैंने Mac पर Nix अपना लिया है। अगर समस्या सिर्फ development dependencies की है, तो containers के अलावा भी बहुत से समाधान हैं।
    • अगर इस तरह का workflow शुरू करने के लिए कोई अच्छी guide link हो, तो मैं जानना चाहूँगा।

  • यह शानदार interview है, जो developers अलग-अलग नज़रियों से development को कैसे देखते हैं, इस mindset की अच्छी झलक देता है; मैं इसे ज़ोरदार recommend करता हूँ।
    हालांकि एक बात पर मेरी असहमति है।
    “Zig में बने text editor के लिए सही नाम Zed ने ले लिया” नहीं, वह नाम “Zag” है ;)

    • zed में ed शामिल है। ed, ex, vi, edlin का predecessor है, और अब भी मौजूद Unix-परिवार का line editor है।
      https://en.wikipedia.org/wiki/Ed_(text_editor)
      दूसरी ओर ag, यानी the silver searcher, भी शानदार है, लेकिन मेरी नज़र में Zed code search से ज़्यादा code editing के क़रीब है।
      https://geoff.greer.fm/ag/

  • मैं Zed इस्तेमाल नहीं करता, लेकिन मैंने José Valim को live coding में इसका इस्तेमाल करते देखा है। मैं ज़्यादातर VSCode इस्तेमाल करता हूँ, और Zed में देखा गया एक feature मुझे काफ़ी आकर्षक लगा।
    “Find All” करने पर, VSCode की तरह matching files के सभी snippets results panel में दिखते हैं, लेकिन वहाँ आप search result snippets को सीधे edit कर सकते हैं, और multi-cursor जैसे सामान्य editing features भी वैसे ही इस्तेमाल कर सकते हैं।
    VSCode में search result पर click करके file खोलनी पड़ती है और फिर वहाँ edit करना पड़ता है, इसलिए यह काफ़ी cool और प्रभावशाली लगा। इतना नहीं कि मैं switch कर लूँ, लेकिन जब भी VSCode परेशान करता है, यह feature कभी-कभी याद आ जाता है।

    • Emacs में 80 के दशक से occur और multi-occur रहे हैं, और यह काम वहाँ किया जा सकता है। यह सच में शानदार है।
      हाल के समय में ripgrep जैसे tools के interfaces भी editable mode देते हैं, जो refactoring के लिए बहुत सुविधाजनक है। बेशक, file names को भी bulk edit किया जा सकता है।
      https://www.masteringemacs.org/article/searching-buffers-occ...
      https://rgel.readthedocs.io/en/latest/
      https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...
    • JetBrains IDEs पहले से ही इसे support करते हैं।
      यह बेतुका लग सकता है, लेकिन VSCode की जगह JetBrains इस्तेमाल करने की मेरी बड़ी वजहों में से एक यह है कि मैं directory search कर सकता हूँ और उसे navigation panel में खोल सकता हूँ।
    • VSCode में भी, project-wide search के लिए super-shift-f दबाने पर, results panel के ऊपर “x results in y files” के दाईं ओर “Open in editor” link button होता है, और मेरी जानकारी में वही यह feature करता है।
      यह comment देखने के बाद ही मुझे वह भूली हुई चीज़ याद आई, इसलिए मुझे इसे फिर से आज़माना चाहिए।
    • यह काफ़ी उपयोगी लगता है। क्या यह VSCode extension “Search Editor: Apply Changes” की तरह काम करता है?
      https://marketplace.visualstudio.com/items?itemName=jakearl....
    • यह बढ़िया feature है। कई मामलों में regex को ज़बरदस्ती जटिल बनाने की ज़रूरत कम हो सकती है।
      मेरी पसंदीदा tricks में से एक है multi-cursor से edit करना और line end या next word पर जाने वाले shortcuts का इस्तेमाल करके bulk changes करना।
      अच्छा होगा अगर यह कई files में एक साथ किया जा सके।

  • यह Windows या Linux पर काम नहीं करता। जब support आ जाए तो फिर बताइएगा।

    • मैंने आज Thorsten से Windows support के बारे में पूछा, तो उनका जवाब था, “अगर आप Zed की बात कर रहे हैं, तो Linux के बाद शायद वही आएगा।” लगता है योजना तो है।

  • शानदार interview है।
    मुझे यह बात पसंद आई कि वे इस पर गहराई से सोचते हैं कि किस चीज़ को ज़रूरत से ज़्यादा polish करना है। मेरा सबसे अच्छा काम भी आमतौर पर दूसरे, तीसरे या चौथे दौर के आसपास ही निकला है।
    मैं यह जानना चाहता हूँ कि settings को script की तरह handle करने वाले feature के लिए क्या योजना है। मैंने अभी तक Zed ज़्यादा इस्तेमाल नहीं किया है; क्या यह अभी भी संभव है? क्या Neon जैसी कोई चीज़ VSCode और पुराने Atom users के बीच की खाई पाटने में मदद कर सकती है?
    https://github.com/neon-bindings/neon

    • “मनुष्य द्वारा डिज़ाइन किया गया दूसरा system सबसे ख़तरनाक होता है। तीसरे और उसके बाद, पिछले अनुभव system की सामान्य विशेषताओं की परस्पर पुष्टि करते हैं, और अंतर उन विशेष अनुभवों को उजागर करते हैं जिन्हें generalize नहीं किया जा सकता। सामान्य प्रवृत्ति यह होती है कि पहले system में सावधानी से टाल दिए गए सभी ideas और decorations का इस्तेमाल करके दूसरे system को overdesign कर दिया जाए.”
      — Brooks, Mythical Man-Month
      v2 को देखना हमेशा दिलचस्प होता है। मैंने ऐसे cases भी देखे हैं जहाँ यह feature bloat की वजह से disaster बन गया, और ऐसे भी जहाँ यह concise और sleek बनकर शानदार हो गया।
      आजकल web apps के क्षेत्र में tools इतने ज़्यादा हैं कि मैं सोचता हूँ, क्या यह जोखिम सिर्फ v2 पर नहीं बल्कि v1 पर भी उतना ही लागू होता है। आजकल कई v1 भी हैरान कर देने वाले स्तर तक bloated दिखते हैं, और अक्सर जानबूझकर कम करने वाले tools ढूँढ़ने पड़ते हैं।
    • मैं Atom से PyCharm और फिर VSCode पर गया, और दोनों transitions काफ़ी आसान थे। हालाँकि मेरे पास बहुत complex settings नहीं थीं।

  • मैंने Zed आज़माया है और यह VSCode जैसा लगा। मुझे पता है कि इसमें Live Share से बेहतर multiplayer feature हैं, लेकिन ऊपर-ऊपर से देखने पर स्विच करने के लिए अभी और ठोस वजह चाहिए लगी।
    अगर Zed, Xcode की जगह ले सके तो शायद मैं इसे और इस्तेमाल करना चाहूँ। derived data हटाने से लेकर build folder साफ़ करने और random crash तक, Xcode का इस्तेमाल करना तकलीफ़देह है।
    Android Studio के developer experience से तुलना करें तो यह बिल्कुल अलग है। iOS development में भी मैं हमेशा Android Studio जैसा अनुभव चाहता था।

    • AppCode कुछ हद तक iOS के लिए Android Studio था। दोनों ही IntelliJ आधारित हैं। हाल में AppCode बंद हो जाना अफ़सोस की बात है।
    • Xcode और Android Studio, दोनों में बहुत कमियाँ हैं। यह जानने की जिज्ञासा है कि Android Studio का कौन-सा अनुभव आपको Xcode में कम लगता है।

  • मुझे native apps सच में बहुत पसंद हैं, लेकिन अभी मैं VS Code से बँधा हुआ हूँ। VS Code में सिर्फ cursor blink होने पर भी इतनी power इस्तेमाल होती देख कर बुरा लगता है।
    मैंने थोड़ी देर के लिए Zed इस्तेमाल किया, लेकिन वह मेरे workflow के हिसाब से फिट नहीं बैठा। हल्का और तेज़ होना अच्छी बात लगी। VS Code processes लगभग 3GB लेते हैं जबकि Zed 300MB, इसलिए memory का दसवाँ हिस्सा होना मायने रखता है।
    लेकिन मुझे VS Code का Jupyter Notebook support ज़रूरी है, और Mac से Ubuntu box पर remote development करने के तरीके की भी मुझे बहुत आदत हो चुकी है। VS Code यह काम बहुत अच्छे से करता है।
    उम्मीद है Zed इतना लंबे समय तक बना रहे कि मेरे workflow को support करने लगे।

    • शायद आपकी किस्मत अच्छी है। इस समय मैंने कई VS Code projects खोल रखे हैं, local और remote दोनों मिले हुए हैं, और Notebook भी चल रहे हैं, फिर भी यह आम तौर पर 650MB से ज़्यादा नहीं जाता। यह मेरे MacBook memory का 1% भी नहीं है।
      शायद बाकी लोग ज़्यादा extensions चालू रखते होंगे।
    • Notebook की request एक साल से ज़्यादा समय से खुली है: https://github.com/zed-industries/zed/issues/5273
      Lindy effect https://en.wikipedia.org/wiki/Lindy_effect के हिसाब से, इसे देखने में शायद एक साल और लगेगा।
    • यह जानने की जिज्ञासा है कि VS Code में cursor blink से वास्तव में कितनी power खर्च होती है, और functionality में मिलते-जुलते दूसरे editors की तुलना में यह कैसा है।

  • मैंने About page देखा, और live coding feature उपयोगी लगती है। डेवलपर्स भी शायद इसे लेकर उत्साहित होंगे। आखिर यह algorithms, performance optimization, और GPU programming तक करने वाला मज़ेदार प्रोजेक्ट है।
    लेकिन एक और text editor की ज़रूरत किसे है, जो शायद Vim और terminal multiplexer की feature parity तक कभी नहीं पहुँच पाएगा?

    • ज़्यादातर developers शायद Vim इस्तेमाल नहीं करते। Vim को ऐसा पेश करना मानो वह सभी developers द्वारा सर्वमान्य और universally loved editor हो, हक़ीक़त से काफ़ी दूर लगता है।
      VS Code अपेक्षाकृत हाल में अचानक उभरा और बहुत से लोग उसे इस्तेमाल करते हैं, इसलिए यह दिखाता है कि Vim के बाद भी नए editors के लिए जगह रही है।
      Zed दूसरे developers की long-tail demand को संभालने लायक momentum पा सकेगा या नहीं, यह देखना होगा, लेकिन users हासिल करने के लिए प्रतिस्पर्धा करने वाले और products आना काफ़ी उत्साहजनक है।
    • अच्छा होगा अगर और editors headless mode में चलने वाले Neovim के frontend बनें।
      तब Vim की नकल करने की ज़रूरत नहीं होगी, बल्कि Neovim और उसके सभी plugins को वैसे का वैसा इस्तेमाल किया जा सकेगा।
      यह अब भी खलता है कि JetBrains उस Vim-नकल plugin को बनाए रखता है जिसे Vim users घटिया कहते हैं। अगर IDE में Neovim frontend को native रूप से लागू किया जाए, तो “Neovim और उसके ecosystem का पूरा support” जैसा कहीं ज़्यादा मज़बूत फ़ायदा मिलेगा; अभी बात बस “Vim जैसा plugin मौजूद है” तक सीमित है।
    • मुझे नहीं लगता कि Vim के साथ feature parity मिलाना कोई ख़ास मायने रखता है। LSP ने मैदान को काफ़ी हद तक बराबर कर दिया है, इसलिए अब किसी भी editor को रोज़मर्रा में इस्तेमाल करने पर ज़्यादातर लोगों से कम productive होने की नौबत नहीं आती।
      जो tool आपको पसंद हो और काम पूरा करवा दे, वही इस्तेमाल करें। इसमें Vim भी शामिल है, लेकिन Vim को किसी अपरिवर्तनीय वरदान की तरह पेश करने वाली बातों से मैं थक चुका हूँ।
      बेहतर सोचने वाला इंसान बनना, किसी भी tool से कहीं ज़्यादा, programmer के रूप में आपकी productivity को घातांकीय रूप से बढ़ाता है।
    • Vim के बारे में अपने विचारों को अच्छे शब्दों में कैसे कहूँ, यह समझ नहीं आता, लेकिन कुल मिलाकर बात सही लगती है।
      पहले से ही काफ़ी feature-rich editors मौजूद हैं जिनसे लोग संतुष्ट हैं, या कम से कम अभ्यस्त हो चुके हैं। ऐसे में नया editor अपनी जगह कहाँ बनाएगा?
      “multiplayer” अच्छा है, लेकिन यह काफ़ी हद तक edge case जैसा है।
      business model को लेकर भी भरोसा नहीं है। क्या लोग सच में channels, calls, और chat को code editor में integrated देखना चाहते हैं? निजी तौर पर मुझे लगभग सहज रूप से इससे असहजता होती है, लेकिन हो सकता है यह सिर्फ मैं ही हूँ।
    • Zed वाकई बहुत तेज़ है।