Hacker News Digest

Социальная сеть для разработчиков под названием /dev/null строится вокруг коммитов вместо постов: вход только через GitHub, а сообщения — это простой текст до 4000 символов. Лента работает без алгоритмов, строго по времени публикации, а профили полностью повторяют данные GitHub и редактируются там же. Первые коммиты проходят ручную модерацию, после чего автоматический модератор проверяет и одобряет их сам.

Тон площадки — шутливый и «свой»: в трендах шутки про Laravel, команды вроде php artisan make:friends и composer require followers, а также жалобы на внезапную нагрузку («нужно масштабировать сервер», «они деплоят прямо с телефона, помогите»). Упоминаются разработчики Нуну Мадуру и Николя Грекас, а число пользователей предлагают оценивать по счётчику подписок одного из участников. Есть и опрос о кроссплатформенной разработке с вариантами React Native, Flutter, SuperNative (NativePHP) и Kotlin Multiplatform. Всё остальное, по ироничному девизу проекта, уходит в /dev/null.

Сообщество разработчиков скептически относится к /dev/null. Обязательный вход через GitHub считается ограничением аудитории и связью с Microsoft, противоречащей идее независимой соцсети. Модерация постов (ручная проверка первых коммитов, затем автоматическая) вызывает опасения по поводу задержек и цензуры. Заявленные новшества воспринимаются как переупаковка существующих решений вроде Mastodon и Solid, без значимых отличий от других соцсетей для разработчиков. Технические проблемы: непонятный выбор домена (dev-null.sh), простои, отсутствие ясности о стеке технологий. Предложения: добавить публичный просмотр ленты и подробную информацию о платформе до регистрации, улучшить онбординг и визуальные метафоры (git‐аналогии, подсказки). Отмечается плюс: открытый исходный код и быстрый отклик сообщества — более 200 pull‐request'ов за 48 часов. Спор о будущем: некоторые видят в /dev/null потенциал для децентрализованного обмена файлами (сравнение с Solid), другие считают его обычным хостингом с альтернативами вроде tilde.town.

Разработчики StreetComplete начали портирование приложения с Android на iOS, используя Kotlin Multiplatform — технологию, позволяющую писать общую логику на Kotlin и компилировать её под iOS через Native. Основная стратегия: сначала заменить Android-специфичные библиотеки (Jetpack Compose) на Compose Multiplatform, затем адаптировать UI под iOS. Код приложения уже на 100% написан на Kotlin, а многие зависимости — чисто котлин-библиотеки, что упрощает миграцию. На данный момент порт достиг 50% завершённости, что стало возможным благодаря полной занятости разработчика в первой половине 2024 года.

Ожидаемый объём работы — около одного человеко-года, поэтому успех зависит от сообщества. Все задачи вынесены в открытый Kanban-борт, и любой может взяться за них. Особый акцент сделан на освоении Compose Multiplatform — новой, но перспективной технологии от JetBrains. Помочь можно не только кодом: спонсорство позволяет увеличить время разработчика на проекте, а помощь в трайдинге задач и поддержке высвобождает ресурсы для фокуса на портировании.

StreetComplete упрощает участие в OSM и получил положительные отзывы на Android и в ожидании iOS-версии как вводный инструмент для новых мапперов. Однако пользователи отмечают недостатки: ограниченная история правок, UX-проблемы (невозможно отменить открытый вопрос без ответа, нет возврата к карте без завершения формы, неудобный вход через WebView), случаи отката правок сообществом и необходимость улучшить доступность бета-версии. Рекомендуется: добавить нативный вход через Apple ID вместо WebView, разместить ссылку на TestFlight более заметно, добавить отдельную кнопку отмены формы (не relying на жест «back»), улучшить подсказки к иконкам в UI (например, в EveryDoor). Есть спор: пользователи хотят полную историю правок, а разработчики ограничивают отмену 24-часовым окном. Kotlin Multiplatform поддерживает единый код, но выбор 100% Kotlin для iOS считается некоторыми странным, хотя не мешает прогрессу.

