- Đội ngũ từng tạo ra Atom đang tiếp tục theo đuổi cùng một mục tiêu trong Zed: một trình soạn thảo nhẹ nhưng có tính năng cấp độ IDE, lần này được hiện thực lại trên nền tảng Rust · UI tăng tốc bằng GPU · CRDT · Tree-sitter
- Năm 2017, giới hạn của Atom bộc lộ không phải do năng lực của đội ngũ mà chủ yếu do thiếu khả năng kiểm soát bộ nhớ và render của Electron và JavaScript, từ đó dẫn đến kết luận rằng “phải bắt đầu lại”
- Rust giúp Zed xử lý shared memory và multithreading an toàn hơn, đồng thời cấu trúc rope dựa trên copy-on-write B-tree và
Arccho phép snapshot O(1) cần thiết cho các tác vụ nền - Zed tự sở hữu các tầng cốt lõi như GPUI, phần mở rộng Tree-sitter, crate
editor, multi-buffer và SumTree để đổi lấy khả năng kiểm soát chi tiết, đồng thời chấp nhận tốc độ phát triển chậm hơn và chi phí onboarding cao hơn - Kết quả quan trọng nhất với người dùng là một editor nhanh, còn cấu trúc dựa trên Rust và
cargogiúp các contributor mã nguồn mở dễ build và thử thay đổi hơn, đồng thời tăng độ tin cậy khi merge
Cách tầm nhìn của Atom được tiếp nối trong Zed
- Mục tiêu của Zed gần với một phiên bản được tinh luyện hơn của tầm nhìn mà Atom ban đầu theo đuổi
- Một công cụ nhẹ, tối giản và mang cảm giác như trình soạn thảo văn bản
- Một công cụ có thể cung cấp tính năng cấp độ IDE khi cần, nhưng UI và trải nghiệm sử dụng không chậm hay nặng nề
- Một editor có thể mở rộng và có thể script
- Tính mở rộng của Emacs đã ảnh hưởng đến tầm nhìn ban đầu, nhưng họ muốn đi theo hướng tiếp cận biểu diễn văn bản phong phú hơn thay vì chỉ thao tác ở mức ký tự đơn thuần
- Tree-sitter là nền tảng cho phép xử lý văn bản theo cấu trúc thay vì theo ký tự, và dù Zed hiện vẫn chưa hỗ trợ scripting, đó vẫn là hướng mà họ nhắm tới
- Atom khởi đầu trên nền tảng web, vào thời điểm đó Rust chưa tồn tại và họ cũng cho rằng việc tạo một editor native bằng C hay C++ là rất khó
Vì sao họ quyết định “bắt đầu lại” vào năm 2017
- Sau khi Atom phát hành Teletype vào năm 2017, nhóm bắt đầu cảm nhận rằng giới hạn của nền tảng là nút thắt lớn hơn sự non trẻ của đội ngũ
- Array trong JavaScript hoạt động giống như mảng con trỏ đối tượng, nên khi duyệt sẽ phát sinh chi phí đuổi theo con trỏ, đồng thời cũng khó kiểm soát trực tiếp cách bố trí bộ nhớ và các lần tạm dừng của garbage collector
- Ngay cả trong việc cố tạo layout dòng thật nhanh, họ cũng phải lách bằng cách kết hợp iframe, Canvas và API đo văn bản, khiến cả những việc tưởng đơn giản như vị trí con trỏ hay bố trí dòng cũng trở nên phức tạp
- Electron sinh ra để phục vụ việc xây dựng Atom, nhưng khó có thể cung cấp mức độ kiểm soát mà một code editor yêu cầu
- Nó vẫn có thể dùng cho các ứng dụng đơn giản hơn, nhưng có nhược điểm là memory footprint lớn
- Với code editor, cần khả năng kiểm soát trực tiếp hơn trong rendering, input và xử lý văn bản
- Vào một thời điểm trong năm 2017, họ kết luận rằng Atom không thể đạt đến mức mong muốn, và bắt đầu từ ý tưởng viết phần lõi bằng Rust nhưng vẫn giữ Electron làm tầng trình bày
Quá trình chuyển sang Rust và tăng tốc bằng GPU
- Lựa chọn công nghệ của Zed không đến từ một bản thiết kế cố định ngay từ đầu mà được định hình từng bước bằng cách loại bỏ dần các ràng buộc
- Trước hết họ xem xét hướng viết phần lõi bằng Rust
- Sau đó họ từ bỏ Electron và đi tới việc tự xây dựng UI framework riêng
- Họ từng dùng Pathfinder, nhưng vì quá chậm nên đã tự học và áp dụng shader riêng cùng signed distance field
- Việc tăng tốc bằng GPU không xuất phát từ khẩu hiệu “GPU-accelerated editor”, mà từ nhận định rằng dùng trực tiếp phần cứng có thể tính màu của từng pixel trên màn hình song song sẽ nhanh hơn
- Zed chọn hướng kiểm soát rendering ở mức gần với cách từng pixel trên màn hình được vẽ, thay vì thao tác trên các DOM node
- Một ví dụ cải thiện hiệu năng là
find-all-matches: trước đây mất khoảng 1 giây, trong khi Sublime Text gần khoảng 200ms, nhưng chỉ với mã cấp cao gọi API nội bộ, họ đã giảm xuống còn 4ms ở bản build release - Thời gian biên dịch của Rust vẫn là một điểm gây khó chịu, nhưng việc vẫn có thể kỳ vọng hiệu năng ngay cả trên các abstraction cấp cao đã tỏ ra hữu ích trong quá trình phát triển Zed
Ranh giới JavaScript/C++ và multithreading trong Rust
- Ngay cả ở Atom, họ cũng dùng khá nhiều C++, nhưng ranh giới giữa mã ứng dụng JavaScript và mã thư viện C++ trở thành một chi phí lớn
- Muốn chuyển công việc sang background thread thì phải hạ cả subsystem liên quan xuống C++
- Muốn dùng shared memory thì phải tạo tầng C++ rồi lại thiết kế API JavaScript phía trên
- Đồng thời vẫn phải làm sao để mọi thứ trông “đúng chất JavaScript” và giữ được các thuộc tính sẵn có
- Rust có thiết kế thân thiện với multithreading nên phù hợp hơn với cách mà Zed muốn xây dựng
- Ban đầu họ từng thử hiện thực một splay tree có parent pointer và có thể thay đổi bằng Rust, nhưng vấp phải borrow checker đến mức từng nghi ngờ không biết có thể xây dựng được hệ thống thực tế hay không
- Sau đó họ tạo ra một copy-on-write B-tree có dùng
Arc, và cấu trúc này tự nhiên phù hợp với multithreading - Rope là cấu trúc lưu trữ văn bản nền tảng của Zed; khi chuyển snapshot sang background thread, việc này gần như chỉ cần tăng reference count của
Arc
Lựa chọn tự sở hữu toàn bộ stack
- Zed chọn hướng tự sở hữu các khối lớn, từ Tree-sitter phụ trách parsing cho tới GPUI là UI framework tăng tốc bằng GPU
- Cấu trúc tự sở hữu này cho phép họ tự quyết định và hiện thực những hành vi cần thiết
- Khi muốn dùng WASM trong language extension, họ có thể thêm tính năng đó vào Tree-sitter
- Họ cũng không phải giao cách render văn bản, vốn rất quan trọng với text editor, cho một UI framework bên ngoài
- GPUI được bắt đầu từ năm 2019; vào thời điểm đó, các UI framework đang tồn tại либо không đáp ứng được hành vi mà Zed cần, либо đội ngũ chưa hiểu chúng đủ sâu
- Cách tiếp cận tự hiểu các primitive cấp thấp và tự xây hệ thống gần như là một chiến lược sinh tồn đối với GPUI
- Chi phí cũng rất rõ ràng
- Tự xây mất rất nhiều thời gian
- Tốc độ phát triển chậm hơn
- Vì không dùng framework phổ biến, nhân sự mới phải học codebase khoảng 300.000 dòng gần như từ đầu
- Đồng thời, vì có người trong nội bộ đã viết chính phần mã đó nên họ có thể giải thích cho thành viên mới; theo thời gian, chi phí của việc tự sở hữu có thể giảm đi còn lợi ích thì tích lũy dần
- Cũng đã bắt đầu xuất hiện các ứng dụng khác xây dựng trên GPUI như loungy
Chỗ cần hoàn thiện kỹ và chỗ có thể đi nhanh
- Tiêu chí của đội ngũ Zed là chỉ xây những gì cần thiết, và trong phạm vi đó thì làm tốt nhất có thể
- Thay vì đoán trước những tính năng có thể cần trong tương lai và tốn thời gian cho chúng, họ chỉ triển khai những gì thực sự trở nên cần thiết với chủ đích và sự cẩn trọng
- Mức độ hoàn thiện khác nhau tùy theo tầng mà mã nằm trong đó
- Những tầng mà toàn bộ ứng dụng phụ thuộc vào như GPUI cần độ hoàn thiện cao
- Những cấu trúc dữ liệu như SumTree, được dùng rộng khắp codebase và quan trọng về hiệu năng, cũng được xử lý cẩn thận
- Các tối ưu hiệu năng cục bộ ở rìa hệ thống thì thay vì mài giũa quá mức, họ chỉ làm đến mức đạt mục tiêu
- SumTree sử dụng random testing để kiểm tra các edge case
- Chủ nghĩa hoàn hảo không nên cản trở việc học hỏi; khi đã vận hành lâu dài chính đoạn mã mình tự viết và cả trải qua những thỏa hiệp, việc viết lại sẽ có cơ sở rõ ràng hơn nhờ những gì đã học được
Bài học rút ra từ CRDT và cấu trúc buffer
- Buffer ban đầu của Atom là một mảng chuỗi JavaScript, tức mảng các dòng
- Buffer của Zed là một copy-on-write B-tree thân thiện với multithread, có thể snapshot và lập chỉ mục cho nhiều loại thông tin cần thiết
- CRDT không phải là lựa chọn hiển nhiên ngay từ đầu; họ đã trải qua một giai đoạn nghiên cứu, đọc nhiều bài báo trước khi đi đến cách tiếp cận hiện tại
- Việc hiện thực CRDT đã được viết lại hai đến ba lần, nhưng hướng tiếp cận tổng thể nhìn chung vẫn được giữ nguyên
- Ở Atom, code editor đầu tiên của họ, nhóm từng dùng cách tiếp cận nhanh hơn và thô hơn kiểu “worse is better”, và chính kinh nghiệm đó giúp họ xác định được đâu là những điểm đau thực sự
- Nếu phải bắt đầu lại, họ sẽ không xây buffer dưới dạng mảng dòng đơn giản nữa, vì những ví dụ chậm trước đây và nhiều edge case trong quá khứ đòi hỏi một thiết kế chặt chẽ hơn
Những tầng được đầu tư đặc biệt trong Zed
- GPUI là khu vực được theo đuổi độ hoàn thiện cao vì họ đã viết lại toàn bộ
editorcrate bao gồm nhiều tầng chuyển đổi văn bản thô trong buffer thành các dòng hiển thị trên màn hình- Mở rộng tab
- Soft wrap
- Chèn block decoration
- Xử lý fold
- Các tầng chuyển đổi này có một chiến lược kiểm thử nhất quán bằng random testing dựa trên thuộc tính
- multi-buffer là cấu trúc ghép các phần của những buffer khác nhau thành một thể thống nhất, và cũng là một phần được xử lý như thành phần cốt lõi
- Trong năm 2021, đã có lúc họ dành trọn nhiều ngày chỉ để giảm bớt và debug các edge case do random testing tìm ra
- Vì tầng này được viết bằng Rust, nếu xảy ra sai sót thì không chỉ đơn giản là hiện stack trace ở một góc editor mà chương trình có thể dừng hẳn do panic, nên tính chính xác là rất quan trọng
- Họ cũng đã bàn đến việc cải thiện input và loading theo hướng thân thiện hơn với streaming để giảm tình trạng người dùng không nhận được phản hồi nào khi mở file lớn, và các tối ưu liên quan sẽ được đưa vào preview
Khác biệt còn lại cho người dùng và contributor
- Với người dùng cuối, điều quan trọng nhất rốt cuộc vẫn là editor có nhanh hay không
- Với developer tool và editor, người dùng có khả năng trực tiếp đóng góp vào codebase cao hơn, nên ngôn ngữ hiện thực và cách build ảnh hưởng đến khả năng đóng góp
- Nếu Zed được viết bằng C++, có thể số người dùng muốn tự sửa đổi trực tiếp sẽ ít hơn
- Rust và
cargogiúp việc build dự án và thử thay đổi trở nên dễ hơn, giảm nhu cầu phải học CMake hay Gyp - Sự nghiêm ngặt của trình biên dịch Rust cũng giúp tăng độ tin cậy khi merge khi tiếp nhận đóng góp từ bên ngoài
- Zed muốn giữ thời gian mỗi frame dưới 3ms, và chính yêu cầu hiệu năng này là lý do họ chọn UI framework tăng tốc bằng GPU thay vì CPU rasterization
- Họ cũng quan tâm đến Zig, nhưng việc dùng một ngôn ngữ duy nhất là Rust cho cả server lẫn frontend vẫn có những lợi thế
1 bình luận
Các ý kiến trên Hacker News
Framework UI tùy biến của Zed hiện có thể trông thú vị, nhưng có lẽ tình hình sẽ khác đi ngay khi họ nhận ra mình phải triển khai khả năng tiếp cận
Để triển khai khả năng tiếp cận trong một framework tùy biến mà không hy sinh hiệu năng, cần rất nhiều công việc lắt nhắt theo từng nền tảng. Zed không chỉ định vị mình là một editor có thể đơn giản là không dùng, mà là công cụ cộng tác, nên việc bảo đảm mọi lập trình viên trong nhóm đều có thể dùng là điều bắt buộc
Với tư cách người dùng screen reader, tôi đã chán những công cụ “hiện đại” dựa trên Rust mà VoiceOver chỉ nhìn thấy một cửa sổ trống. So với web app, nơi chỉ cần gắn vài aria label cho nút và dọn lại focus, UI tùy biến phải phơi bày mọi control cho mọi OS khó hơn rất nhiều
May là đã có AccessKit như https://accesskit.dev/ nên công việc có thể dễ hơn đôi chút, nhưng tôi không biết nó phù hợp đến đâu với một app lớn như editor
Vì họ xây GPUI từ đầu nên không thể dùng nguyên các tính năng tiếp cận mà app dựa trên Swift hoặc web có sẵn; cần vừa làm phía Zed vừa mở rộng tính năng của GPUI
Tuy nhiên link họ gắn cho thảo luận về khả năng tiếp cận, https://github.com/zed-industries/zed/pull/1297, lại là một issue GitHub về nút lùi/tiến nên vô dụng. Có lẽ họ định link tới https://github.com/zed-industries/zed/discussions/6576
Tài liệu liên quan: https://zed.dev/docs/themes
Họ có nghĩ đến khả năng tiếp cận, nhưng chưa đến giai đoạn thực sự triển khai
Cho đến cách đây không lâu, chỉ có các binding cho framework C hiện có hoặc các thư viện GUI ở mức proof of concept. Tương lai sẽ tốt hơn, nhưng tôi cũng hiểu sự thất vọng của những người phụ thuộc vào tính năng tiếp cận
Tuy vậy, nhiều dự án có khả năng sẽ muốn tạo một thư viện GUI vững chắc trước rồi mới thêm các tính năng tiếp cận
Nhiều startup đã thất bại vì đổ tài nguyên vào những tính năng hào nhoáng không phải yếu tố khác biệt
Các sản phẩm thành công với UI không native nhìn chung dùng công nghệ web hoặc framework trưởng thành như Qt, hoặc là ngoại lệ như Blender đã 30 năm tuổi. Apple cũng từng làm điều tương tự với iTunes, nhưng iTunes cho Windows gây khó chịu, chỉ là người ta vẫn dùng iTunes mà thôi
Tôi hiểu sức hấp dẫn của việc muốn tạo một framework như GPUI, nhưng bài viết không giải thích điều đó liên quan thế nào đến vấn đề Zed muốn giải quyết
Kiểu công cụ chỉ nhìn pixel mà hiểu như con người, rồi dùng OCR để phân tích văn bản
Tôi hiểu các công nghệ như VoiceOver biết và tận dụng định nghĩa cửa sổ cùng các phần tử thực tế ở cấp độ lập trình
Với những dự án muốn tốc độ render bằng GPU nên trông như “cửa sổ trống” đối với VoiceOver, cách này có thể là một phương án thay thế tối thiểu chăng
Nếu vậy tôi cũng thắc mắc liệu điều đó có nghĩa là mọi nội dung được render bằng GPU như game đều không thể tiếp cận hay không
Trên iPhone, tôi đã tạo một Apple Shortcut tên “GPT Explains”: chạm hai lần vào mặt lưng điện thoại để chụp màn hình, gửi tới OpenAI, rồi nhận lại mô tả những gì nhìn thấy, bản dịch tiếng Anh của văn bản không phải tiếng Anh, phản biện các luận điểm trong meme, v.v.
Bản sao đã bỏ API key ở đây: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
Trước khi bắt theo trào lưu text editor mới, tôi để lại đây để mọi người xem thử giấy phép mà người dùng phải đồng ý
“Customer Data, bao gồm nội dung do người dùng tạo ra trong quá trình sử dụng Solution, được phân loại là User Content. User Content chỉ được truyền ra khỏi môi trường của người dùng khi người dùng chọn chia sẻ dự án trong Editor để cộng tác với các người dùng Zed khác.”
“[...] quyền truy cập của Zed vào User Content đó được giới hạn cho việc debug và cải thiện Solution.”
Tôi sẽ không diễn giải thêm, mỗi người tự rút ra kết luận
Nếu đã chọn chia sẻ dự án với người khác để cộng tác, thì việc nội dung dự án được truyền ra khỏi máy của mình là đương nhiên. Không vậy thì nó hoạt động kiểu gì?
Bài viết này khiến tôi thử dùng Zed, và trông nó khá hứa hẹn. Nhưng vì không hỗ trợ remote host/devcontainer nên tôi không thể dùng được
Tính năng này của VSCode là cốt lõi trong quy trình làm việc của tôi. Thực ra tôi không muốn phát triển trên Mac, mà muốn dùng Mac như một cổng vào các VM và container nơi tôi code
Nó giúp ích rất nhiều cho việc tách biệt các dự án, và vì không đặt môi trường phát triển hay dependency trên máy host thật nên cũng tốt hơn về mặt bảo mật
Tôi tò mò lợi ích của remote host/devcontainer trong VSCode so với một phiên remote thông thường là gì
Đây là một cuộc phỏng vấn tuyệt vời, rất đáng đọc, cho thấy rõ cách các nhà phát triển nhìn nhận việc phát triển từ nhiều góc độ khác nhau
Tuy nhiên tôi có một điểm không đồng ý
Không phải “cái tên phù hợp hoàn hảo cho một text editor viết bằng Zig đã bị Zed lấy mất”, mà cái tên đó là “Zag” ;)
zedcóed.edlà tiền thân củaex,vi,edlin, và là một line editor họ Unix vẫn còn tồn tạihttps://en.wikipedia.org/wiki/Ed_(text_editor)
Ngược lại,
ag, tức the silver searcher, cũng rất tuyệt, nhưng tôi thấy Zed nghiêng về chỉnh sửa code hơn là tìm kiếm codehttps://geoff.greer.fm/ag/
Tôi không dùng Zed, nhưng đã thấy José Valim dùng nó khi live coding. Tôi chủ yếu dùng VSCode, nhưng có một tính năng tôi thấy trong Zed khá hấp dẫn
Khi dùng “Find All”, giống VSCode, các đoạn khớp từ mọi file sẽ hiện trong panel kết quả, nhưng ở đó có thể chỉnh sửa trực tiếp các đoạn kết quả tìm kiếm, và vẫn dùng được các tính năng chỉnh sửa thông thường như multi-cursor
Trong VSCode thì phải bấm vào kết quả tìm kiếm để mở file rồi sửa ở đó, nên tôi thấy tính năng này khá hay và ấn tượng. Chưa đến mức khiến tôi chuyển sang dùng, nhưng mỗi khi VSCode làm tôi bực mình thì đôi lúc tôi lại nhớ tới nó
occurvàmulti-occurtừ thập niên 80, và có thể làm việc kiểu này. Thật sự rất tuyệtGần đây các giao diện cho công cụ như ripgrep cũng cung cấp chế độ có thể chỉnh sửa, rất tiện cho refactoring. Tất nhiên cũng có thể chỉnh sửa hàng loạt tên file
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...
Nghe có thể vô lý, nhưng một trong những lý do chính tôi dùng JetBrains thay vì VSCode là vì có thể tìm kiếm thư mục và mở từ panel điều hướng
Chỉ sau khi đọc bình luận này tôi mới nhớ ra thứ mình đã quên, nên chắc phải dùng lại thử
https://marketplace.visualstudio.com/items?itemName=jakearl....
Một mẹo tôi thích là chỉnh sửa bằng multi-cursor rồi dùng phím tắt đi tới cuối dòng hoặc từ tiếp theo để sửa hàng loạt
Nếu làm được việc đó trên nhiều file thì tốt quá
Nó không chạy trên Windows hay Linux. Khi nào được hỗ trợ thì mong có người báo lại
Một cuộc phỏng vấn tuyệt vời
Tôi thích việc họ suy nghĩ sâu về chuyện nên trau chuốt quá mức thứ gì. Tác phẩm tốt nhất của tôi thường cũng xuất hiện vào khoảng vòng thứ hai, thứ ba, thứ tư
Tôi tò mò họ có kế hoạch gì cho khả năng xử lý cấu hình bằng script. Tôi chưa dùng Zed nhiều, nhưng hiện tại đã làm được chưa? Liệu thứ như Neon có giúp lấp khoảng cách giữa VSCode và người dùng Atom cũ không?
https://github.com/neon-bindings/neon
— Brooks, Mythical Man-Month
Theo dõi v2 lúc nào cũng thú vị. Tôi đã thấy có trường hợp trở thành thảm họa vì quá tải tính năng, và cũng có trường hợp trở nên tuyệt vời vì gọn gàng, sắc bén hơn
Trong lĩnh vực web app ngày nay có quá nhiều công cụ, nên tôi tự hỏi liệu rủi ro này có áp dụng không chỉ cho v2 mà cả v1 nữa không. Gần đây tôi thấy nhiều v1 phình to đến đáng ngạc nhiên, và thường phải cố tình đi tìm các công cụ làm ít hơn
Tôi đã thử Zed và cảm thấy nó khá giống VSCode. Tôi biết nó có tính năng multiplayer tốt hơn Live Share, nhưng nhìn bề ngoài thì vẫn cần thêm lý do thuyết phục để chuyển sang
Nếu Zed có thể thay thế Xcode thì có lẽ tôi sẽ muốn dùng thử thêm. Từ việc xóa derived data hay dọn build folder cho đến các lỗi crash ngẫu nhiên, dùng Xcode thật khổ sở
So với trải nghiệm nhà phát triển của Android Studio thì hoàn toàn khác. Trong phát triển iOS, tôi luôn mong có được trải nghiệm như Android Studio
Tôi thật sự thích ứng dụng native, nhưng hiện giờ vẫn bị buộc chặt vào VS Code. Nhìn thấy việc con trỏ nhấp nháy trong VS Code cũng tiêu tốn nhiều điện năng mà thấy xót
Tôi đã thử Zed một chút nhưng chưa thể điều chỉnh cho phù hợp với workflow của mình. Tôi thích việc nó nhẹ và nhanh. Các process của VS Code khoảng 3GB, còn Zed là 300MB, nên chỉ bằng 1/10 bộ nhớ là một khác biệt đáng kể
Nhưng tôi rất cần hỗ trợ Jupyter Notebook mà VS Code cung cấp, và cũng đã quá quen với cách phát triển từ xa từ Mac sang máy Ubuntu. VS Code làm việc này rất tốt
Hy vọng Zed trụ đủ lâu để hỗ trợ workflow của tôi
Có lẽ mọi người bật nhiều extension hơn chăng
Theo hiệu ứng Lindy https://en.wikipedia.org/wiki/Lindy_effect, có lẽ phải thêm ít nhất 1 năm nữa mới thấy được thứ gì đó
Tôi đã xem trang About và tính năng live coding trông có vẻ hữu ích. Có lẽ các developer cũng rất hào hứng. Đây là một dự án thú vị vì có thể viết thuật toán, tối ưu hiệu năng và cả lập trình GPU
Nhưng tôi tự hỏi ai cần thêm một text editor khác có lẽ sẽ không bao giờ đạt được mức tương đương về tính năng với Vim và terminal multiplexer
VS Code xuất hiện khá đột ngột trong thời gian tương đối gần đây và được rất nhiều người dùng, cho thấy sau Vim vẫn có cơ hội cho editor mới
Còn Zed có đạt đủ đà để đáp ứng nhu cầu long-tail của các developer khác hay không thì phải chờ xem, nhưng việc có thêm sản phẩm cạnh tranh để giành người dùng là điều khá đáng mong đợi
Không cần bắt chước Vim, có thể tận dụng nguyên Neovim và toàn bộ plugin của nó
Tôi vẫn thấy tiếc khi JetBrains tiếp tục duy trì plugin giả lập Vim mà người dùng Vim gọi là tệ hại. Nếu họ triển khai native một frontend Neovim trong IDE, họ sẽ có lợi thế mạnh hơn nhiều là “hỗ trợ đầy đủ Neovim và hệ sinh thái của nó”, trong khi hiện tại chỉ dừng ở “có plugin giống Vim”
Cứ dùng công cụ bạn thích và giúp bạn hoàn thành công việc. Vim cũng nằm trong số đó, nhưng tôi đã mệt với cách người ta làm như dùng Vim là một phước lành không thể thay thế
Trở thành người tư duy tốt hơn sẽ làm năng suất lập trình viên của bạn tăng theo cấp số nhân hơn bất kỳ công cụ nào
Đã có những editor khá giàu tính năng và mọi người hài lòng, hoặc ít nhất là đã quen dùng. Một editor mới có thể tìm chỗ đứng ở đâu?
“Multiplayer” thì hay đấy, nhưng gần với edge case hơn
Tôi cũng không chắc về mô hình kinh doanh. Mọi người có thật sự muốn kênh, cuộc gọi, chat được tích hợp vào code editor không? Cá nhân tôi gần như phản cảm theo bản năng, nhưng có thể chỉ mình tôi như vậy