Hacker News Digest

Автор создал заголовочный файл safe_c.h (600 строк), добавляющий в C современные средства безопасности из C++ и Rust, сохраняя при этом производительность и простоту языка. Этот файл используется для создания высокопроизводительного grep-клона cgrep, демонстрируя, как можно обуздать "опасные возможности" C. safe_c.h предоставляет семантику RAII через атрибуты [[cleanup]] с обратной совместимостью для старых компиляторов, а также умные указатели UniquePtr и SharedPtr для автоматического управления памятью.

Заголовочный файл включает макросы LIKELY/UNLIKELY для оптимизации ветвления и гарантирует очистку ресурсов даже при раннем возврате или goto. UniquePtr автоматически освобождает память при выходе из области видимости, устраняя утечки, а SharedPtr реализует автоматический подсчёт ссылок. Автор утверждает, что с помощью таких инструментов C остаётся языком свободы и гибкости, позволяющим писать безопасный код без потери производительности.

• Обсуждение показало, что безопасность в C требует компромисов: либо платить за счёт производительности (POSIX-мьютексы), либо отказаться от переносимости кода.
• Участники спорят, стоит ли вообще пытаться эмулировать современные примитивы безопасности в C, или лучше просто использовать C++ там, где это возможно.
• Поднимается вопрос, что макросы и обёртки в C ведут к созданию "мини-языка" внутри проекта, что затрудняет понимание кода для новых участников команды.
• Обсуждается, что C++ уже реализовал всё, что пытаются эмулировать в C, и что это не избежно ведёт к "переизобретению велосипеда".
• Участники обсуждают, что встроенные в компилятор возможности C++ вроде std::unique_ptr и std::shared_ptr не только более безопасны, но и более производительны, чем попытки их эмулировать в C.

Memory maps (mmap) в Go позволяют отображать файлы непосредственно в адресное пространство процесса, избегая копирования данных через буферы. Этот подход устраняет необходимость в системных вызовах read/write, позволяя процессору обращаться к файловой памяти так же, как к обычной памяти. Техника особенно эффективна для больших файлов, когда требуется частый доступ к разным участкам данных, так как mmap обеспечивает постоянное время доступа к любой части файла.

Тесты показали впечатляющие результаты: mmap обеспечивает до 25-кратное ускорение по сравнению с традиционным чтением файлов. В одном эксперименте обработка 1.2GB JSON-файла через заняла 0.4 секунды с mmap против 10 секунд с использованием стандартного пак ioutil. Однако mmap имеет ограничения: он не подходит для очень больших файлов, которые могут не поместиться в виртуальном адресном пространстве, и требует осторожного управления при работе с несколькими процессами. Для оптимальной производительности mmap лучше всего работает с файлами, которые считываются целиком или accessed случайным образом, а не последовательно.

• Обсуждение показало, что mmap не всегда быстрее обычного чтения, особенно при последовательном чтении, и что его преимущество в основном в нишевых сценариях, таких как случайный доступ к большим файлам.
• Участники отметили, что mmap требует осторожности при работе с файлами, которые могут быть изменены или усечены, поскольку это может вызвать ошибки доступа.
• Также было отмечено, что в некоторых ситуациях, таких как чтение из файла в последовательном режиме, обычное чтение может быть предпочтительнее, особенно если файл больше размера оперативной памяти.
• Обсуждение также затронуло влияние различных файловых систем и их взаимодействия с mmap, включая то, что некоторые файловые системы могут не поддерживать mmap или могут вести себя неожиданно при его использовании.
• В конце обсуждение подвело к выводу, что выбор между использованием mmap и обычного чтения должен быть сделан на основе конкретного сценария и требований к производительности, а не на основе предвзятого убеждения в превосходстве одного над другим.

Предлагается добавить в Python явный синтаксис для ленивого импорта с ключевым словом lazy, которое размещается перед import или from. Это позволяет отложить загрузку модуля до момента первого использования импортированного имени, сокращая время запуска и потребление памяти. Особенно полезно для CLI-инструментов с подкомандами, где даже вызов --help может загружать десятки ненужных модулей.