F-Droid 2.0 — это полное переосмысление официального клиента для репозитория свободного ПО на Android, выпущенное после более чем года разработки и 14 тестовых релизов. Обновление построено на Kotlin Compose и Material Design, сохраняя привычные взаимодействия, но предлагая современный интерфейс, упрощённую навигацию и улучшенную обнаруживаемость приложений. Основные разделы теперь — Discover, Search и My Apps — заменяют прежнюю структуру, делая акцент на простом доступе к категориям, обновлениям и управлению установленным ПО.

Ключевое улучшение — переработанная система категорий: вместо нескольких широких групп теперь доступны numerous специализированные категории (например, отдельные жанры игр — 17 видов), объединённые в мета-категории для удобного browsing. Discover выделяет новые, обновлённые и самые популярные приложения, помогая пользователям находить релевантное ПО без трекинга или манипуляций вовлечённостью. Функция Nearby Swap пока не включена в релиз, но активно разрабатывается на основе улучшенных методов соединения. Команда призывает пользователей тестировать, переводить, донатить и участвовать в развитии проекта через Liberapay или OpenCollective, подчёркивая, что F-Droid 2.0 — фундамент для будущих улучшений в экосистеме свободного Android-ПО.

F-Droid 2.0 решает ключевые проблемы UX, но вызывает споры о дизайне, отсутствии рейтингов и сложностях с обновлением. Пользователи активно ищут альтернативы и ждут стабильного релиза. Совет: Пользователи рекомендуют Droid-ify и NeoStore как альтернативы из-за плохого UX официального F-Droid, особенно на GrapheneOS и для поиска популярных приложений. Спор: Одни хвалят новый дизайн на Kotlin Compose за современность и упрощённую навигацию, другие критикуют отсутствие визуальных разделителей, неясность тапаемых элементов и следование трендам без мысли. Все согласны, что поиск — ключевая функция, и его улучшение (удаление плавающей кнопки) — значительный прогресс, который давно требовался. Совет: Пользователи с опытом на Android без Google-аккаунтов советуют Aurora Store как комплемент F-Droid, несмотря на задержки с новыми приложениями и сбои в синхронизации. Спор: Некоторые отмечают, что F-Droid 2.0 не поддерживает F-Droid Privileged Extension (FPE), но заменяет его на Android Session Installer — другие считают это потерей функциональности для старых устройств. Пользователи жалуются на отсутствие рейтингов, отзывов и статистики загрузок, что делает выбор приложений рискованным и неинтуитивным, особенно для новичков. Совет: Пользователи с опытом на TV (Nvidia Shield, Onn TV) просят улучшить навигацию с пульта, так как текущий интерфейс не позволяет отслеживать фокус курсора. Спор: Некоторые считают, что F-Droid — это инструмент для разработчиков и продвинутых пользователей, а не массового рынка, и не ожидают от него простоты Kindle или Play Store. Все отмечают, что F-Droid 2.0 не обновляется автоматически, и пользователи вынуждены вручную скачивать APK, несмотря на наличие старой версии на устройстве. Совет: Пользователи с опытом в Linux и CLI просят создать командную утилиту fdr для управления приложениями через ADB, как пакетный менеджер для Android. Пользователи подтверждают, что репозитории F-Droid часто не синхронизируются вовремя, и это остаётся болевой точкой, даже в новой версии. Совет: Пользователи ищут F/OSS-читалки для Kindle-альтернатив, но жалуются, что существующие приложения слишком сложны и не подходят для обычных пользователей. Спор: Некоторые выражают недоверие к бинарникам из F-Droid, предпочитая скачивать APK напрямую с GitHub, так как репозиторий может быть устаревшим. Пользователи отмечают, что F-Droid стал важнее из-за ужесточения политики Google, и многие готовы отказаться от Android, если F-Droid перестанет работать. Совет: Пользователи с опытом на GrapheneOS и LineageOS подтверждают, что настройка F-Droid Privileged Extension была сложной, и переход на Android Session Installer — правильное решение.

