Hacker News Digest

Браузер Arc прекращает существование 22 декабря 2026 года. Компания объясняет решение приоритетом безопасности: поддерживать защиту браузера в эпоху искусственного интеллекта требует постоянной работы, и все инженерные и security-команды переключаются на новый браузер Dia, построенный с нуля под современные угрозы. Команда признаёт, что решение далось тяжело, ведь Arc годами развивался вместе с сообществом.

Переход на Dia максимально упрощён: пароли, закладки, расширения и история переносятся автоматически. Пространства стали профилями, папки — группами вкладок, а вертикальные вкладки в боковой панели, закреплённые вкладки и разделённый экран сохранены. По заявлениям разработчиков, Dia превосходит Arc по стабильности, скорости и безопасности; функции браузера бесплатны, а ИИ опционален.

Ключевые даты: с 22 октября 2026 года нельзя создать новый аккаунт Arc, но появляется экспорт всех данных; 23 ноября на iOS и Android отключаются ИИ-функции и синхронизация; 22 декабря Arc перестаёт работать на macOS и Windows, аккаунты деактивируются, а личные данные удаляются в течение 30 дней. Arc Search для Android исчезнет из Google Play. Сохранить данные можно, экспортировав их из Arc или импортировав в Dia до 22 декабря.

Пользователи ценят уникальный UX Arc (боковую панель, вертикальные вкладки, Peek, Air Traffic Control, вложенные папки), но считают переход на Dia неполноценным, дорогим и избыточно зависимым от AI. Dia критикуют за огромный размер (861 МБ), корпоративную ориентацию (запрос рабочего email), половинчатый интерфейс и навязчивую кнопку AI-чата, которая воспринимается как реклама и обоснование цены в $100 в месяц. Многие выражают недоверие к Atlassian, упоминая серьезную уязвимость безопасности в Arc, и призывают открыть исходный код браузера для его сохранения сообществом. В качестве более стабильных и надежных альтернатив рассматривают Zen, Orion, Vivaldi или Safari с расширениями SupaSidebar и OpenIn. Отдельно отмечают, что вертикальные вкладки в сплит-моде неэффективны для многозадачности, так как занимают около 40% экрана.

Команда Thunderbird разрабатывает нативное приложение для iPhone с нуля, не используя существующий код. Это позволяет применить весь опыт, накопленный при создании версий для настольных компьютеров и Android, и сразу заложить быструю, надёжную и современную основу. Конечная цель — бесшовная работа на всех устройствах: почтовый процесс должен ощущаться единым и на компьютере, и в дороге. Сейчас основное внимание уделяется чистой архитектуре, что в будущем ускорит добавление новых функций.

Уже прорабатываются ключевые элементы. Настроить учётные записи Google и Microsoft можно будет в один клик, а фоновая синхронизация будет поддерживать постоянную связь с провайдером, обновляя входящие и экономя заряд батареи. Готовятся и повседневные инструменты: лаконичный, удобный для чтения список писем и современный редактор с панелью форматирования. Приложение задумано расширяемым — с системой экспериментальных флагов, чтобы сообщество разработчиков могло легко вносить вклад, а опытные пользователи раньше тестировать новшества.

Первая версия для тестирования сообществом должна появиться в ближайшие месяцы. Команда подчёркивает, что создаёт продукт вместе с сообществом, и просила назвать три самые важные вещи в ежедневной работе с почтой. В комментариях уже просят интеграцию с календарём Apple и синхронизацию тегов между устройствами.

Пользователи скептически относятся к новому iOS‐клиенту Thunderbird из‐за давних проблем: неудобный поиск (баг с «wedding» открыт 14 лет), громоздкая работа с ветками (клик открывает все сообщения в цепочке, особенно неудобно при 60+ письмах), отсутствие полной синхронизации и устаревший дизайн («Bootstrap‐подобный», не соответствующий 2026 году). Многие считают, что встроенный iOS‐Mail уже удовлетворяет их потребности, делая Thunderbird излишним. На других платформах пользователи также жалуются на почти бесполезный поиск. Дискуссия о кроссплатформенности Thunderbird разделилась: одни хвалят поддержку CardDAV/CalDAV для Linux, несмотря на тяжеловесность; другие называют его «тормозом» с плохой интеграцией и базовыми недоработками. Для решения проблем предлагают использовать форки и патчи сообщества (Betterbird, K9 для Android) или альтернативные клиенты вроде Marco с офлайн‐синхронизацией и push‐уведомлениями. Пользователи требуют от iOS‐версии полной загрузки всей почты и поддержки JMAP для офлайн‐доступа и быстрого отклика, как у настольных клиентов.

