Hacker News Digest

ImapGoose — это инструмент для синхронизации почты, работающий в режиме реального времени. В отличие от традиционных решений, которые выполняют синхронизацию периодически, ImapGoose работает как демон, отслеживая изменения как на сервере (через IMAP), так и в локальной файловой системе (через inotify/kqueue). Это позволяет моментально отражать изменения: новое письмо на сервере появляется в файловой системе в течение секунды, а удалённое в другом клиенте — исчезает локально.

Ключевые особенности включают поддержку современных расширений IMAP, таких как CONDSTORE (2006) для эффективного определения изменений, QRESYNC (2008) для работы с удалениями и NOTIFY (2009) для мгновенных уведомлений об изменениях. Это позволяет ImapGoose минимизировать трафик и избегать массовой пересинхронизации.

ImapGoose использует локальную базу данных для отслеживания состояния, что позволяет ему интеллектуально обрабатывать изменения. Например, при обнаружении расхождений программа не перезагружает весь mailbox, а вычисляет разницу и синхронизирует только необходимые части. Это особенно эффективно в сочетании с NOTIFY, который немедленно сообщает об изменениях, сводя к минимуму необходимость опросов.

Программа устойчива к сетевым проблемам: использует экспоненциальный бэксаптинг при отключениях (от 1 секунды до 17 минут), и автоматически возобновляет синхронизацию при восстановлении соединения. Внутренняя архитектура использует систему задач и очередей для координации синхронизации, предотвращая конфликты даже при параллельных изменениях.

• Пользователи обсуждают, какие инструменты (mbsync/isync, imapfilter, isync/notmuch, mu4e, aerc, gnus) лучше всего использовать для синхронизации и чтения почты в условиях нестабильного интернета и отсутствия push-уведомлений.
• Поднимается вопрос, насколько современные почтовые клиенты (Thunderbird, Apple Mail, Outlook) используют такие же стратегии и расширения.
• Участники обсуждают, что происходит при потере соединения и как обеспечивается надежная синхронизация состояния почты.

Компиляция Zig становится значительно быстрее благодаря многолетней работе над оптимизацией компилятора. Например, сборка скрипта build.zig в версии 0.15 заняла всего 1,7 секунды против 7,2 секунд в версии 0.14. Полная сборка проекта Ghostty без кеша сократилась с 41 до 32 секунд, даже с использованием LLVM.

Особенно впечатляет скорость инкрементных сборок: пересборка библиотеки libghostty-vt после изменения одной строки теперь занимает менее секунды (975 мс против 2,9 секунд ранее). Это уже ощутимо ускоряет рабочий процесс, а в будущем, с отказом от LLVM и внедрением инкрементной компиляции, результаты станут ещё лучше — ожидаются миллисекундные задержки.

• LLVM рассматривается как ловушка из-за сложности тонкой настройки финальных оптимизаций и линковки, несмотря на преимущества в скорости начальной разработки и поддержке платформ. Cranelift и другие бэкенды могут стать альтернативой.
• Zig фокусируется на скорости компиляции для разработки, используя собственный бэкенд для debug-сборок (x86_64) и LLVM для релизов. Есть баги, но инструментарий ценится за простую кросс-компиляцию и статическую линковку.
• Быстрая компиляция (TCC, Go, Vlang) важна для итеративной разработки, но trade-off с оптимизацией кода неизбежен. Интерпретаторы или JIT-компиляция (Julia) предлагают альтернативы для интерактивности.
• Интеграция Zig с системами сборки (Bazel) возможна через правила, но Turing-полные скрипты сборки могут усложнить кеширование. Библиотеки часто обходятся без кастомных скриптов.
• Поддержка платформ (OpenBSD) требует доработки низкоуровневого IO (kqueue). Статическая линковка зависимостей в Zig упрощает деплой, но динамические библиотеки (libc, GUI) остаются.