GrapheneOS Messaging 13 полностью переработан на Jetpack Compose и Material 3, с обновлённым интерфейсом, улучшенной поддержкой больших экранов и множеством исправлений в стабильности, безопасности и удобстве использования. Добавлен новый адаптивный значок приложения, экран настройки с акцентом на конфиденциальность SMS и правильную обработку вырезов и системных панелей в обеих ориентациях.

В списке диалогов теперь можно закреплять беседы, откладывать уведомления на 1, 8, 24 часа или навсегда, помечать как непрочитанное свайпом или через меню, а также архивировать или разархивировать одним движением. Добавлены индикаторы для закреплённых, отложенных, отключённых уведомлений, рабочих профилей и статуса входящих MMS. Действия с архивацией, удалением и блокировкой применяются мгновенно, а экран архива полностью переработан.

В самих диалогах улучшены пузырьки сообщений, группировка, выделение и обработка ссылок. Добавлен счётчик сегментов и символов SMS, возможность редактировать темы MMS, баннер с разблокировкой для заблокированных отправителей и выбор SIM-карты по системному умолчанию при fallback. Переработан выбор получателей с разделением по алфавиту, поддержкой email, форматированных номеров и нескольких номеров на контакт. Экстренные номера нельзя набрать из чата, а сообщения, приходящие во время удаления диалога, больше не уничтожаются.

Медиа и вложения получили новый выбор фото и видео с поддержкой захвата, вспышки и встроенного выбора Android, а также переработанную запись аудио с жестом свайпа для отмены и блокировкой hands-free. Просмотр фото и vCard теперь поддерживает зум, индикаторы страниц, детали и сохранение в контакты. Делиться контентом стало удобнее благодаря новому выбору с поиском, недавними чатами и многократным выбором, с возможностью редактировать текст, добавлять тему и выбирать SIM перед отправкой.

В настройках добавлен раздел конфиденциальности, переписаны основные и per-SIM параметры, а экран лицензий теперь генерирует данные динамически. Улучшена безопасность: превью YouTube-ссылок отключено по умолчанию, проверка共享 контента блокирует опасные URI, виджеты больше не экспортируются, а PendingIntent используют флаг immutability. Добавлены лимиты при парсинге EXIF, MMS и типа контента, исправлены проблемы с GIF, цветовой коррупцией и парсером vCard. Уведомления теперь сохраняют непрочитанное состояние после перезагрузки, не звучат для заблокированных чатов и не сбрасывают изменения архива при синхронизации.

Для многопользовательского использования и рабочих профилей: уведомления во вторичных пользователях показывают содержание сообщений, а ожидающие MMS должны быть получены владельцем, после чего становятся доступны всем. Диалоги в рабочем профиле помечены специальной меткой. Доступность улучшена: метки для TalkBack, полные названия дней в таймстампах, копирование деталей сообщения как действие доступности и звуковое подтверждение при отправке. Тестовое покрытие расширено для слоёв данных, домена и Compose-UI, с проверками на каждом pull request. Обновлены зависимости: minSdk 36, targetSdk и compileSdk 37, AGP 9.3.2, Kotlin 2.4.10, Gradle 9.7.1, а также добавлены Compose BOM, Material 3 Adaptive, Navigation 3, Coil 3 и CameraX.

