- Atom’u yapan ekip, hafif ama IDE düzeyinde özelliklere sahip bir editör hedefini Zed’de Rust·GPU hızlandırmalı UI·CRDT·Tree-sitter temeliyle yeniden kuruyor
- 2017’de Atom’un sınırları, ekip yetkinliğinden çok Electron ve JavaScript’in bellek·rendering kontrolündeki yetersizliğinde daha belirgin hale geldi ve bu da “yeniden başlamamız gerekiyor” kararına yol açtı
- Rust, Zed’in paylaşımlı bellek ve çok iş parçacıklılığını daha güvenli ele almasını sağlıyor; copy-on-write B-tree ve
Arctabanlı rope yapısı sayesinde arka plan işleri için gereken O(1) snapshot mümkün oluyor - Zed, GPUI, Tree-sitter uzantıları,
editorcrate’i, multi-buffer, SumTree gibi temel katmanları doğrudan sahiplenerek ince ayarlı kontrol kazanıyor; bunun karşılığında geliştirme hızı ve onboarding maliyetini üstleniyor - Kullanıcı için en önemli sonuç hızlı bir editör; Rust ve
cargotabanlı yapı, açık kaynak katkıcılarının build alıp değişiklik denemesini kolaylaştırıyor ve merge güvenilirliğini artırıyor
Atom’un vizyonu Zed’e nasıl taşındı
- Zed’in hedefi, Atom’un başta peşinden gittiği vizyonun daha rafine edilmiş bir biçimine yakın
- Hafif, minimal ve bir metin editörü gibi hissettiren bir araç
- Gerektiğinde IDE seviyesinde özellikler sunarken UI ve kullanım deneyimi yavaş ya da ağır hissettirmeyen bir araç
- Genişletilebilir ve script edilebilir bir editör
- Emacs’in genişletilebilirliği ilk vizyonu etkiledi, ancak yalnızca karakter düzeyinde manipülasyon yapan bir yaklaşımdan ziyade daha zengin metin temsiline erişen bir yön isteniyordu
- Tree-sitter, metni karakterlerden çok yapısal olarak ele almayı sağlayan temel katman; Zed henüz script edilebilir değil ama hedef o yönde
- Atom web teknolojileri üzerine başladı; o dönemde Rust yoktu ve C ya da C++ ile native bir editör yapmanın da zor olacağı düşünülüyordu
2017’de neden “yeniden başlama” kararı alındı
- Atom, 2017’de Teletype’ı çıkardıktan sonra, darboğazın ekipteki acemilikten çok platform kısıtları olduğu daha net hissedilmeye başlandı
- JavaScript dizileri nesne işaretçileri dizisi gibi çalıştığı için, dolaşım sırasında pointer takibi maliyeti oluşuyordu; bellek yerleşimini ve garbage collector duraklamalarını doğrudan kontrol etmek de zordu
- Satır yerleşimini hızlı üretmeye çalışırken bile iframe, Canvas ve metin ölçüm API’lerini dolaylı biçimde bir araya getirmek gerekiyordu; imleç konumu ya da satır yerleşimi gibi basit görünen işler bile karmaşıklaşıyordu
- Electron, Atom’u yapmak için doğmuş olsa da, kod editörünün gerektirdiği seviyede kontrol sağlamak zordu
- Daha basit uygulamalarda kullanılabilir, ancak bellek ayak izi büyük olma dezavantajı var
- Kod editörlerinde rendering, giriş ve metin işleme tarafında daha doğrudan kontrol gerekiyor
- 2017’de bir noktada, Atom ile istenen seviyeye ulaşılamayacağı düşünülerek, çekirdeği Rust ile yazıp Electron’u sunum katmanı olarak tutma fikriyle yola çıkıldı
Rust ve GPU hızlandırmaya geçiş süreci
- Zed’in teknik tercihleri baştan çizilmiş sabit bir plan değil, kısıtlar tek tek kaldırıldıkça şekillendi
- Önce çekirdeği Rust ile yazma yönü değerlendirildi
- Sonra Electron bırakıldı ve kendi UI framework’ünü yapma noktasına gelindi
- Pathfinder kullanıldı, ancak fazla yavaş bulunduğu için ekip kendi shader’larını ve signed distance field yaklaşımını öğrenip uyguladı
- GPU hızlandırma, “GPU hızlandırmalı editör” sloganından çok, ekrandaki her pikselin rengini paralel hesaplayabilen donanımı doğrudan kullanmanın daha hızlı olabileceği düşüncesiyle seçildi
- Zed, DOM node’larını ayarlamak yerine, ekrandaki piksellerin nasıl çizileceğine daha yakın bir seviyede rendering’i kontrol etmeyi seçti
- Performans iyileştirmesi örneği olarak
find-all-matches, önceden yaklaşık 1 saniye sürerken Sublime Text yaklaşık 200ms civarındaydı; Zed’de ise yalnızca iç API’leri çağıran yüksek seviyeli kodla release build’de 4ms seviyesine indi - Rust’ın derleme süreleri hâlâ bir şikâyet konusu, ancak yüksek seviyeli soyutlamalar üzerinde bile performans beklenebilmesi Zed geliştirmesinde faydalı oldu
JavaScript/C++ sınırı ve Rust’ın çok iş parçacıklılığı
- Atom’da da yoğun biçimde C++ kullanıldı, ancak JavaScript uygulama kodu ile C++ kütüphane kodu arasındaki sınır büyük bir maliyet oluşturuyordu
- İşleri arka plan thread’lerine taşımak için ilgili alt sistemleri C++ tarafına indirmek gerekiyordu
- Paylaşımlı bellek kullanmak için C++ katmanı kurup ardından yeniden JavaScript API tasarlamak gerekiyordu
- Her şeyin JavaScript gibi görünmesini sağlarken mevcut özellikleri korumak da gerekiyordu
- Rust, çok iş parçacıklılığına uygun tasarımı sayesinde Zed’in istediği yaklaşıma daha iyi uyuyor
- Başlangıçta ebeveyn pointer’larına sahip, değiştirilebilir bir splay tree’yi Rust ile yazmaya çalışırken borrow checker ile çatışıldı; bu da gerçekten çalışan bir sistem kurulup kurulamayacağından şüphe ettirdi
- Sonrasında copy-on-write B-tree yapılırken
Arckullanıldı ve bu yapı doğal olarak çok iş parçacıklılığına uygun bir biçime dönüştü - Zed’in temel metin saklama yapısı olan rope, snapshot’ı arka plan thread’ine verirken yalnızca
Arcreferans sayacını artırmakla yetinebiliyor
Tüm stack’e doğrudan sahip olma tercihi
- Zed, parsing’den sorumlu Tree-sitter’dan GPU hızlandırmalı UI framework’ü GPUI’ye kadar büyük blokları doğrudan sahiplenme yolunu seçti
- Bu yapı, ihtiyaç duyulan davranışları kendisinin belirleyip uygulamasını sağlıyor
- Dil uzantılarında WASM kullanmak istendiğinde, Tree-sitter’a bu özellik eklenebildi
- Metin editörü için kritik olan text rendering yöntemini dış bir UI framework’üne bırakmak gerekmiyor
- GPUI 2019’da başladı; o sırada mevcut UI framework’leri ya Zed’in ihtiyaç duyduğu davranışı karşılamıyordu ya da ekip onları yeterince iyi anlamıyordu
- Alt seviye primitive’leri doğrudan anlayıp sistem kurma yaklaşımı, GPUI’de bir hayatta kalma stratejisine yakındı
- Maliyeti de açık
- Her şeyi doğrudan yapmak uzun zaman alıyor
- Geliştirme hızı yavaşlıyor
- Yaygın bir framework kullanılmadığı için yeni gelenlerin yaklaşık 300 bin satırlık kod tabanını baştan öğrenmesi gerekiyor
- Buna karşılık, o kodu yazmış kişilerin içeride olması yeni ekip üyelerine açıklamayı mümkün kılıyor; zaman geçtikçe doğrudan sahip olmanın maliyetinin azalacağı ve avantajlarının birikeceği düşünülüyor
- loungy gibi GPUI üzerinde başka uygulamaların geliştirildiği örnekler de ortaya çıkmış durumda
Nerede mükemmelleştirmek, nerede hızlı geçmek gerekir
- Zed ekibinin ölçütü, yalnızca gerekeni yapmak ve o kapsam içinde olabildiğince iyi yapmaktır
- İleride gerekip gerekmeyeceği bilinmeyen özellikleri tahmin ederek zaman harcamak yerine, gerçekten ihtiyaç duyulan şeyler niyet ve dikkatle uygulanıyor
- Tamlık ölçütü, kodun bulunduğu katmana göre değişiyor
- GPUI gibi tüm uygulamanın bağımlı olduğu katmanlarda yüksek tamlık gerekiyor
- SumTree gibi kod tabanı boyunca kullanılan ve performans açısından kritik veri yapıları da dikkatle ele alınıyor
- Uç noktalardaki belirli performans iyileştirmeleri ise aşırı parlatılmadan, amaca yetecek seviyede bırakılıyor
- SumTree, edge case’leri doğrulamak için rastgele testler kullanıyor
- Mükemmeliyetçiliğin öğrenmeyi engellemesine izin verilmemeli; doğrudan yazılmış bir kodu uzun süre işletip tavizlerini yaşadıktan sonra yeniden yazmak, öğrenmenin yeniden yazıma yansıması için meşru bir gerekçe oluşturuyor
CRDT ve buffer yapısından çıkarılan dersler
- Atom’un ilk buffer’ı JavaScript string dizileri, yani satır dizileriydi
- Zed’in buffer’ı, çok iş parçacıklılığına uygun ve snapshot alınabilen bir copy-on-write B-tree; ayrıca gereken çeşitli öğeleri indeksliyor
- CRDT baştan beri kendiliğinden seçilmiş bir yol değildi; çeşitli makalelerin okunduğu bir araştırma döneminden sonra bugünkü yaklaşıma ulaşıldı
- CRDT implementasyonu iki ya da üç kez yeniden yazıldı, ancak yaklaşımın kendisi büyük ölçüde korundu
- İlk kod editörü olan Atom’da daha hızlı ve daha kaba bir “worse is better” yaklaşımı kullanılmıştı; bu deneyim gerçek acı noktalarının nerede olduğunu görmeyi sağladı
- Bugün yeniden başlanacak olsa, buffer basit bir satır dizisi olarak kurulmazdı; geçmişteki yavaş örnekler ve edge case’ler daha güçlü bir tasarımı gerekli kılıyor
Zed’de özellikle emek verilen katmanlar
- GPUI, tümüyle yeniden yazıldığı için yüksek tamlığın hedeflendiği alanlardan biri
editorcrate, ham buffer metnini ekrandaki satırlara dönüştüren çeşitli katmanları içeriyor- Tab genişletme
- Soft wrap
- Blok dekorasyonları ekleme
- Fold işleme
- Bu dönüşüm katmanları, özellik tabanlı rastgele testler kullanan tutarlı bir test stratejisine sahip
- multi-buffer, farklı buffer’ların parçalarını tek bir yapı içinde birleştiren bir sistem ve bu da çekirdek alanlardan biri olarak ele alınıyor
- 2021’de rastgele testlerin bulduğu edge case’leri azaltıp debug etmek için birkaç gün tamamen ayrıldığı olmuştu
- Rust ile yazılmış bu katman hata yaptığında, editörün bir köşesinde basitçe bir stack trace görünmek yerine program panic ile kapanabildiği için doğruluk çok önemli
- Büyük dosyalar açılırken kullanıcının hiç geri bildirim almadan beklemesini azaltmak amacıyla daha streaming dostu giriş ve yükleme iyileştirmeleri de tartışıldı; ilgili optimizasyonların preview sürümüne girmesi planlanıyor
Kullanıcı ve katkıcı açısından kalan fark
- Son kullanıcı için nihayetinde en önemli şey editörün hızlı olması olabilir
- Geliştirici araçları ve editörlerde, kullanıcıların doğrudan kod tabanına katkı verme ihtimali yüksek olduğu için, uygulama dili ve build sistemi katkı olasılığını etkiler
- Zed C++ ile yazılmış olsaydı, doğrudan değişiklik yapmaya çalışan kullanıcı sayısı daha az olabilirdi
- Rust ve
cargo, projeyi build etmeyi ve değişiklik denemeyi kolaylaştırıyor; CMake ya da Gyp öğrenme gereğini azaltıyor - Rust derleyicisinin katılığı, dış katkıları kabul eden bir projede merge güvenilirliğini artırmaya yardımcı oluyor
- Zed, frame sürelerini 3ms’nin altında tutmak istiyor ve bu performans hedefi nedeniyle CPU rasterization yerine GPU hızlandırmalı bir UI framework’ü seçiyor
- Zig’e de ilgi var, ancak hem sunucu hem frontend’in Rust olduğu tek dilli yapı kendi avantajlarını sunuyor
1 yorum
Hacker News yorumları
Zed’in özel UI framework’ü şu an eğlenceli görünebilir, ama erişilebilirliği uygulamak zorunda olduklarını fark ettikleri anda iş değişecek gibi
Performanstan ödün vermeden özel bir framework’te erişilebilirlik uygulamak, platforma göre bir sürü dağınık iş gerektirir. Zed kendini sadece kullanmayabileceğiniz bir editör olarak değil, iş birliği aracı olarak konumlandırıyor; bu yüzden ekipteki tüm geliştiricilerin kullanabilmesini sağlamak şart
Bir ekran okuyucu kullanıcısı olarak, VoiceOver’ın yalnızca boş bir pencere gördüğü Rust tabanlı “modern” araçlardan bıktım. Birkaç düğmeye aria etiketi koyup odağı düzenlemenin yeterli olduğu web uygulamalarına kıyasla, tüm kontrolleri her işletim sistemine açmak zorunda olan özel UI çok daha zor
Neyse ki https://accesskit.dev/ gibi AccessKit ortaya çıktı ve işi biraz kolaylaştırabilir; ama editör gibi büyük bir uygulamaya ne kadar uygun olduğundan emin değilim
GPUI’yi sıfırdan yaptıkları için Swift’in ya da web tabanlı uygulamaların sahip olduğu erişilebilirlik özelliklerini aynen kullanamıyorlar; Zed tarafındaki çalışmalarla GPUI özelliklerinin genişletilmesinin birlikte gerektiğini söylüyorlar
Ancak erişilebilirlik tartışması diye verdikleri https://github.com/zed-industries/zed/pull/1297 bağlantısı, geri/ileri düğmeleriyle ilgili bir GitHub issue’su olduğu için işe yaramıyor. Muhtemelen https://github.com/zed-industries/zed/discussions/6576 bağlantısını vermek istemişler
İlgili belge: https://zed.dev/docs/themes
Erişilebilirliği düşünmüşler, ama henüz fiilen uygulama aşamasına gelmemiş
Çok yakın zamana kadar yalnızca mevcut C framework’lerine binding’ler ya da kavram kanıtı aşamasındaki GUI kütüphaneleri vardı. İleride daha iyi olacaktır, ama erişilebilirlik özelliklerine bağımlı olanların hayal kırıklığını da anlıyorum
Yine de birçok projenin önce sağlam bir GUI kütüphanesi oluşturup erişilebilirlik özelliklerini sonra eklemeye çalışması muhtemel
Pek çok startup, farklılaştırıcı unsur bile olmayan parlak özelliklere kaynak harcayıp başarısız oldu
Yerel olmayan UI ile başarılı olan ürünler genelde web teknolojileri ya da Qt gibi olgun framework’ler kullanıyor; ya da 30 yıllık Blender gibi istisnalar. Apple da iTunes’ta benzer bir şey yaptı, ama Windows için iTunes tatsızdı; insanlar buna rağmen iTunes’u kullandı sadece
GPUI gibi bir framework geliştirme cazibesini anlıyorum, ama yazı bunun Zed’in çözmeye çalıştığı sorunla ne ilgisi olduğunu açıklamıyor
Yalnızca piksellere bakıp insan gibi anlayan, OCR ile metni ayrıştıran türden araçlardan söz ediyorum
VoiceOver gibi teknolojilerin gerçek pencere tanımını ve öğeleri programlama düzeyinde bildiğini ve bunlardan yararlandığını anlıyorum
GPU render hızı istedikleri için VoiceOver’a “boş pencere” gibi görünen projelerde, böyle bir yöntem en azından asgari bir alternatif olabilir mi diye düşünüyorum
Öyleyse oyunlar gibi GPU ile render edilen tüm içeriklerin erişilemez olduğu anlamına mı geliyor, onu da merak ediyorum
iPhone’da “GPT Explains” adlı bir Apple Kestirmesi oluşturdum; telefonun arkasına iki kez dokununca ekran görüntüsü alıp OpenAI’ye gönderiyor ve görünen içeriğin açıklamasını, İngilizce olmayan metinlerin İngilizce çevirisini, meme’lerdeki iddialara karşı argümanları vb. geri döndürüyor
API anahtarı çıkarılmış kopyası burada: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
Yeni metin editörü trendine atlamadan önce, kullanıcının kabul etmesi gereken lisansa bir bakın diye bırakıyorum
“Solution kullanımı sırasında oluşturulan kullanıcı içeriğinden oluşan Customer Data, User Content olarak sınıflandırılır. User Content yalnızca Editor içinde proje paylaşımını seçip diğer Zed kullanıcılarıyla iş birliği yaptığınızda kullanıcı ortamınızdan aktarılır.”
“[...] Zed’in söz konusu User Content’e erişimi hata ayıklama ve Solution’ı iyileştirme ile sınırlıdır.”
Ayrıca yorum yapmayacağım; herkes kendi sonucunu çıkarsın
İş birliği yapmak için projeyi başkalarıyla paylaşmayı seçtiyseniz, o proje içeriğinin makinenizin dışına aktarılması doğal. Yoksa nasıl çalışacak?
Bu yazı yüzünden Zed’i denedim ve oldukça umut verici göründü. Ama uzak host/devcontainer desteği olmadığı için kullanamıyorum
VSCode’un bu özelliği iş akışımın merkezinde. Aslında Mac’te geliştirme yapmak istemiyorum; Mac’i, kod yazdığım VM’lere ve container’lara açılan bir portal gibi kullanmak istiyorum
Projeleri ayırmada çok yardımcı oluyor; geliştirme ortamını veya bağımlılıkları gerçek host makinede tutmadığım için güvenlik açısından da daha iyi
VSCode’un uzak host/devcontainer özelliğinin sıradan bir uzak oturuma göre ne avantaj sağladığını merak ediyorum
Geliştiricilerin geliştirmeye farklı açılardan nasıl baktıklarına dair düşünce tarzlarını çok iyi gösteren harika bir röportaj; şiddetle tavsiye ederim
Yalnız bir konuda itirazım var
“Zig ile yapılmış bir metin editörü için en uygun adı Zed zaten almış” değil; o ad “Zag” olmalı ;)
zediçindeedvar.ed,ex,vi,edlinin öncülü olan ve hâlâ varlığını sürdüren Unix tarzı bir satır editörüdürhttps://en.wikipedia.org/wiki/Ed_(text_editor)
Öte yandan
ag, yani the silver searcher da harika, ama bence Zed kod aramadan çok kod düzenlemeye daha yakınhttps://geoff.greer.fm/ag/
Zed kullanmıyorum ama José Valim’in canlı kodlamada kullandığını gördüm. Çoğunlukla VSCode kullanıyorum; Zed’de gördüğüm bir özellik oldukça cazipti
“Find All” yaptığınızda, VSCode’daki gibi eşleşen tüm dosyalardan parçalar sonuç panelinde görünüyor; ama orada arama sonucu parçalarını doğrudan düzenleyebiliyordunuz ve çoklu imleç gibi normal düzenleme özelliklerini de aynen kullanabiliyordunuz
VSCode’da arama sonucuna tıklayıp dosyayı açmak ve değişikliği orada yapmak gerekiyor; bu yüzden oldukça hoş ve etkileyiciydi. Geçiş yapacak kadar değil, ama VSCode sinirimi her bozduğunda ara sıra aklıma geliyor
occurvemulti-occurvardı ve bu tür işler yapılabiliyor. Gerçekten harikaSon zamanlarda ripgrep gibi araçların arayüzleri de düzenlenebilir mod sunuyor; refactoring için çok kullanışlı. Elbette dosya adlarını da topluca düzenleyebiliyorsunuz
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...
Saçma gelebilir ama VSCode yerine JetBrains kullanmamın başlıca nedenlerinden biri, dizin içinde arama yapıp bunu gezinme panelinde açabilmek
Bu yorumu görünce unutmuş olduğumu hatırladım, tekrar kullanmayı denemeliyim
https://marketplace.visualstudio.com/items?itemName=jakearl....
Sevdiğim numaralardan biri, çoklu imleçle düzenleme yapıp satır sonuna veya sonraki kelimeye gitme kısayollarını kullanarak toplu değişiklik yapmak
Bunu birden çok dosyaya yayarak yapabilmek güzel olurdu
Windows veya Linux’ta çalışmıyor. Desteklenirse yeniden haber verilmesini isterim
Harika bir röportaj
Neyi fazla cilalayacağı üzerine derin düşünmelerini sevdim. Benim en iyi işlerim de genelde ikinci, üçüncü, dördüncü tur civarında ortaya çıkmış gibi geliyor
Ayarları script’lerle ele alma özelliği için planları nedir merak ediyorum. Zed’i henüz çok kullanmadım; şu anda mümkün mü? Neon gibi bir şey VSCode ile eski Atom kullanıcıları arasındaki boşluğu kapatmaya yardımcı olur mu?
https://github.com/neon-bindings/neon
— Brooks, Mythical Man-Month
v2’leri görmek her zaman ilginç. Özellik şişkinliği yüzünden felakete dönüşenleri de gördüm, sade ve çevik hâle gelip harikalaşanları da
Günümüzde web uygulamaları alanında araç o kadar çok ki, bu riskin yalnızca v2’ye değil v1’e de aynı şekilde uygulanıp uygulanmadığını merak ediyorum. Bugünün v1’lerinde bile şaşırtıcı derecede şişkin örnekleri sıkça gördüm; çoğu zaman özellikle daha az şey yapan araçları aramam gerekiyor
Zed’i denedim ve VSCode’a benzer hissettirdi. Live Share’den daha iyi bir çok oyunculu özelliği olduğunu biliyorum, ama dışarıdan bakınca geçiş yapmak için daha ikna edici nedenlere ihtiyaç vardı
Zed, Xcode’un yerini alabilirse daha fazla denemek isterim. derived data silmekten build folder temizlemeye, rastgele çöküşlere kadar Xcode kullanmak acı verici
Android Studio’nun geliştirici deneyimiyle karşılaştırınca bambaşka. iOS geliştirmede de hep Android Studio benzeri bir deneyim istemiştim
Yerel uygulamaları gerçekten seviyorum ama şu anda VS Code’a bağlı durumdayım. VS Code’da imleç yanıp sönmesinin bile çok güç tükettiğini görmek içimi acıtıyor
Zed’i kısa süre denedim ama iş akışıma uyduramadım. Hafif ve hızlı olması hoşuma gitti. VS Code süreçleri yaklaşık 3GB iken Zed 300MB; belleğin onda biri anlamlı bir fark
Ama VS Code’un sunduğu Jupyter Notebook desteğine kesinlikle ihtiyacım var ve Mac’ten Ubuntu makinesine uzaktan geliştirme yapma biçimine de fazla alıştım. VS Code bunu çok iyi yapıyor
Umarım Zed yeterince uzun süre dayanır da iş akışımı destekler hale gelir
Belki de herkes daha fazla eklentiyi etkin bırakıyordur
Lindy etkisine https://en.wikipedia.org/wiki/Lindy_effect göre, bir şey görmek için muhtemelen bir yıl daha gerekecek
About sayfasına baktım; canlı kodlama özelliği kullanışlı görünüyor. Geliştiriciler de heyecanlıdır herhalde. Algoritma yazılabilen, performans optimize edilebilen, GPU programlama da yapılabilen eğlenceli bir proje çünkü
Ama Vim ve terminal multiplexer’larının özellik denkliğine muhtemelen asla ulaşamayacak bir başka metin editörüne kimin ihtiyacı var, diye düşünüyorum
VS Code görece yakın zamanda birden ortaya çıktı ve birçok kişi kullanıyor; bu da Vim’den sonra da yeni editörler için fırsat olduğunu gösteriyor
Zed’in diğer geliştiricilerin uzun kuyruk taleplerini karşılayacak kadar ivme kazanıp kazanmayacağını göreceğiz, ama kullanıcı kazanmak için rekabet eden daha fazla ürünün çıkması oldukça heyecan verici
Vim’i taklit etmeye gerek kalmadan Neovim’i ve tüm eklentilerini olduğu gibi kullanabilirsiniz
JetBrains’in, Vim kullanıcılarının berbat dediği Vim taklidi eklentisini hâlâ sürdürmesi beni hâlâ üzüyor. IDE’de Neovim ön yüzünü yerel olarak uygularsa “Neovim’i ve ekosistemini tam destekliyor” gibi çok daha güçlü bir avantaja sahip olurdu; şu anda ise “Vim benzeri bir eklentisi var” seviyesinde kalıyor
Hoşunuza giden ve işi bitirmenizi sağlayan aracı kullanın. Buna Vim de dahil, ama Vim kullanmanın yeri doldurulamaz bir nimetmiş gibi davranılmasından bıktım
Daha iyi düşünen biri olmak, programcı olarak üretkenliğinizi herhangi bir araçtan katbekat fazla artırır
Zaten epey özellikli ve insanların memnun olduğu ya da en azından alıştığı editörler var. Yeni bir editör kendine nerede yer bulabilir?
“Çok oyunculu” hoş, ama daha çok bir uç durum gibi
İş modelinden de emin değilim. İnsanlar gerçekten kanalların, aramaların ve sohbetin kod editörüne entegre edilmesini istiyor mu? Şahsen neredeyse içgüdüsel olarak itici buluyorum ama belki sadece ben böyleyim