- 2,000 से ज़्यादा developers द्वारा माँगा गया debugging feature अब आखिरकार Zed में लागू कर दिया गया है
- debugger को speed, familiarity, configurability पर केंद्रित करके डिज़ाइन किया गया है
- Rust, C/C++, JavaScript, Go, Python जैसी लोकप्रिय भाषाओं और Debug Adapter Protocol (DAP) आधारित extensions का support दिया गया है
- सहज LOCATORS system की मदद से ज़्यादातर projects में अलग setup के बिना आसानी से debugging की जा सकती है
- UI और data layer की अलग architecture के कारण collaborative debugging और scalability के लिए मज़बूत आधार तैयार किया गया है
Zed debugger जारी
- 2,000 से ज़्यादा developers की माँग पर Zed editor में आधिकारिक debugging feature जोड़ा गया है। यह Zed 1.0 की दिशा में बहुत महत्वपूर्ण प्रगति है
मुख्य लक्ष्य
- स्पीड: तेज़ context switching और प्रभावी debugging experience देना
- परिचित अनुभव: Zed की design language के साथ मेल रखते हुए, सामान्य debugger flow में अपेक्षित सभी features का support
- configurability: UI, key bindings, debug settings आदि को user अपनी ज़रूरत के अनुसार customize कर सकता है
भाषा और extension support
- Rust, C/C++, JavaScript, Go, Python जैसी प्रमुख भाषाओं का built-in support है
- Debug Adapter Protocol (DAP) को implement करने वाले सभी debug adapters के साथ integration संभव है
- extension system के ज़रिए और भी कई भाषाएँ व debugging features आसानी से जोड़े जा सकते हैं
आसान debugging setup
- LOCATORS नाम का नया system जोड़कर build settings को debug settings में बदला जाता है
- एक बार
tasks.json में build task लिखने के बाद, उसे debug.json में refer किया जा सकता है, या Zed की auto-configuration feature का उपयोग किया जा सकता है
- Zed built-in या Language Server के executable files से locators को अपने-आप चलाता है
- ज़्यादातर मामलों में अलग debug configuration के बिना सीधे इस्तेमाल किया जा सकता है
- अभी Cargo, Python, JavaScript, Go के लिए locator support उपलब्ध है (और भाषाएँ बाद में आएँगी)
debugging session की सुविधाएँ
- Zed के भीतर threads, variables, breakpoints, call stack जैसे program state को आसानी से देखा जा सकता है
- debugger panel पूरी तरह customizable है, इसलिए tabs को drag और rearrange किया जा सकता है या panels को स्वतंत्र रूप से move किया जा सकता है
- keyboard-केंद्रित debugging भी supported है, जिससे mouse के बिना code navigation, breakpoint toggle और session movement किया जा सकता है
उच्च विस्तारयोग्य architecture
- कई भाषाओं की debugging, collaborative environments, extension support, और प्रभावी data caching व management के लिए 2-layer architecture डिज़ाइन की गई है
- data layer: debug adapter से सीधे communicate करती है, session state बनाए रखती है, responses cache करती है, और पुराने data की invalidation संभालती है
- UI layer: केवल ज़रूरी data request करती है और interface rendering पर केंद्रित रहती है
- इस separation की वजह से collaborative (multiplayer) debugging feature बनाना आसान होता है और network bandwidth की बचत भी होती है
extension API और DAP का उपयोग
- 70 से ज़्यादा तरह के DAP implementations मौजूद हैं, इसलिए सबको built-in support देने के बजाय Zed के extension API को बढ़ाकर debugger integration संभव बनाया गया है
- schema को सीधे define करना, adapter download और execution logic implement करना, debug settings के default inject करना, locator के साथ auto-integration करना आदि के ज़रिए DAP support बढ़ाया जा सकता है
- LSP (Language Server Protocol) extension model की तरह, developers अपने debug adapters को आसानी से Zed में integrate कर सकते हैं
inline variable values support
- inline variable values दिखाने की सुविधा DAP नहीं बल्कि LSP का हिस्सा है, इसलिए पारंपरिक तरीके से यह तभी उपलब्ध होती है जब DAP और LSP दोनों साथ जुड़े हों
- regular expression जैसे simple matching तरीकों में scope, comments आदि के कारण सटीकता कम हो जाती है
- Tree-sitter का उपयोग करके चल रहे code के scope के भीतर variables की पहचान अधिक सटीक ढंग से की जाती है
- अलग LSP integration के बिना भी
.scm files के ज़रिए language-specific support संभव है
- launch के समय Python, Rust, Go का support है, और आगे और भाषाएँ जोड़ी जाएँगी
- Zed, Tree-sitter के creators द्वारा बनाया गया editor है
आगे की योजना
- नए views: watch list, memory view, disassembly view, stack trace जैसे advanced features जोड़े जाएँगे
- auto-configuration: और भाषाओं व build systems के लिए automatic setup support बढ़ाने का लक्ष्य है
- polish और expansion: Discord, GitHub आदि के ज़रिए feedback लेकर सक्रिय रूप से सुधार जारी रखने की योजना है
परिशिष्ट
- Zed को macOS और Linux पर इस्तेमाल किया जा सकता है
- developers की hiring चल रही है (रुचि हो तो official site देखें)
2 टिप्पणियां
क्या कोई Java में Zed इस्तेमाल करता है...? हाहा
Hacker News राय
यह देखकर सच में खुशी हो रही है कि debugger पर काम आगे बढ़ रहा है। यही वह मुख्य फीचर था जो मुझे पूरी तरह Zed पर स्विच करने से रोक रहा था। हालांकि, इसे अभी "आ गया" कहना थोड़ा जल्दबाज़ी होगी। watch window, stack trace view की कमी और data breakpoint का कोई ज़िक्र न होना खटकता है, इसलिए मैं इसे अभी beta मानता हूँ। मुझे पता है कि ये फीचर कभी न कभी जुड़ेंगे, लेकिन अभी जो दिया गया है वह मेरे debugging sessions के 97% को संभालने के लिए पर्याप्त नहीं है। साथ ही, multiple debugging sessions support और multithreaded debugging की योजना का ऐलान में और स्पष्ट ज़िक्र होता तो अच्छा लगता। खासकर RemedyBG की तरह किसी खास thread को "freeze" करना या सिर्फ एक को "solo" चलाना जैसी multithreaded debugging की cool ideas के बारे में भी जानना चाहूँगा
नमस्ते Laserbeam, मैं वही developer हूँ जिसने debugger बनाया है और वही पोस्ट लिखी है। basic stack trace view पहले से supported है। जल्द ही multi-buffer system के भीतर stack trace view जोड़ा जाएगा, और अभी भी debugging session के दौरान "show stack trace" action से multi-buffer में call stack फैलाकर हर frame देखा जा सकता है। बस, यह अभी Zed के मानकों के हिसाब से high quality तक नहीं पहुँचा है, इसलिए हमने इसे खुलकर promote नहीं किया। watch variables/expressions feature का PR भी कुछ ही दिनों में merge होने वाला है। feature पूरा हो चुका था, लेकिन release के ठीक पहले पर्याप्त testing न हुई functionality जोड़ने में हमें सावधानी रखनी पड़ी। data breakpoint एक अहम priority है, लेकिन कुछ समय तक हमारा focus automatic setup पर रहेगा, इसलिए सटीक timeline बताना मुश्किल है। multiple sessions और multithreaded debugging भी अभी साथ में supported हैं; सुधार की गुंजाइश है, लेकिन basic support मौजूद है
ब्लॉग पोस्ट में बताया गया है कि advanced views पर काम चल रहा है। यह पहली release और announcement foundation बनाने पर केंद्रित है। आगे watch list, memory view, disassembly view, stack trace view जैसे advanced views जोड़े जाएंगे [संबंधित लिंक]
मेरे debugging sessions तो हमेशा सिर्फ सामान्य breakpoints और stepping से ही चलते हैं। इसलिए मेरे लिए यह पर्याप्त है
मैं भी सहमत हूँ, लेकिन Zed team की development speed देखकर लगता है कि ये फीचर जल्दी ही आ जाएँगे
मैंने अभी debugger इस्तेमाल नहीं किया है, लेकिन Git features को लेकर मेरी भी कुछ ऐसी ही भावना है। Zed में basic Git features हैं, लेकिन यह अभी मेरे पूरे existing workflow को replace करने के लिए काफी नहीं है। उम्मीद है कि Git पर development भी लगातार focus में रहेगी
Zed वाकई एक बढ़िया editor है। मैं हाल ही में neovim से zed पर आ रहा हूँ और काफी संतुष्ट हूँ। सब कुछ बहुत तेज़ चलता है और vim bindings भी अच्छी तरह integrated हैं। agent mode भी सुविधाजनक है। VSCode के मुकाबले extension ecosystem अभी छोटा है, लेकिन मुझे जिन कामों की ज़रूरत थी उनमें से बहुत कुछ यह कवर कर लेता है। debugger अब तक इसकी बड़ी कमी था, इसलिए इसका जुड़ना सच में स्वागतयोग्य है
यह जानने की उत्सुकता है कि vim bindings कितनी "real vim" जैसी लगती हैं। ज़्यादातर vim emulators काफी करीब तो होते हैं, लेकिन इतने आधे-अधूरे कि key input बार-बार गड़बड़ा जाता है और वही ज्यादा frustrate करता है। कभी-कभी तो ऐसा editor बेहतर लगता है जिसमें vim जैसा एहसास ही न हो, बजाय उस editor के जिसमें उँगलियाँ बार-बार "गलत" पड़ती रहें
Zed में Rust code autocomplete कैसा है, यह जानना चाहता हूँ। अगर Windsurf या Cursor की तरह "tab-tab-tab" करके सब कुछ बहुत natural तरीके से autocomplete हो जाए तो सच में अच्छा होगा। खासकर TypeScript या scripting languages में इस तरह की autocomplete लगभग refactoring automation जैसी लगती है। IntelliJ/RustRover ने JetBrains model या Co-pilot के साथ भी Cursor या Windsurf के स्तर को नहीं छुआ। मुझे लगता है यह Rust की अपनी प्रकृति की वजह से है। 1) क्या Rust में अब ऐसा natural autocomplete संभव हो गया है, और क्या यह Zed में काम करता है? 2) Zed का अनुभव Cursor, Windsurf के मुकाबले कैसा है, और RustRover तथा JetBrains के Rust AST को संभालने के तरीके की तुलना में कैसा लगता है?
Zed ऐसा लगता है जैसे उसने वह हासिल कर लिया जो Lapce, Helix, Neovim अब तक नहीं कर पाए। 2021~2022 के आसपास जब मैंने Helix इस्तेमाल किया था, तब bugs और integration की कमी के कारण आखिरकार छोड़ना पड़ा, खासकर PHP support लगभग न के बराबर था जो मेरी पिछली कंपनी में ज़रूरी था। Neovim सबसे आरामदायक था, लेकिन लोकप्रिय community plugins में कई बहुत सख्त style वाले थे और alternative plugins बहुत slow थे। एक stable environment बनाने के लिए बहुत ज़्यादा विकल्पों पर सोचना पड़ता था, जो थका देता था। Lapce बस "VSCode clone" जैसा लगा, उसमें क्या खास है समझ नहीं आया। अभी भी वह daily driver बनने लायक नहीं लगता। उस हिसाब से Zed बहुत कम समय में मेरा पसंदीदा editor बन गया है, और इन दिनों मैं इसके लिए रोज़ आभारी महसूस करता हूँ। debugger का जुड़ना भी बहुत अच्छा लगा
PHP support के साथ "(क्योंकि वह मेरी पिछली कंपनी थी)" जैसी सफाई की ज़रूरत नहीं है
इसे "VSCode clone" कहना भी दिलचस्प नज़रिया है। मानव इतिहास के सबसे लोकप्रिय editor के लिए यह एक मज़ेदार व्याख्या है
Zed को धीरे-धीरे एक polished, lightweight और feature-rich IDE बनते देखना प्रभावशाली है। मेरे हिसाब से DAP और LSP पिछले 10 सालों में programming tools में हुई सबसे बड़ी innovations हैं
शुरू में मेरी Zed में दिलचस्पी थी, लेकिन जैसे ही इसमें "AI" integrate होना शुरू हुआ, मेरी रुचि कम हो गई। अब "AI" बहुत ज़्यादा हो चुका है और उससे थकान होने लगी है। जब तक कुछ बेहतर नहीं आता, मैं Neovim ही इस्तेमाल करता रहूँगा, और शायद ऐसे बदलाव "AI bubble" फूटने के बाद ही आएँगे
Zed पहला editor है जिसने मुझे AI features आज़माने का मन कराया। इसकी बुनियाद कुल मिलाकर बहुत मजबूत लगी, और AI की मौजूदगी भी दूसरे editors की autocomplete जैसी ही सीमित लगती है। इसमें ऐसा एहसास है कि "आपको AI नहीं, एक अच्छा तेज़ editor चाहिए; हमने वह बनाया है और AI features भी जोड़ दिए हैं।" जबकि competitors में vibe अक्सर "हम AI पहले हैं, editor बाद में" जैसी लगती है। Zed का केंद्र अलग है
neovim के बारे में पढ़ते हुए यह देखकर हैरानी हुई कि उसे दो AI products sponsor भी कर रहे हैं। यह सीधे AI integration जैसा नहीं है, लेकिन अब इससे पूरी तरह बचना भी मुश्किल होता जा रहा है
मैं तो बस AI से जुड़ी सारी options बंद करके इस्तेमाल करता हूँ। editor काफ़ी अच्छा है। अभी भी merge conflict सुलझाने के लिए VSCode खोलना पड़ता है, लेकिन कुल मिलाकर संतुष्ट हूँ
यह जानना चाहता हूँ कि Zed के AI features वास्तव में कितने intrusive हैं, और क्या उन्हें settings से disable किया जा सकता है
रोज़मर्रा में Zed इस्तेमाल करते समय AI features बिल्कुल परेशान नहीं करते। कभी-कभी काम आ जाते हैं, लेकिन मैं उन्हें अक्सर इस्तेमाल नहीं करता
Linux support आने के बाद से मैं हर बार यह देखता हूँ कि क्या normal display (LoDPI) support आया या नहीं। अभी तक न आने से निराशा होती है
यह सच में frustrate करने वाली बात है। text rendering तो code editor की बुनियाद है, लेकिन लगता है Zed team में कोई normal (non-retina) screen इस्तेमाल ही नहीं करता। संबंधित GitHub issue लिंक
एक workaround के तौर पर BetterDisplay (free tool) install करके LoDPI screen को HiDPI में बदल दें, तो text rendering ठीक हो जाती है
मैं Linux पर 1920x1200 laptop screen में इसे रोज़ इस्तेमाल करता हूँ और कोई दिक्कत नहीं दिखती
अगर Windows support भी नहीं है और Linux पर भी normal screen support नहीं है, तो क्या यह असल में Mac-centric company नहीं है?
मैं अभी Python project में Pyright के साथ काम करते हुए Cursor की जगह Zed पर जाना चाहता हूँ, लेकिन battery usage इतना ज़्यादा है कि उसे justify करना मुश्किल है। यह issue GitHub पर पहले से दर्ज है, और team इसे priority नहीं दे रही, जो काफ़ी निराशाजनक है
मुझे लगता है Zed असली product engineering का उदाहरण है। यह कोई और Chrome engine repackaging नहीं है, इसलिए यह सच में एक ताज़गी भरा विकल्प है
ईमानदारी से कहूँ तो इसमें कुछ slow हिस्से देखकर हैरानी हुई। tab list से file switch करते समय delay है, और typing response भी Emacs (lsp-mode enabled) या web browser से धीमा लगता है। memory usage भी Emacs से लगभग 60MiB ज़्यादा है। हाँ, startup speed वाकई बहुत तेज़ है। लेकिन सिर्फ "fast editor" के slogan के हिसाब से देखें तो यह Emacs Lisp + C core से भी धीमा पड़ता है। plugin architecture को देखकर लगा कि शायद यह WASM में compile होकर VM पर चलता है। क्या यही वजह हो सकती है?
यह कैसे हुआ कि zed, emacs से भी धीमा लगने लगा? मेरे अनुभव में zed लगभग lag-free है। editing, lsp, file switching सब तुरंत होता है। उलटे emacs को तो latency issues की वजह से कई बार छोड़ना पड़ा है, खासकर remote development environment में
plugins के WASM VM में चलने की वजह से slow होने वाले सवाल पर, मैंने जितने plugins देखे हैं वे बस server launching जैसी चीजें करते हैं, इसलिए typing responsiveness से उनका सीधा संबंध नहीं है। मुझे ज़्यादा संभावना GPU usage की लगती है। GPU compositing में delay आना आसान है, और यह OS-level rendering के ऊपर भी चढ़ सकता है। याद है emacs भी event loop को bypass करके UI सीधे refresh करने जैसी tricks इस्तेमाल करता था, जिससे compatibility issues आते थे
emacs में dape package नाम का एक अच्छी तरह designed DAP-based debugger है। संबंधित लिंक यह बिना dependencies के design किया गया है, इसलिए भविष्य में शायद इसे default emacs में शामिल किया जा सके
यह rendering pipeline की समस्या भी हो सकती है। आप कौन-सा operating system इस्तेमाल कर रहे हैं?
Zed team से मेरी एक गुज़ारिश है कि proper C और C++ language detection दी जाए। लगभग हर editor C को C++ की तरह treat करने की गलती दोहराता है (C, C++ नहीं है, और दोनों को मिलाना नहीं चाहिए)। compile_commands.json में C standard दिया हो तब भी कई बार C++ syntax errors वाले code को C++ समझ लिया जाता है। अगर सिर्फ language detection ठीक हो जाए, तो यह बहुत अच्छा editor है