Обсуждение подтверждает, что переработка Messaging-приложения GrapheneOS — необходимое условие для привлечения массового пользователя, особенно с выходом на новые устройства, но остаются критические недостатки: отсутствие RCS, слабый UX, отсутствие скриншотов в документации и непрозрачные пути доступа к Alpha-каналу. Пользователи спорят о интуитивности интерфейса: mrd3v0 считает интерфейс звонков неудобным, но loufe и okanat показывают, что детали доступны через «Call Details». andrepd критикует Material 3 за избыточное пространство, другие — воспринимают как улучшение. preisschild подтверждает критический баг в старой версии: неправильное сопоставление контактов и отправка сообщений не тем получателям. RCS-поддержка отсутствует и будет добавлена позже — реализация сложна, но считается единственно надёжным решением; шифрование SMS не планируется, кастомные альтернативы вроде SMSecure не рассматриваются. Отправка SMS по email (например, Verizon Vtext) признана устаревшей и небезопасной из-за отсутствия SPF-проверки. Скриншоты отсутствуют в официальных материалах — это подтверждается многими пользователями; karimabuseer предлагает поднять вопрос через PR. Доступ к Alpha-каналу описан пользователями: три точки → Change release channel — информация не в документации. gib444 указывает на регрессию: при длинном нажатии на ссылку больше не появляется меню копирования, а выделяется весь SMS — критично для OTP-кодов. HybridStatAnim8 сообщает, что после Messaging планируются обновления Dialer и Contacts, а автоматическая запись звонков уже выпущена. Спор о приоритетах: mmooss спрашивает, почему ресурсы тратятся на Messaging, а не на ядро безопасности — ответы объясняют, что без полированного приложения GrapheneOS не сможет масштабироваться, даже при надёжном ядре. I_am_tiberius предлагает объединение с Fairphone, но jasonvorhe, drnick1 и saligne возражают: цели проектов разные, Fairphone не поддерживается официально, Pixel — приоритет. Несколько пользователей (jcul, nosioptar) отмечают, что для них SMS не критично — основные коммуникации через Signal/WhatsApp, и рекомендуют Fossify Messages как альтернативу.

Shopify переходит обратно на нативную разработку мобильных приложений после пяти лет успешного использования React Native. В 2020 году выбор фреймворка был обусловлен необходимостью избегать дублирования функций, расширить круг разработчиков и снизить затраты на поддержание паритета между iOS и Android. Эти преимущества реализовались: команда экономила время, привлекала специалистов без мобильного опыта и сосредотачивалась на доставке ценности. Однако к концу 2025 года фундаментальное предположение о стоимости дублирования труда изменилось благодаря прогрессу больших языковых моделей (LLM). Shopify начал использовать ИИ с 2021 года, и к 2025-м агенты стали способны не только ускорять написание кода, но и выполнять перевод функций между платформами, помогать в наboardingе разработчиков и обеспечивать проверку кода и тестов на основе общих спецификаций. Это снизило нагрузку по поддержанию паритета до уровня, когда нативная разработка перестала быть непрактичной.

Теперь Shopify считает, что преимущества нативной разработки — близость к платформенным возможностям, доступ к первым-party инструментам и меньшее количество абстракционных слоёв — вновь перевешивают выгоды от共享 кода. Компания не отказывается от React Native резко: она планирует чистый переход, продолжая поддерживать свои открытые библиотеки (например, Reanimated и React Native Skia), которые стали лидерами в своих нишах. Одновременно Shopify активно нанимает мобильных инженеров и специалистов на стыке ИИ и разработки. Переход не отрицает прошлых успехов: React Native был правильным выбором в 2020 году благодаря усилиям сотен инженеров и поддержке сообщества, включая Meta, Software Mansion и Уильяма Кандильона. Накопленный опыт и инструменты останутся фундаментом для будущей мобильной стратегии Shopify.

Переход Shopify на нативную разработку обусловлен ростом сложности React Native, нестабильностью библиотек, проблемами с обновлениями и несоответствием с платформенными фреймворками, что повышает стоимость поддержки. LLM значительно снижают стоимость генерации и поддержки нативного кода, делая миграцию экономически целесообразной даже для крупных продуктов — даже без глубокого знания Swift или Kotlin. Нативная разработка обеспечивает лучшую производительность, стабильность и контроль над платформой, особенно в сложных сценариях отладки. Отказ от React Native устраняет угрозы цепочек поставок npm. Даже без LLM миграция оправдана из-за высокой стоимости поддержки абстракции, что подтверждается опытом команд до 2026 года. Споры остаются: отказ от OTA-обновлений критичен для быстрорастущих компаний; сложность отладки крашей в JS, C++ и нативных потоках не устраняется LLM и может быть дороже поддержки двух кодбаз. Рекомендации: стартапам React Native и Flutter остаются разумными для MVP; после зрелости — переход на нативный код для контроля качества и производительности. При миграции важно отделить бизнес-логику от UI, чтобы LLM могли тестировать состояние через CLI. Использование агентов требует строгого контроля зависимостей и тестов — иначе компания рискует стать зависимой от нестабильных LLM. Нативные инструменты (Jetpack Compose, SwiftUI) становятся более предсказуемыми, а LLM эффективнее работают с прямым доступом к платформе, чем через слои абстракции. Ранее привлекательный аргумент «React Native для веб-разработчиков» устарел: LLM позволяют генерировать нативный код без знания платформенных языков. Опыт показывает, что React Native-проекты часто превращаются в «junk show» из-за нестабильности и низкого качества библиотек. Снижение стоимости генерации кода LLM меняет баланс: дублирование кода теперь дешевле, чем поддержка абстракции без полного контроля. Индустрия движется к отказу от высокоуровневых абстракций в пользу нативного кода.