Go предоставляет лёгкие горутины, запускаемые ключевым словом go, которые планируются рантаймом на системные потоки. Для синхронизации используются sync.WaitGroup, увеличивающий счётчик при Add и уменьшающий при Done, а Wait блокирует до нуля. Каналы обеспечивают синхронный обмен данными: отправка блокирует до получения, а select позволяет ждать нескольких каналов одновременно, включая time.After для таймаутов. Контекст (context.Context) передаёт сигналы отмены и таймауты через WithCancel и WithTimeout, проверяемые через Done(). Для защиты共享 данных применяются мьютексы (sync.Mutex), а атомарные операции (sync/atomic) работают без блокировок. Семафоры ограничивают доступ к ресурсам через буферизованные каналы, а sync.Once гарантирует однократную инициализацию. Профилирование выполняется через net/http/pprof или вручную: pprof.StartCPUProfile для CPU, runtime.MemStats для памяти, trace.Start для трассировки, включая flight recording с ограничением по размеру и времени. Все инструменты направлены на безопасную и эффективную конкурентность без гонок данных.

Go-конкурентность проста для старта, но сложна для безопасной эксплуатации в проде: утечки горутин, отсутствие встроенной отмены и трудности с отладкой — частые проблемы. Опытные разработчики обходят их через context, WaitGroup и избегают каналов там, где они не нужны. Не используйте каналы повсеместно — многие профессионалы Go редко применяют их, предпочитая последовательный код и вводя конкуренцию только при превышении SLO. Перед запуском горутины обязательно определите, как она будет остановлена — утечки горутин в проде трудно отлаживать и требуют перезапуска процесса. Используйте context для отмены, но помните: отмена требует сотрудничества горутины — Go не поддерживает прерывание, так как не имеет исключений. Простые шаблоны go+chan из учебников часто небезопасны — реальные приложения требуют хаков для управления жизненным циклом горутин. Избегайте сложных графов операций в Go — без generics и completable futures это сложно; альтернативы вроде goyek помогают, но не решают фундаментальные ограничения. Go-каналы не эквивалентны Haskell's STM — отсутствие транзакционной памяти снижает абстрактную мощность, а поведение при закрытии канала дважды — произвольное и непредсказуемое. Java с виртуальными потоками и структурированной конкурентностью предлагает более надёжный и безопасный подход, чем Go, особенно с учётом отсутствия memory safety в Go. Erlang/BEAM и Elixir имеют более зрелую модель акторов с распределённой обработкой, устойчивостью к сбоям и поддержкой межмашинной коммуникации, чего Go не имеет. Kotlin coroutines и структурированная конкурентность решают проблему отмены и управления жизненным циклом более элегантно, чем Go-контекст. Haskell позволяет писать асинхронный код как синхронный — без прыжков между сообщениями, что делает логику проще для понимания, чем в Go-каналах. Julia предлагает более продвинутую систему потоков: M:N, структурированная конкурентность, распределённые вычисления и безопасные атомарные операции в стандартной библиотеке. Опытные разработчики Go часто избегают mutex и каналов в PR — любое использование этих механизмов воспринимается как признак ошибки. Для сложных задач с очередями и диспетчеризацией лучше выносить конкурентность в отдельные менеджеры — логика остаётся линейной, что упрощает аудит и отладку. Go-конкурентность — это магия для старта, но требует глубокого понимания для продакшена: утечки, отмена и отладка — главные боли, которые не решаются синтаксисом. Каналы в Go — это просто буферизованные очереди; небуферизованные каналы создают rendezvous-синхронизацию, что отличает их от mvar и требует осознанного применения.