Редактор Zed летает на macOS, стабилен на Linux… но тонет в багах на Windows. Когда же ждать релиз?

Редактор Zed летает на macOS, стабилен на Linux… но тонет в багах на Windows. Когда же ждать релиз?

Год работы, сотни коммитов и ни одной стабильной версии…

image

Сооснователь редактора Zed, написанного на Rust, Макс Брунсфельд рассказал , почему разработка версии для Windows затянулась. Его объяснение в блоге компании хорошо иллюстрирует трудности, с которыми сталкиваются команды, пытающиеся сделать кроссплатформенные приложения , особенно если в список поддерживаемых систем входит Windows.

Первая бета-версия Zed появилась ещё в марте 2023 года, но только для macOS. Сборка для Linux вышла в июне 2024-го. Работы над портированием на Windows начались в начале 2024 года: поначалу основную часть коммитов делал контрибьютор Чжанкьюй Чжан, но в последние полтора месяца над задачей трудятся уже четыре инженера из основной команды. На данный момент Windows-сборка находится в статусе закрытой альфы, но её можно собрать из исходного кода .

Zed пока находится в стадии превью на всех платформах. Релиз версии 1.0 разработчики обещают к концу 2025 года, и поддержка Windows входит в этот план. Однако, по словам Брунсфельда, речь скорее идёт о предварительном варианте, чем о полноценной стабильной версии.

Создание приложений, одинаково хорошо работающих на разных ОС, проще, если использовать готовые фреймворки вроде Qt, рассчитанного на C++. Но команда пошла другим путём: они разработали собственный GPU-ускоренный фреймворк для Rust под названием GPUI, чтобы добиться максимальной производительности. Это означает прямое использование графических API для отрисовки интерфейса: на macOS — Metal и Metal Shading Language, на Linux — Blade, построенный поверх Vulkan. Такой низкоуровневый подход отличается от Visual Studio Code, где интерфейс работает на базе JavaScript-движка. Благодаря этому Zed заметно быстрее и экономнее в использовании ресурсов.

Изначально для Windows команда тоже применяла Blade, однако столкнулась с проблемами при сборке под ARM64. В свежем коде используется DirectX 11 — родной графический API для Windows. Он обеспечивает лучшую работу и меньшее потребление памяти, но теперь приходится поддерживать сразу три реализации шейдеров. Подробности этой работы Брунсфельд описал в своём блоге.

Затруднения касаются не только графики. Для Windows пришлось решать целый набор специфических задач :

  • отличия в файловой системе, включая невозможность перезаписать .exe-файл, пока он выполняется, что усложняет обновления;
  • иная инфраструктура для отчётов о сбоях;
  • различия в ожиданиях пользователей по поводу горячих клавиш;
  • особые соглашения о формате путей, создающие сложности при редактировании файлов на удалённой Linux-машине с клиента под Windows;
  • необходимость полноценной поддержки WSL (Windows Subsystem for Linux) вместо авторизации через SSH;
  • типичные ошибки наподобие «слишком длинного пути», которые решаются включением longpath-поддержки.

Опыт команды Zed показывает, насколько непросто создавать нативные приложения, одинаково хорошо работающие на всех ОС. Те же самые трудности объясняют, почему Windows до сих пор так прочно удерживает позиции и в бизнес-среде, и в игровой индустрии: портировать приложения «в обратную сторону» тоже крайне сложно.