Desert Ant Labs запускает набор из 18 специализированных моделей для работы на устройстве — в аудио, зрении и тексте — каждая из которых отвечает за миллисекунды и работает бесплатно, без токенов и облачных вызовов. Эти модели достаточно малы, чтобы работать на пятилетнем смартфоне, и достаточно быстры, чтобы обрабатывать каждый кадр видео или каждое нажатие клавиши, превосходя по скорости и качеству существующие API-решения. Например, модель Voz транскрибирует 10 минут аудио за две секунды на iPhone — в 4,7 раза быстрее Whisper — с временными метками для каждого слова. Clear, весом всего 9 МБ, превращает пятиминутную запись в студийное качество за одну секунду. Redact маскирует персональные данные (имена, адреса, номера карт) в реальном времени на 27 языках, достигая 88,8% точности при размере всего 12 МБ — близко к результатам 2,3 ГБ модели GLiNER-PII. Tongue идентифицирует 84 языка по трём словам с точностью 0,933 при размере 2 МБ, обгоняя 293 МБ детектор с показателем 0,887.

Все модели доступны через единый SDK для Swift, Kotlin и JavaScript, с бесплатным использованием до 100 тыс. ежемесячно активных устройств. Desert Ant Labs, основанный в Европе, делает ставку на суверенный подход: данные никогда не покидают устройство пользователя, что исключает зависимость от облака и защищает от принудительного изъятия информации. Лаб вырос из внутренней потребности команды Detail — их видео-приложения, где функции вроде Auto Edit и аудио-улучшения изначально требовали облачных API, prowadząc к росту инфраструктурных расходов. Обучив собственные модели, команда достигла превосходства над Dolby, Whisper и Claude Sonnet по скорости, качеству и стоимости, при этом модели оказались значительно меньше. Первые 18 моделей — это «маленький мозг» (мозжечок) системы: они выполняют рутинные, всегда включённые задачи, освобождая ресурсы для высшего уровня обработки. В будущем планируется добавить «кору» — динамическую селекцию моделей: локальные сначала, крупные при необходимости, облако — только если данные должны покинуть устройство. Появление более мощных чипов и открытых исследований позволит постепенно увеличивать размер и возможности локальных моделей, строя frontier-интеллект снизу вверх. SDK и документация доступны на GitHub, а модели можно протестировать через CLI или в браузере на Hugging Face.

