▲

GN⁺: 다시 시작해야 합니다: Atom부터 Zed까지

 (zed.dev)
2P by neo 5달전 | favorite | 댓글 1개
  • Zed의 공동 창립자인 Nathan, Max, Antonio와의 대화에서 기술적 선택의 이유, Rust의 중요성, 기술 스택을 소유하는 것에 대한 의도 등에 대한 질문이 있었음
  • 이들은 다시 한번 질문에 답하며, 한 시간 동안의 대화를 편집한 내용을 공유

Atom에서 Zed로: 10년의 여정

  • 세 창립자는 약 10년 동안 함께 일해왔으며, 아톰을 개발한 후 Zed를 만들기로 결정함.
  • Zed의 비전은 아톰의 초기 비전을 더 세련되고 구체화한 것으로, 기술적 선택이 이 비전과 밀접하게 연결되어 있음.
  • Rust, GPU 가속, CRDTs 등의 기술적 선택은 Zed의 목표를 달성하기 위해 중요함.

기술적 선택과 비전

  • Zed의 비전은 가벼우면서도 필요할 때 IDE의 기능을 제공하는 텍스트 편집기를 만드는 것임.
  • 아톰 개발 당시 기술적 한계와 개발자들의 기술적 성숙도 부족으로 인해 비전을 완전히 실현하지 못함.
  • Rust가 등장하면서 기존의 한계를 극복할 수 있는 기회가 마련됨.

아톰의 한계와 새로운 시작

  • 아톰 개발 중 JavaScript의 한계와 웹 기술의 제약으로 인해 성능 문제가 발생함.
  • 2017년, 기존 플랫폼의 한계를 느끼고 Zed를 처음부터 다시 시작하기로 결정함.
  • Rust와 GPU 가속을 통해 성능을 향상시키고자 함.

Rust의 영향

  • Rust는 고수준의 추상화를 제공하면서도 뛰어난 성능을 제공함.
  • Rust의 '제로 비용 추상화'는 텍스트 편집기 개발에 있어 중요한 역할을 함.
  • C++이나 C로도 유사한 성능을 낼 수 있지만, Rust는 개발자에게 더 쉽고 안전한 개발 경험을 제공함.

전체 스택 소유의 중요성

  • Zed 개발팀은 tree-sitter부터 GPU 가속 UI 프레임워크인 GPUI에 이르기까지 전체 기술 스택을 소유함.
  • 전체 스택을 소유하는 것은 의도적인 선택이며, 이를 통해 성능과 기능에 대한 완전한 제어가 가능함.

완벽한 추상화와 긴급성 사이의 균형

  • 필요한 것만, 필요한 만큼만 구축하고, 배운 것을 바탕으로 필요할 때 재검토하는 것이 중요함.
  • 핵심적인 부분은 높은 품질과 성능을 보장하기 위해 충분한 시간을 투자함.

개발자 도구와 기술의 관계

  • 개발자 도구 사용자들은 기술에 더 관심을 가질 수 있으며, 기술이 사용자에게 제공하는 성능과 기능에 영향을 줌.
  • Rust로 작성된 Zed는 개발자들이 쉽게 기여할 수 있게 하며, 이는 커뮤니티의 참여를 촉진함.

GN⁺의 의견

  1. Zed의 개발 과정은 기술적 선택이 제품의 비전과 성능에 얼마나 중요한지를 보여줌. Rust와 같은 현대적인 프로그래밍 언어의 선택은 개발자의 생산성과 제품의 성능을 동시에 향상시킬 수 있음을 입증함.
  2. 전체 기술 스택을 소유하는 것은 Zed 팀이 성능 최적화와 기능 개발에 있어 유연성을 갖게 하며, 이는 고성능 텍스트 편집기를 만드는 데 결정적인 역할을 함.
  3. 개발자 도구의 경우, 사용하는 기술이 최종 사용자 경험에 더 큰 영향을 미칠 수 있으며, 이는 Zed가 개발자 커뮤니티에 어떻게 받아들여지는지에 영향을 줄 수 있음. Rust의 사용은 개발자들에게 Zed에 기여하는 것을 더 매력적으로 만들고, 이는 제품의 성장과 발전에 긍정적인 영향을 미침.
