Hacker News Digest

Маленькие знания часто дают большой эффект в повседневной работе инженера. Например, ctrl + r в терминале можно улучшить с помощью fzf для нечёткого поиска истории или atuin, который хранит историю в SQLite и позволяет искать по директориям. В SQL можно выполнять SELECT без FROM — удобно для тестирования функций или проверки выражений вроде SELECT TRUE <> NULL. Для оптимизации запросов в PostgreSQL и MySQL полезно EXPLAIN ANALYZE, которое выполняет запрос и показывает детальную производительность. В регулярных выражениях \b помогает находить границы слов, а логарифмы удобны для bucketing метрик — например, Math.floor(Math.log10(count)) группирует значения по порядкам величины. В современном JavaScript полезны Array.flatMap, Object.entries и Promise.withResolvers, а в Node.js — повторное использование HTTPS-соединений через https.Agent, что снижает латентность. В Git: git log -S pattern ищет коммиты, где строка была добавлена или удалена («git pickaxe»), git checkout - переключается на предыдущий HEAD, а вместо find часто достаточно **/*.md при включённом globstar в Bash. Для поиска по содержимому файлов лучше использовать rg (ripgrep), а в Zsh стоит включить автодополнение через compinit и настроить FPATH для функций от Homebrew. Эти приёмы не требуют глубоких знаний, но экономят время и снижают когнитивную нагрузку. Аналогично в компаниях ценны небольшие внутренние лайфхаки: какой источник данных смотреть при проблеме, кто эксперт в определённой области, где лежит документация по сложной теме, когда нужно вручную масштабировать систему, какая команда делает rolling restart, какой утилитой удобно скриптировать рутинную задачу. Один такой совет в день — достаточно, чтобы не перегружать команду, но полезно для тех, кто ещё не знал этого трюка. Даже если вы знаете 9 из 10, десятый может сэкономить час работы и спровоцировать полезное обсуждение. Старшим инженерам стоит делиться такими знаниями — они формируют культуру эффективной работы.

Эффективность мелких трюков зависит от привычки и системного закрепления, а не от их наличия. Инженеры годами используют неоптимальные методы из-за привычки и лени, несмотря на знание более быстрых альтернатив. Записывайте полезные трюки в легко доступный документ — это помогает вспомнить их при необходимости, не полагаясь на память или поиск в интернете. Размещайте чит-листы на стене или в рабочем пространстве — физическое присутствие подсказок повышает вероятность их применения. Создавайте bash-алиасы или скрипты, которые 'порицают' за использование устаревших команд — это формирует новую привычку (как @lelandbatey с git switch). Храните редко используемые, но важные команды в файле типа ~/scratch.txt с grep-доступом — это надежнее, чем история shell. Используйте zoxide вместо cd — он запоминает частые директории и позволяет прыгать между ними без цепочек ../.. (как @disinterred). Используйте zhist для улучшенного поиска истории Zsh с контекстом — он лучше стандартного fzf (как @overflowy). Сохраняйте полезные команды в Makefile или инструментарии приложения — это делает их воспроизводимыми и устраняет необходимость вводить их вручную (как @cachvico). Пишите полезные трюки на собственном сайте — это делает их долговечными и удобными для обмена (как @AJRF). Изучайте трюки, наблюдая за тем, как AI выполняет задачи — часто AI использует неизвестные вам команды (например, в perf, как @kccqzy и @SebasDev). Спор: Некоторые считают, что трюки вроде SELECT без FROM зависят от СУБД — например, IBM-продукты могут не поддерживать это (как @rf15). Спор: Некоторые считают, что эти трюки — не программирование, а администрирование или CLI-навыки (как @ozim и @1vuio0pswjnm7). Спор: Некоторые считают, что трюки устаревают из-за AI — например, @bufordtwain и @monideas считают, что AI делает их менее полезными. Используйте git ls-files вместо find для поиска файлов в репозитории — это быстрее и точнее (как @lucasoshiro). Используйте rg --hidden -g '!*.lock' для фильтрации шума в поиске — это эффективно для повседневной работы (как @ahmedhossamdev). Используйте pbcopy на macOS для копирования вывода команды в буфер обмена — это ускоряет работу с API-ответами (как @okinternets).

Современные инструменты, особенно LLM, радикально снизили барьер для оптимизации производительности. То, что раньше требовало экспертов в ассемблере, JIT-компиляторах или глубокой оптимизации под конкретный хардвер, теперь может сделать любой разработчик, задав правильный запрос. Пример — FRE, регулярное выражение, созданное агентом за месяц и оптимизированное под набор тестов rebar: его AOT-скомпилированная версия показала отличную производительность на длинных поисках, хотя и тратила ресурсы на компиляцию. Это открывает путь к гибридным решениям — например, запускать компилятор в фоне при работе ripgrep и переключаться на оптимизированный код, когда он готов, жертвуя скоростью для коротких запросов ради выигрыша на долгих.

Такой подход — не редкость, а новая норма. Как и JIT-компиляторы, которые раньше считались слишком сложными для внедрения, теперь их можно написать за минуты. Это позволяет создавать «сделанные на заказ» решения под конкретные рабочие нагрузки, как в демосцене или FFTW, а не универсальные библиотеки. Технологии больше не ограничивают амбиции: если раньше писали «достаточно хорошо», теперь можно добиваться максимальной скорости — даже если это требует нестандартных трюков. Производительность перестала быть привилегией элиты и стала доступной для всех.

LLM не решают проблему медленности ПО — основные причины: сетевые задержки (особенно из-за географической удаленности), архитектурные компромиссы (синхронность, буферы, изоляция ресурсов) и системные накладные расходы ОС, а не алгоритмическая неэффективность. LLM эффективны только при чётких метриках (бенчмарки, regex): например, оптимизировали SafeRE (Java) или снизили загрузку фронтенда с 4с до 750мс. Но они плохо справляются с оптимизацией памяти, кэшей, низкоуровневых механизмов и аппаратных особенностей — в обучающих данных преобладает неэффективный код, а LLM не понимают реальных ограничений, что приводит к ошибкам аллокации (например, ChatGPT на macOS потребляет до 50 ГБ). LLM работают с абстракциями, не способны к экстремальной оптимизации (демосцена, сложные движки) и не учитывают компромиссы поддержки кода, поэтому многие оптимизации (mawk 2.0, специфичные JIT) не внедряются. Эффективность зависит от качества спецификации: без чётких критериев приёмки агенты не гарантируют скорость и корректность. AI-код часто накапливает избыточные изменения, ухудшая долгосрочную производительность (парадокс Джевонса). Оптимизация стала функцией затрат: если рынок не требует скорости, ресурсы не вкладываются. Минимальный стек (node, express, ejs, pg) даёт лучшую производительность, чем перегруженные фреймворки. LLM могут формально доказывать корректность кода и снижать баги, но экономика (стоимость RAM, токенов) и аппаратные ограничения остаются главными регуляторами производительности.

В версии ripgrep 15.2.0, собираемой под x86_64‑unknown‑linux‑musl, иногда возникает SIGSEGV при поиске по очень большим каталогам при высокой степени параллелизма. Ошибка проявляется в момент вызова calloc внутри opendir, когда проверка целостности кучи в MUSL‑mallocng падает. Для воспроизведения требуется массив файлов порядка 20 GiB и 1.8 млн файлов; достаточно запустить цикл rg <незначающаяся строка> и дождаться сбоя, что обычно происходит через минуту на 24‑ядерной машине с достаточным свободным RAM. Сборка производилась с debug‑символами через cross‑toolchain, а в бинарнике включены функции PCRE2 10.45 с поддержкой JIT.

Следствие backtrace указывает, что сбой происходит в get_meta (../src_musl/src/malloc/mallocng/meta.h:141) и заканчивается в цепочке вызовов std::fs::read_dir → ignore::walk::Worker::run → std::thread::spawn. При этом в стеке виден вызов calloc из opendir и падение в std::panic::catch_unwind. Таким образом, проблема связана с некорректной работой динамического распределения памяти в MUSL при одновременном обходе большого количества директорий, что приводит к повреждению метаданных кучи и аварийному завершению процесса. Кроме того, в стеке видно, что сбой происходит в контексте пула потоков ignore::walk, где каждый поток одновременно читает каталоги, что усиливает конкуренцию и ускоряет появление ошибки.

Тред обсуждает причины SIGSEGV в ripgrep при поиске по большим каталогам, включая проблемы с musl-аллокатором при многопоточности, которые могут снижать производительность. По опыту @Orphis, замена musl на mimalloc улучшает производительность в 20 раз. Проблемы могут быть связаны не только с аллокатором, но и с подходом к поиску и обработке данных. Рекомендуется использовать альтернативные аллокаторы, такие как mimalloc.