Обсуждение подтверждает потенциал локальных моделей для снижения задержек и расходов, но выявляет практические проблемы: неясная бизнес‐модель после бесплатного порога, ограниченная поддержка только Apple‐устройств, отсутствие Python‐SDK и вопросы качества и лицензирования моделей. Автор поста считает модель бесплатной до 100 k MAU, но пользователи спорят о дальнейшей монетизации: один аргументирует, что без облачных вызовов нет оснований для оплаты, другой указывает на типичный enterprise‐подход с гибкой лицензией. Пользователь @momojo подтверждает, что небольшие модели (≈50 MB) запускаются на ноутбуке без дискретного GPU для биоинформатики, что поддерживает обещанную эффективность on‐device. Многие комментаторы отмечают, что модели доступны только через CoreML — только на iOS/macOS — и выражают недовольство отсутствием поддержки Android, Windows и Linux. Для расширения аудитории рекомендуется выпустить Python‐SDK или pip‐пакет для интеграции в серверные и кроссплатформенные проекты. После бесплатного уровня цены не раскрыты; участники указывают на «contact sales», что типично для корпоративного ПО с гибкой ценой и риском доли от доходов приложения. Стоит явно указывать, какие модели оригинальные, а какие — переупакованные открытые (например, Voz = Parakeet v3), чтобы избежать недоразумений. Маленькие on‐device модели могут использоваться для автодополнения текста и UI‐подсказок, особенно ценно на старых смартфонах с ограниченными ресурсами. Есть опасения по поводу on‐device модерации контента (hate‐speech triage): без постоянных обновлений риск ложных срабатываний высок, поэтому требуется тщательная валидация. Для выхода за пределы экосистемы Apple стоит добавить поддержку TensorFlow Lite, ONNX Runtime или ML Kit, чтобы запускать модели на Android и других платформах. Демонстрация модели Clear (улучшение аудио) не произвела ощутимого различия в звучании, вызывая сомнения в реальном качестве улучшения.

В Kotlin-компиляторе скрыта ошибка, срабатывающая при сборке проекта в турецкой локали. Из-за неё при попытке скомпилировать код в турецкой локали возникает ошибка парсинга XML от компилятора: строчка var category: CompilerMessageSeverity? = CATEGORIES[qName.toLowerCase()] в функции CompilerOutputParser некорректно обрабатывает турецкий символ I (U+0049), который при приведении к нижнему регистру становится не i (U+0069), а ı (U+0131) — точкой надстрочного i без точки. Из-за этого ключ i не находится в словаре CATEGORIES, и код ошибочно считает, что это неизвестный тег, и выдаёт сообщение об ошибке.

Ошибка скрывалась в коде с 2016 по 2021 год, пока не была обнаружена и исправлена. Теперь код корректно использует локально-независимый toLowerCase(Locale.ROOT), и проблема решена. Это яркий пример того, как тонкости локализации могут вызывать ошибки в интернационализированном ПО, особенно при обработке текста.

• Проблема "турецкое I" встречается везде, где не указывается локаль при работе со строками, и это приводит к багам, когда вместо "I" в турецкой локали превращается в "ı" (без точки) и наоборот.
• Современные языки и фреймворки должны предоставлять единообразные и предсказуемые API, но вместо этого они вынуждают разработчиков указывать локаль каждый раз, что приводит к ошибкам.
• Пользователи с турецкой локалью страдают от багов, которые не могут быть обнаружены автоматически, потому что большинство разработчиков тестируют только на английской локали.
• Это также является примером более широкой проблемы: API-функции, которые не принимают Locale параметр, вместо этого полагаясь на дефолтной локали, что может привести к ошибкам.

Python сохраняет лидерство благодаря своей универсальности в машинном обучении и веб-разработке, а JavaScript остаётся незаменимым для фронтенда. Rust продолжает расти из-за акцента на безопасность и производительность, особенно в системном программировании. Go набирает популярность в облачных сервисах и микросервисной архитектуре благодаря простоте и эффективной параллельной обработке.

Стоит отметить рост TypeScript как более строгой альтернативы JavaScript, а также стабильное присутствие Java в корпоративных приложениях. Интерес к Julia увеличивается в научных вычислениях, а Kotlin укрепляет позиции в мобильной разработке под Android. Практический вывод: выбор языка всё больше зависит от конкретной области, а не только от общей популярности.

• Сомнения в методологии рейтинга языков программирования IEEE из-за использования ненадёжных источников (поисковые запросы, устаревающий StackOverflow), что может искажать реальную картину.
• Удивление высокой позицией Java (2-е место), объясняемой её доминированием в enterprise-секторе (финансы, страхование, здравоохранение) и миграцией legacy-систем с COBOL.
• Обсуждение искусственного завышения позиции Python из-за его популярности у новичков, в академических статьях и как основного языка вывода для LLM.
• Предложение объединить рейтинги близких языков (JavaScript/TypeScript, Java/Kotlin, C/C++) для более точного отражения популярности экосистем.
• Размышления о влиянии AI-ассистентов на будущее языков: возможная стагнация из-за зависимости LLM от популярных языков или, наоборот, упрощение изучения нишевых.