▲
neo 5달전  [-]
Hacker News 의견

  • 사용자 정의 UI 프레임워크가 현재는 재미있을 수 있으나, 접근성을 구현해야 할 때 문제가 될 수 있음. 성능 저하 없이 사용자 정의 프레임워크에서 접근성을 구현하는 것은 쉽지 않으며, 플랫폼별로 복잡한 작업이 필요함. Zed는 단순한 에디터가 아니라 협업 도구로 자리매김하고 있기 때문에 모든 개발 팀원이 사용할 수 있도록 하는 것이 중요함.

    AccessKit이라는 도구가 있어 작업을 조금 더 쉽게 할 수 있을지도 모르지만, 큰 에디터에 적합한지는 확실하지 않음.

  • Zed 텍스트 에디터를 사용하기 전에 사용자가 동의해야 하는 라이선스에 대한 주의사항. 사용자 콘텐츠는 'User Content'로 분류되며, Zed 사용자와 협업하여 프로젝트를 공유할 때만 환경에서 전송됨. Zed는 사용자 콘텐츠에 대한 접근이 디버깅과 솔루션 개선을 위해서만 제한되어 있음.

    사용자는 이 정보를 바탕으로 자신의 결론을 내릴 수 있음.

  • Zed 에디터가 매우 유망해 보이지만, 원격 호스트/개발 컨테이너 지원이 없어 사용할 수 없음. VSCode의 해당 기능은 사용자의 워크플로우에 중요하며, Mac을 VM과 컨테이너로 코드를 작성하는 포털로 사용하는 것을 선호함. 이는 프로젝트 분리와 보안 자세를 향상시킴.

  • 개발자들의 개발 접근 방식에 대한 통찰을 제공하는 훌륭한 인터뷰. 다양한 각도에서 개발을 바라보는 방식에 대해 많은 생각을 하고 있음.

    개발자들은 'Zed'라는 이름이 이미 Zig에서 완벽한 텍스트 에디터 이름으로 사용되고 있다고 생각하지만, 실제로는 'Zag'이 더 적합하다는 의견도 있음.

  • Zed를 사용하지 않지만, José Valim이 코딩 세션을 실시간 스트리밍할 때 사용하는 것을 보았음. VSCode를 주로 사용하지만, Zed의 'Find All' 기능이 인상적임. VSCode와 비슷하게 결과 창을 열어 일치하는 모든 파일의 스니펫을 보여주지만, Zed에서는 바로 그곳에서 스니펫을 직접 편집할 수 있음. 이는 VSCode에서는 검색 결과를 클릭하여 파일을 열고 편집해야 하는 것과 대조적임.

  • Zed가 Windows나 Linux에서 작동하지 않음. 이 플랫폼들에서 작동하게 되면 알려달라고 요청함.

  • 인터뷰가 매우 좋았으며, 'gold-plate'에 얼마나 많은 생각을 하는지에 대해 감탄함. 최고의 작업은 보통 두 번째 또는 그 이후의 시도에서 나옴. Zed의 구성을 스크립트로 작성할 수 있는 기능에 대한 계획이 궁금함. 아직 Zed를 많이 사용해보지 않았지만, VSCode와 Atom 사용자들에게 도움이 될 Neon 같은 도구가 있음.

  • Zed를 시도해보았고, VSCode와 유사함을 느낌. 멀티플레이어 기능이 live share보다 낫지만, 전환을 설득하기 위해서는 더 많은 것이 필요함. XCode를 대체할 수 있다면 Zed 사용에 더 기울 수 있을 것임. XCode 사용에 불편함을 느끼며, Android Studio와 같은 iOS 개발 경험을 원함.

  • 네이티브 앱을 선호하지만 현재는 VSCode를 사용해야 함. VSCode에서 커서 깜빡임에 너무 많은 전력을 소모하는 것을 보고 아쉬움을 느낌. Zed는 가볍고 빠르지만, Jupyter Notebook 지원과 Mac에서 Ubuntu 박스로 원격 개발하는 데 익숙해져 있어서 VSCode가 잘 작동함. Zed가 사용자의 워크플로우를 지원할 때까지 충분히 개발을 이어나가길 바람.

  • Zed의 About 페이지를 살펴보았고, 실시간 코딩 기능이 유용해 보임. 개발자들에게 재미있는 프로젝트일 것이며, 알고리즘 작성, 성능 최적화, GPU 프로그래밍 등을 할 수 있음. 하지만 Vim과 터미널 멀티플렉서와 기능적으로 동등해지지 못할 또 다른 텍스트 에디터가 필요한지 의문임.

답변달기