Ленивые импорты сохраняют полную обратную совместимость — обычные импорты работают как раньше, а новые семантика активируется только при явном указании. Механизм использует прокси-объекты, которые заменяются реальными значениями при первом обращении (реификация). Это решает проблему ручного переноса импортов в функции, что уже делается в 17% случаев в стандартной библиотеке.

• Предложение о ленивых импортах (PEP 690) поддерживается для ускорения запуска CLI-инструментов и уменьшения накладных расходов, но вызывает опасения по поводу непредсказуемости и ошибок времени выполнения.
• Критики указывают на проблемы с безопасностью потоков, сложность отладки и потенциальное ухудшение читаемости кода из-за нового синтаксиса (lazy import).
• Альтернативы включают ленивую загрузку на уровне модуля (с явным объявлением модулем), использование существующих методов (импорт внутри функций) или инструментов вроде LazyLoader.
• Некоторые участники выступают за ленивые импорты по умолчанию, но признают, что это нарушит обратную совместимость из-за побочных эффектов при импорте.
• Обсуждаются вопросы совместимости с линтерами, влияние на стандартную библиотеку и необходимость обновления парсеров и редакторов для поддержки нового ключевого слова.

В .NET 10 сборщик мусора получает серьёзные улучшения, которые могут вдвое или втрое сократить использование памяти и повысить производительность. Ключевые изменения включают расширенный escape-анализ для выделения объектов на стеке, оптимизацию делегатов и настройку размеров регионов кучи. Также активирована система DATAS, автоматически адаптирующая сборку мусора под поведение приложения, особенно в контейнерах.

Однако эти улучшения требуют осторожного подхода: они доступны через runtime-флаги и могут иметь компромиссы, например, увеличение пауз или нагрузки на CPU. Разработчикам стоит тестировать новые настройки в боевых сценариях, а не включать их вслепую. Инструменты мониторинга, такие как счетчики GC и дампы памяти, помогут оценить эффект для конкретного приложения.