• CSS

  • min-width: auto (по умолчанию) имеет приоритет над flex-shrink, overflow: hidden, width: 0; задайте min-width: 0.
  • Горизонталь и вертикаль различаются: width: auto растягивается, height: auto по содержимому; margin: 0 auto центрирует по горизонтали, но не по вертикали (в flex-direction: column работает).
  • BFC (display: flow-root) предотвращает схлопывание margin и «обнуление» высоты родителя с float-потомками.
  • Новый stacking context создают transform, filter, opacity, position: fixed/sticky, z-index + absolute/relative и др.; z-index действует только внутри контекста.
  • На мобильных 100vh включает скрытые панели; используйте 100dvh.
  • position: absolute ориентируется на ближайший «positioned» ancestor, а не на родителя.
  • float не работает внутри flex/grid-родителя.
  • Процентные width/height не работают, если размер родителя не задан.
  • display: inline игнорирует width, height, вертикальные margin.
  • Пробелы между inline-block элементами рендерятся; в flex/grid — нет.
  • box-sizing: content-box (по умолчанию) не включает padding/border; включите border-box.
  • Указывайте width/height у <img> для предотвращения CLS.
  • Загрузка файлов не показывается в DevTools; используйте chrome://net-export/.
  • Внутри <script> строка </script> ломает парсинг.

• Unicode

  • Отличайте code point и grapheme cluster (последнее — то, что видит пользователь).

• Маршрутизаторы могут тихо обрывать простаивающие TCP-соединения; настройте TCP-keepalive или HTTP-заголовки.
• Возвращать null из Optional<T> — антипаттерн; Kotlin и аннотации уже решают это.
• UTF-16 в Java/C#/JS — деталь реализации; в Go строки — просто байты.
• min-width: auto работает не везде; CSS-свойства нельзя читать изолированно.
• Регексы, YAML, LF/CRLF, rm -rf $DIR/ — каждый язык/платформа имеет свои подводные камни.

Zig выглядит почти как Rust, но делает синтаксис ещё приятнее за счёт более простой семантики и ряда изящных решений.

Числа
Литералы 92 всегда имеют тип comptime_int; при присваивании они неявно приводятся к нужному типу. Суффиксов нет.

Строки
Многострочные «сырые» строки пишутся через \\ в начале каждой строки; \ не экранируется, отступы не портятся, а лексер работает построчно.

Структуры
.{ .x = 1, .y = 2 } — запись поля через .x = совпадает с присваиванием, что позволяет грепом находить именно записи, а не чтения.

Типы
Все типы префиксные: u32, [3]u32, ?[3]u32, *const ?[3]u32. Разыменование постфиксное: ptr.*.

Идентификаторы
Синтаксис @"имя с пробелом" позволяет обходить ключевые слова и экспортировать любые имена.

Функции
fn add(x: i32, y: i32) i32 — без стрелки ->, так как лямбд нет, а возвращаемый тип всегда обязателен. pub fn main() void {}.

Переменные
const и var; часто используемое const короче, чем в Rust, но всё же длиннее Kotlin-овского val.

• Обсуждение разделилось: кому-то синтаксис Zig кажется «прекрасным» минимализмом, другим — «шумным» и «капризным».
• Спор о порядке «имя: тип» vs «тип имя»: одни хотят видеть тип первым, другие — имя.
• Критика деталей: @-префиксы, .{}, отсутствие лямбд, перенос строк, orelse без пробела.
• Плюсы: raw-строки Zig решают проблему отступов; обработка ошибок через try нравится многим.
• Сравнения: Kotlin, C#, Go, Rust, D — каждый считает «своё» лучше.
• Итог: «красота» синтаксиса субъективна и во многом привычна; после практики Zig начинает нравиться.