• Пользователи отмечают значительное повышение производительности в .NET 10 по сравнению с .NET 8, особенно в приложениях для анализа аудио и текста.
• Высказываются опасения, что оптимизации .NET могут отдалить его от совместимости с WASMGC, что критично для использования в браузере.
• Обсуждаются потенциальные риски, такие как переполнение стека в программах, которые ранее работали стабильно, и сложность настройки GC.
• Упоминаются альтернативные фреймворки для кроссплатформенной разработки (Avalonia, Flutter, MvvmCross) на фоне скептического отношения к стабильности и будущему MAUI.
• Поднимаются вопросы о применимости .NET для high-frequency trading и оптимизации LINQ, а также о сравнении с JVM и другими языками (F#, Java).

Larian Studios выпустила нативную версию Baldur's Gate 3 для Steam Deck, которая работает без слоя совместимости Proton. Это снижает нагрузку на процессор и потребление памяти, улучшая производительность. Игроки могут проверить установку через настройки Steam, выбрав инструмент совместимости с Linux Runtime.

Сохранения в нативной версии хранятся в папке /home/deck/.local/share/Larian Studios/, а не в compatdata. Steam Cloud автоматически синхронизирует последние сейвы, но старые можно перенести вручную через режим рабочего стола. Larian подчёркивает, что поддержка Linux ограничена только Steam Deck.

• Обсуждается выпуск нативной версии Baldur's Gate 3 для Steam Deck, отмечаются усилия Larian и улучшение производительности (~10% FPS в Act 3) по сравнению с версией на Proton.
• Поднимаются вопросы о термине "нативная" версия: означает ли она Linux-бинарник, оптимизацию под железо Steam Deck или просто правильную конфигурацию, а также о возможности её запуска на других Linux-дистрибутивах.
• Участники делятся личным опытом игры на Steam Deck: одни хвалят работу через Proton, другие сталкивались с проблемами производительности и теперь рады нативному релизу.
• Критикуется позиция Larian о непредоставлении поддержки для платформы Linux в целом, при этом выпуске сборки под конкретное устройство (Steam Deck) на Arch Linux.
• Затрагиваются смежные темы: проблемы с производительностью старого железа, сравнение с другими играми, баги в процессе обновления через Steam на Linux.

Automerge — это движок синхронизации данных с приоритетом локальной работы, упрощающий создание коллаборативных приложений. Выпущена версия 3.0.

Главное обновление — резкое снижение потребления памяти. Ранее хранение полной истории документов могло приводить к гигабайтам в ОЗУ. В 3.0 память сокращена более чем в 10 раз (иногда значительно больше), что делает Automerge применимым в куда большем числе сценариев.

Также упразднены избыточные API, особенно при работе со строками.

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

Чтобы узнать, как достигнуты улучшения, читайте далее.

• Улучшенное использование памяти

  • Automerge хранит каждое изменение для офлайн-работы, конфликтов и истории; это требует большого объёма метаданных.
  • Раньше: сжатый колоночный формат «на диске», но при загрузке в память — несжатый вид, из-за чего ОЗУ раздувалось.
  • Теперь: сжатое представление используется и во время выполнения, давая огромную экономию. Пример: вставка «Моби Дика» — было ~700 МБ в v2, стало ~1,3 МБ в v3.
  • Меньше памяти — стабильнее нагруженные сервера синхронизации.
  • Для документов с длинной историей существенно ускорена загрузка (пример: с «не загрузилось за 17 часов» до 9 секунд).

• Упрощение API

  • Два типа строк: «коллаборативные» (сливают правки) и «неколлаборативные».
  • В 1.0: обычные строки для неколлаборативных, класс Text — для коллаборативных.
  • В 2.0 (namespace next): сделали коллаборативный текст по умолчанию — строки для него, RawString для неколлаборативного.
  • В 3.0: закрепили новый подход — удалён Text, API next стал дефолтным; RawString переименован в ImmutableString.

• Попробовать

  • Automerge 3.0 используется по умолчанию в последних @automerge/automerge-repo и @automerge/react (версия 2.1.0).
  • Новичкам — туториал. Существующим кодовым базам — руководство по миграции; если зависите от @automerge/automerge-repo, выполните npm update @automerge/automerge.
  • Проблемы — создавайте issue; вопросы — в Discord.

• Обсуждение вокруг Automerge 3.0: многие впечатлены скачком производительности и «local‑first» подходом к CRDT; сравнивают с Yjs, ElectricSQL, Convex, Zero и интересуются бенчмарками.
• Ключевой апгрейд: сжатое представление данных теперь используется на рантайме — память и время загрузки резко снижены (пример: «Моби Дик»: ~700 МБ → ~1,3 МБ в v3).
• Вопросы по применимости: когда выбирать Automerge/Yjs (совместное редактирование, rich text) vs ElectricSQL (сервер — источник истины, синхронизация приложения). Также интерес к настройкам для «одиночной» кросс‑девайс синхронизации.
• Технические вопросы: структура полурешётки, тип регистра карт (MV-Register vs LWW), поддержка перемещений в деревьях, permissioned-блоки в документе, интеграция с TipTap/ProseMirror, терминальные UI, C/Rust API и состояние C-обёртки.
• Ответы/подсказки: TipTap можно использовать, обернув схему атрибутами Automerge; undo/redo меняется соответствующим образом; ссылки на конфликты в доках; перемещения в деревьях прототипировались (Клепманн), но, похоже, ещё не в основном релизе.
• Практические интересы: какие железо/серверные ресурсы нужны для синка и сколько чтений/записей выдержит; запрос бенчмарков против Yjs и рекомендации по альтернативам (jsonjoy для перформанса).
• Сообщество делится опытом кастомных CRDT, типобезопасностью, бизнес‑правилами и тем, как это вписать в Automerge; часть аудитории всё ещё ищет простое объяснение, «что именно делает» инструмент.