Hacker News Digest

Публикация проекта на Hacker News привела к неожиданному последствию: сайт начал испытывать резкое замедление, причём не сразу, а через несколько дней после публикации. Автор, разрабатывающий «sprinklz.io» — настраиваемый агрегатор новостей с функцией понижения приоритета определённых тем, — изначально списал это на возросшее внимание аудитории. Однако логи показали, что подавляющее большинство запросов даже не пыталось загружать статьи: это был трафик от ИИ-ботов, которые обходили конечные точки, не свойственные обычным пользователям.

Яркий факт: пост набрал около сотни голосов, и пользователи особенно оценили возможность скрывать из ленты материалы про большие языковые модели. Но именно эта популярность обнажила проблему — сайт, построенный как одностраничное приложение, столкнулся с нагрузкой, не связанной с реальной активностью. Автор отметил, что при горстке живых авторизованных пользователей сервер демонстрировал непомерно высокую загрузку. Это заставило его добавить журналирование на уровне всех конечных точек, чтобы выявить источник аномалии.

Публикация на HN часто триггерит агрессивный бот-трафик, который может привести к огромным счетам за облачные ресурсы и DDoS-эффекту даже без популярности поста. Боты начинают сканировать ресурс мгновенно после добавления TLS на поддомен или публикации ссылки на HN, даже если пост не набрал лайков. Рекомендуется блокировать целые ASN крупных облачных провайдеров (AWS, Google Cloud, Azure, Alibaba Cloud, Oracle) — через них идет основной поток злонамеренного скрапинга и поиска уязвимостей. Следует различать типы LLM-трафика: индексаторы (GPTBot, ClaudeBot) можно блокировать, но пользовательские агенты (ChatGPT-User, Claude-User) могут приносить ценных посетителей. Бот-трафик приводит к серьезным финансовым потерям: @QueensGambit сообщил о счете в $10,000 от GCP из-за ClaudeBot, @layerv-ai отмечает резкий рост счетов Vercel даже при наличии защиты Cloudflare. Для борьбы с ботами рекомендуют использовать специализированные списки блокировки (например, blocklist-abuseipdb по совету @pmlnr) или инструменты вроде CF Turnstile (@paaloeye). Чтобы снизить нагрузку и улучшить скорость, советуют отказаться от SPA в пользу кэшируемых статических страниц и серверного рендеринга (@est, @mediumsmart). Альтернатива стандартным прокси-решениям — собственная версия Anubis на Elixir для валидации вызовов внутри приложений (@8by3). Спор о масштабах проблемы: @janalsncm считает, что несколько запросов в минуту легко выдержит даже старый ноутбук, в то время как другие описывают ситуацию как полноценный DDoS и финансовый крах.

WSL 3.x с ядром Linux 6.18 привёл к заметным улучшениям в низкоуровневых операциях по сравнению с WSL 2.x на ядре 6.6. Наибольший прирост наблюдается в памяти: пропускная способность memcpy выросла на 61,35 % — с 7,84 ГБ/с до 12,64 ГБ/с благодаря более крупному размеру страниц при репортинге памяти, что снижает накладные расходы гипервизора. Планировщик и межпроцессное взаимодействие также ускорились: latency контекстного переключения упал на 11,25 %, а производительность в тестах sched/pipe и sched/messaging выросла на 12,68 % и снизилась на 10,06 % соответственно. Базовые системные вызовы вроде getppid() стали быстрее на ~4 %, но здесь ограничения архитектуры процессора оставляют мало места для оптимизаций.

В реальной нагрузке — сборке GoReleaser — общее время уменьшилось на 3,91 % (с 191,27 с до 183,80 с), причём основной выигрыш пришёлся на снижение времени, проведённого в ядре: sys‑time упал на 15,98 % (с 57,39 с до 48,22 с) благодаря меньшим издержкам при открытии файлов, mmap и futex. Однако так как компиляция Go на 80 % зависит от пользовательских вычислений, а vCPU ограничены двумя ядрами на 2,10 ГГц, общий приростwall‑clock времени остался скромным. Вывод: WSL 3.x выигрывает в задачах с высокой интенсивностью IPC и работы с памятью (БД, микросервисы), тогда для вычислительно ограниченных сборок улучшение будет ощущаться преимущественно в снижении нагрузки на ядро, а не в ускорении самого билда.

WSL3 улучшает производительность, но не решает фундаментальные проблемы Windows как ОС. Основная проблема — медленный доступ к файлам через /mnt/c из-за 9P-файловой системы, а не виртуализация. Улучшения в WSL3 (например, +61% пропускной способности memcpy) значимы для разработчиков, но не меняют восприятия WSL как второсортной среды по сравнению с нативным Linux. Многие пользователи, перешедшие на Linux, не планируют возвращаться к Windows из-за нестабильности, принудительных обновлений и ограничений в управлении системой. AI (например, Claude) стал ключевым фактором, позволяющим новичкам преодолевать сложности Linux и ускоряя переход от WSL к нативной системе. WSL3 — это не архитектурный прорыв, а обновление WSL2 до версии 3.0 без изменения гипервизора или фундаментальной модели. Оно не решает проблему отсутствия полноценной интеграции с Windows и считается 'leaky abstraction' с ненужными слоями. Споры о стабильности Windows 11: некоторые называют её надёжной, другие — нестабильной, особенно на ноутбуках Lenovo Legion 5 с проблемами Wi-Fi. Одни видят в WSL незаменимый инструмент для корпоративных пользователей, другие — неудовлетворительное решение, не компенсирующее неудобства Windows. Советы: хранить рабочие файлы внутри WSL-файловой системы, а не в /mnt/c; полностью отказаться от Windows в пользу Linux с AI-помощью; переход на Linux с AI становится решаемым за час вместо дней. WSL стал 'вратами' для многих, кто впоследствии перешёл на нативный Linux и не возвращался. WSL2 и WSL3 не решают проблему производительности при работе с большими файлами — это остаётся ограничением. Воссоздать 'полированный' интерфейс Windows на Linux сложно, и даже dual-boot может быть технически сложной задачей.

Turbopuffer переходит от вектор-ориентированной архитектуры к новой модели, где ANN-индекс становится вторичным, а не основным. В v1 и v2 документы хранились вокруг векторных кластеров, что ограничивало размер блоков данными 100–200 записей — недостаточно для эффективных агрегаций, GROUP BY и полнотекстового поиска. Хотя FTS v2 улучшил ситуацию за счёт фиксированных блоков по 256 записей, фундаментальное ограничение оставалось: все планы запросов были привязаны к структуре векторного индекса. Теперь в v3 хранилище перепроектировано так, чтобы документы могли группироваться оптимальным образом для каждого типа запроса, а векторный поиск стал просто одним из вторичных индексов. Это изменение позволит ускорить все операции — включая текст, regex и SQL-подобные запросы — и заложит основу для масштабирования до более сложных аналитических нагрузок. Уже достигнуто 100% прохождения CI на v3, и команда готовится делиться бенчмарками по производительности в ближайшие недели. Turbopuffer сейчас обрабатывает ponad 1T документов, 10M+ записей в секунду и 25k+ запросов в секунду, и команда уверена, что новая архитектура раскроет его потенциал ещё дальше.

Turbopuffer перешёл к вторичному ANN‐индексу, снижая запись‐амплитуду, аналогично подходам InnoDB и PostgreSQL. В реальных проектах предпочтительнее использовать SQL‐БД с нативной векторной поддержкой, так как они объединяют векторный поиск с полнотекстовым, фильтрами, JOIN‐ами и ACL, устраняя необходимость синхронного слоя. В Turbopuffer v3 ANN‐слоты заменены на внутренние идентификаторы (segment ID, doc ID), а пользовательский ключ стал вторичным индексом — как в InnoDB — что уменьшает стоимость переиндексации при обновлениях. ElasticSearch успешно используется как единый движок для векторного и традиционного поиска, позволяя добавлять векторные запросы к существующим фильтрам и сортировкам. LanceDB реализует ANN как вторичный индекс, храня строки в фрагментах без их перемещения при перестройке индекса, что схоже с архитектурой Turbopuffer v3. Обсуждаются альтернативы: generative поиск и трансформер‐как‐индекс. Отмечается, что векторные БД изначально ориентированы на поиск, а не на хранение, и термин стал маркетинговым. Для больших кодовых баз (десятки миллионов строк) рекомендуется мульти‐БД система вместо готовых векторных СУБД для лучшей производительности. Отсутствие истинных кластерных индексов в PostgreSQL ограничивает производительность при запросах по PK, в отличие от MSSQL и Oracle. Для оценки масштабируемости необходимо измерять p99‐задержку при нагрузке 1 000+ запросов/сек. При проектировании систем с векторным поиском следует учитывать стоимость дополнительного чтения (например, S3 GET) при переходе от прямых указателей к PK‐ориентированным индексам. Ранее высокая запись‐амплитуда в Turbopuffer делала оптимизацию индексации малоэффективной; новая модель уменьшила эту проблему. В дискуссии gopalv сравнивает старый дизайн Turbopuffer с PostgreSQL (оптимизирован под поиск) и новый с MySQL/InnoDB (оптимизирован под записи), тогда как malisper указывает, что выгода от множества индексов в MySQL не полностью компенсирует общие затраты.

Выпуск jemalloc 5.4.0 включает улучшения производительности и исправления ошибок. Добавлена поддержка новых архитектур, включая оптимизации для ARM64 и x86-64, что повышает эффективность распределения памяти в многопоточных средах. Улучшена масштабируемость при высокой нагрузке за счёт доработки внутренних кешей и уменьшения конкуренции за глобальные структуры. Исправлены проблемы с фрагментацией памяти в определённых сценариях аллокации и dealлокации мелких объектов. Обновлён интерфейс для лучшей интеграции с инструментами профилирования и отладки, включая расширенную поддержку статистики через mallctl. Добавлены новые флаги конфигурации для тонкой настройки поведения аллокатора под конкретные рабочие нагрузки. Исправлены утечки ресурсов в редких условиях ошибок инициализации. Релиз совместим с предыдущими версиями по ABI, обеспечивая плавное обновление без пересборки зависимых проектов. Изменения направлены на повышение надёжности и эффективности jemalloc в продакшн-средах, особенно в системах с высокой конкуренцией за память.

Выпуск jemalloc 5.4.0 восстанавливает активность проекта после многолетнего застоя (с 2022 года), что критично для пользователей, зависящих от его стабильности и производительности в продакшене, особенно в Ruby on Rails и многопоточных системах. Jemalloc значительно снижает потребление памяти в Ruby on Rails приложениях: один пользователь зафиксировал падение с 8 ГБ до менее чем 1 ГБ при использовании Sidekiq. Он позволяет отслеживать потребление памяти по потокам и ограничивать нагрузку по бюджету памяти, что полезно для CPU-ограниченных приложений с привязкой потоков к ядрам. Jemalloc эффективнее tcmalloc и mimalloc в сценариях, требующих перпотокового учёта памяти, так как другие аллокаторы не предоставляют аналогичной функциональности. Несмотря на уход Jason Evans, jemalloc продолжает развиваться, и его название (JE — Jason Evans) остаётся историческим наследием, хотя в документации не упоминается явно. Совет: Для приложений на Ruby on Rails в Kubernetes использование jemalloc рекомендовано для снижения потребления памяти и улучшения стабильности. Переход tcmalloc с кешей потоков на кешы CPU обусловлен нестабильностью привязки потоков к ядрам в Linux — потоки могут перемещаться, делая перпотоковые кешы неэффективными. Спор: Некоторые пользователи считают попадание jemalloc 5.4.0 на главную страницу HN необоснованным, другие — оправданным из-за важности проекта для продакшена. Корпоративное участие (например, Meta) в развитии jemalloc не гарантирует долгосрочной поддержки, что подтверждается постмортемом и прекращением активности в прошлом. Фрагментация памяти и масштабируемость в многопоточных средах были ключевыми проблемами, решёнными в jemalloc 5.4.0, что делает релиз значимым для высоконагруженных систем. История jemalloc — пример того, как открытый проект, поддерживаемый крупной компанией, может потерять импульс, и его возрождение — редкое и ценное событие для сообщества. Несмотря на юмористические шутки о происхождении названия («Je m'alloc»), реальное имя происходит от Jason Evans, и это общепринятая традиция в мире malloc-аллокаторов (dlmalloc, phkmalloc).

Go 1.27 выводит язык на новый уровень: впервые поддерживаются generic-методы, позволяющие писать универсальные функции для всех числовых типов без дублирования кода. Например, Rand.N[Int intType](n Int) Int заменяет три отдельных метода для int32, int64 и int. Также теперь можно напрямую инициализировать вложенные поля через ключи — например, Burrow: "Burrow #42" в embedded-структурах. Функции высшего порядка стали ещё гибче: их можно использовать в литералах, конвертациях и каналах без явного указания типов.

Новые инструменты ускоряют разработку: go fix автоматизирует переход на современные практики (например, замену устаревших вызовов на slicesbackward), а go mod tidy упрощает управление зависимостями, группируя их в два блока. В стандартной библиотеке появилось native UUID, SIMD-ускорение для вычислений и новый JSON-парсер с улучшенной производительностью. Особенно важно, что размерно-специализированное выделение памяти сокращает затраты на мелкие объекты на 30%, а профиль goroutineleak теперь доступен по умолчанию — это революция для отладки утечек корутин. Эти изменения делают Go не просто быстрым, но и умным: меньше кода, меньше ошибок, больше производительности.

Generic-методы и инициализация вложенных полей снижают boilerplate, но вызывают риски: регрессии в gopls и linters, баги при перекрытии полей в embedded-структурах (по опыту @pjmlp, @sethops1). Алгоритм uscale для парсинга float не упомянут в релиз-нотах, несмотря на значимый прирост производительности (@e4m2, @dolmen). Стандартный пакет uuid спровоцировал запросы на замену github.com/google/uuid в крупных проектах, включая Kubernetes (@guessmyname, @patabyte). Улучшения SIMD и JSON-парсинга снизили потребление CPU и памяти (@tschellenbach, @todotask2). Споры: о темпах перехода на постквантовую криптографию — проактивность команды crypto (@teabee89) vs. замедление прогресса из-за конкурирующих приоритетов (@halJordan); о философии Go — усложнение и сходство с Java/C# (@pregnenolone, @freakynit) vs. эффективность и удобство многопоточности (@tonymet, @ejboy). LLM эффективны как транслираторы скалярного кода в SIMD-интринсики, но уступают ассемблерной оптимизации (@tyho). На go.dev отсутствует подсветка синтаксиса, затрудняя чтение документации (@xavdid, @pmkary).

Игра, превышающая доступный объём видеопамяти, не обречена на крах — главное ограничение — производительность, а не стабильность. При нехватке VRAM данные выгружаются в системную оперативку, а доступ к ней через PCIe‑4.0x16 (≈ 32 ГБ/с) ограничивает пропускную способность до ~1 ГБ за кадр, что делает невозможным удержание 30 fps, если требуется больше.

Ключевой нюанс — не все обращения одинаковы: небольшие буферы команд и часто используемые данные могут оставаться в CPU‑памяти без катастрофических потерь, особенно если они умеют кэшироваться. Поэтому оптимизация доступа и более тесное взаимодействие драйвера с приложением позволяют смягчить удар по FPS, делая «переполнение» VRAM менее болезненным.

Обсуждение смещает фокус с производительности на стабильность при нехватке RAM/VRAM. Пользователи отмечают критические различия в работе драйверов NVIDIA и AMD под Wayland: старые NVIDIA (750 Ti) вызывают краши композиторов при исчерпании VRAM, тогда как AMD (RX 480) бесшовно выгружает в системную память. Проблемы с утечками и стабильностью под Wayland/Vulkan сохраняются и на новых NVIDIA (2080). Для предотвращения зависаний рекомендуют systemd-oomd или Magic SysRq 'f'. Спор о том, какая ОС лучше справляется с нехваткой памяти: @krisknez утверждает, что Windows не фризит, но @alightsoul и @qwertox опровергают — Windows также зависает при активном swap или ресурсоёмких браузерах (Chromium); @adrian_b считает, что отказ от swap в Linux решает проблему. Поведение macOS неоднозначно: @inventor7777 отмечает сохранение отзывчивости (Ctrl+C работает) на M4 Max даже с артефактами, @LoganDark — сильную деградацию и необходимость перезагрузки после загрузки LLM. Улучшения Linux 7.3 менее значимы для LLM inference, чем для игр — в играх паттерны использования VRAM менее предсказуемы и требуют сложного управления памятью. Рекомендация: выделять 32 ГБ swap на быстрых SSD для комфортной работы с ВМ и тяжёлыми процессами. В Ubuntu 24 OOM-killer по умолчанию часто убивает Firefox, даже если память потребляют другие процессы — вызывает раздражение.

Команда Skald переписала бэкенд с Python на Node.js всего через неделю после запуска, идя против стандартного совета стартапам сначала "делать то, что не масштабируется". Основная причина — сложность с асинхронностью в Python, особенно при работе с Django. Автор отмечает, что писать качественный асинхронный код на Python "очень сложно и неинтуитивно", в отличие от JavaScript с его event loop или Go с goroutines.

Django до сих пор не имеет полной поддержки асинхронности: нет нативного асинхронного файлового ввода-вывода, ORM не поддерживает async, а для интеграции синхронных и асинхронных функций требуется постоянно писать sync_to_async и async_to_sync. Даже крупные компании вроде PostHog, несмотря на наличие AI-фич, продолжают использовать традиционный WSGI вместо полного перехода на асинхронность. В итоге команда пришла к выводу, что Django скоро начнет создавать проблемы с производительностью даже при небольшом количестве пользователей.

• Обсуждение в основном вращается вокруг того, что Python/async-экосистема остаётся незрелой, а Django-ORM не предназначена для асинхронной работы, что делает выбор между «старым, но проверенным» и «новым, но сырым» неоднозначным.
• Участники спорят, стоит ли жертвовать удобством разработки и экосистемой ради производительности, или же лучше переписать всё на Node/TypeScript, если речь идёт о высоконагруженном REST API.
• Поднимается вопрос о том, что выбор стека влияет на набор инженеров, и что важнее — удобство разработки или производительность.
• Некоторые участники подчеркивают, что важно не только выбрать правильный инструмент, но и уметь его использовать, иначе даже самый современный фреймворк не спасёт от проблем с масштабированием.

Предоставленный контент — это навигационное меню GitHub для репозитория "samrolken/nokode", без описания самого проекта. На странице отсутствует информация о функционале, целях или особенностях nokode.

В интерфейсе присутствуют стандартные элементы GitHub: поиск, разделы для Enterprise, Pricing, Open Source, Resources и Solutions. Нет ни README, ни кода, ни обсуждений — только базовая структура страницы репозитория.

Для получения информации о проекте потребуется доступ к содержимому репозитория или его документации.

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

Пять лет после выхода первых Mac с чипами M1 показали, что предсказуемые обновления — это именно то, чего мы хотели. Автор статьи цитирует Джона Грубера, который в 2020 году отмечал, как M1 сломал компромисс между производительностью, нагревом и временем работы от батареи. Несмотря на это, некоторые называют M5 «скучным incremental-обновлением», что, по мнению автора, как раз и является целью.

В эпоху PowerPC и Intel Mac иногда годами не получали значительных апдейтов, а проблемы с перегревом и неудачные решения вроде клавиатуры-бабочки были обычным делом. Теперь, когда Apple контролирует собственную silicon-архитектуру, компания может регулярно выпускать чипы с последовательным улучшением производительности и эффективности. Графики Geekbench показывают значительный прирост производительности CPU и GPU от M1 до M5, и для большинства пользователей, не меняющих компьютеры каждый год, каждое обновление будет ощутимым.

Это и есть успех Apple silicon — не революция, а эволюция, которая обеспечивает стабильный прогресс. Назвать такие достижения «скучными» — значит упускать суть и игнорировать то, что мы сами и требовали от Apple после перехода с Intel.

• Пользователи обсуждают, что ежегодные обновления процессоров в MacBook не всегда вызывают восторг, но важно, чтобы покупатели не вынуждены были покупать устаревший продукт без понимания, когда будет обновление.
• Некоторые отмечают, что Apple не предоставляет достаточно новых функций, чтобы оправдать обновление, и что они хотели бы, чтобы Apple сосредоточилась на улучшении программного обеспечения.
• Обсуждается, что Apple Silicon делает возможным запуск локальных моделей ИИ, но не все считают, что это оправдывает ежегодные обновления.
• Участники обсуждают, что Apple не предоставляет достаточно новых функций, чтобы оправдать обновление, и что они хотели бы, чтобы Apple сосредоточилась на улучшении программного обеспечения.

PostgreSQL 18 представляет поддержку UUIDv7, нового типа универсально уникальных идентификаторов, решающего проблемы производительности традиционных UUIDv4. В отличие от полностью случайного UUIDv4, UUIDv7 включает временную метку как наиболее значимую часть своей 128-битной структуры, обеспечивая естественную сортировку по времени создания. Это открывает возможности для более эффективного использования UUID в качестве первичных ключей в базах данных.

В статье демонстрируется сравнительный анализ производительности между UUIDv4 и UUIDv7 через создание двух таблиц для "магазина крабов" с использованием Aiven for PostgreSQL. Авторы предоставляют практические примеры кода для создания сервиса и таблиц, а также функцию для вставки случайных данных. Тесты показывают, что UUIDv7 может значительно улучшить производительность операций вставки по сравнению с UUIDv4, особенно при работе с большими объемами данных.

• UUIDv7 раскрывает время создания записи, что может быть критично для приватности и безопасности, особенно если первичный ключ публично доступен.
• Эксперты рекомендуют использовать UUIDv7 только для внутренних ключей и выставлять отдельный UUIDv4 как публичный идентификатор.
• Но в большинстве случаев, когда выбор между UUIDv7 и v4, важно учитывать, что v7 предоставляет лучшую производительность при вставке и сортировке, но требует дополнительных усилий для защиты приватности.

SQLite написан на C, а не на более современных языках, по нескольким ключевым причинам.

Производительность и контроль: C позволяет разработчикам писать код, который выполняется максимально близко к аппаратному уровню, что критично для низкоуровневых библиотек, таких как SQLite. Хотя некоторые языки могут заявлять о схожей производительности, C остается эталоном. Кроме того, его "портабельность" (работа практически на любой платформе) делает его универсальным.

Совместимость и стабильность: Библиотеки на C могут использоваться практически из любого другого языка программирования, что делает SQLite доступным для разработчиков на разных платформах и в разных экосистемах. C также является зрелым и стабильным языком, что минимизирует риски, связанные с изменчивостью более молодых языков.

Минимальные зависимости: В отличие от многих современных языков, которые требуют объемные среды выполнения, код на C имеет минимальные зависимости. Это делает развертывание легким и надежным, что критично для встраиваемых систем, где SQLite часто используется.

Хотя существуют аргументы в пользу использования объектно-ориентированных или "безопасных" языков (таких как Rust), эти варианты были либо недоступны, либо незрелы, когда начиналась разработка SQLite. Более того, переход на новый язык потребовал бы значительных усилий без гарантии улучшений, особенно учитывая, что SQLite уже хорошо отлажен и оптимизирован в своей текущей реализации на C.

• Обсуждение вращается вокруг того, стоит ли переписывать SQLite на другие языки, но аргументы сводятся к тому, что существующий код уже безупречен, а переписывание может внести новые баги и даже замедлить работу.
• Подчеркивается, что SQLite — это не только код, но и 100% покрытие тестами и 25 лет отладки, что делает язык менее важным, чем для других проектов.
• Участники обсуждения отмечают, что языки вроде Rust всё ещё молоды и меняются, а также не предоставляют преимуществ в контексте уже готового кода.
• Поднимается вопрос о том, что важнее — язык или разработчики, и подчеркивается, что последние могут писать на любом языке, если бы это действительно было нужно.

Почему Wi-Fi в домашних условиях часто работает плохо? Потому что маркетинг и потребительская психология заставляют производителей и провайдеров выставлять по умолчанию широкие каналы 80 МГц вместо 20/40 МГц, что приводит к перегрузке эфира и соседским помехам. А ведь профессионалы знают, что узкие каналы дают больше свободных частот и лучше масштабируют сеть. Но продавать «широкий» канал как «фичу» выгоднее.

Кроме того, популярные онлайн-тесты скорости, которые пользователи любят запускать, сами по себе создают конкуренцию за эфирное время и ухудшают качество связи для всех устройств в сети. Это показывает, что «скорость» как метрика качества Wi-Fi вредоносна сама по себе.

• Wi-Fi оптимизирована под скорость, а не под надежность, что приводит к перегрузке каналов и влияет на задержки и потери пакетов, что особенно критично в плотно населенных местах.
• Пользователи часто не осознают, что их сети могут быть перегружены из-за соседей, и что это может быть причиной проблем, которые они приписывают провайдеру или оборудованию.
• Провайдеры и производители оборудования продолжают продвигать "скорость" как единственную метрику качества сети, потому что это легко продавать, даже если это не отражает реальную производительность сети.
• В действительности, наилучшая производительность Wi-Fi достигается при использовании Ethernet кабеля для стационарных устройств, оставляя Wi-Fi для мобильных устройств, где это действительно необходимо.

Python 3.14 вышел 8 октября 2025 года. Автор сравнил его с 3.9-3.13, а также с PyPy 3.11, Node.js 24 и Rust 1.90. Для тестов использовались два скрипта: рекурсивный расчет 40-го числа Фибоначчи и пузырьковая сортировка 10 000 элементов. Все тесты запускались на ноутбуке с Intel Core i5 под Ubuntu и ноутбуке Apple M2 под macOS.

Результаты: CPython 3.14 оказался на 10-15% быстрее 3.13 и примерно вдвое быстрее 3.9. JIT в 3.14 работает стабильно, а в 3.13 еще может выдавать сбои. Free-threading в 3.14 показал себя как надежный способ распараллеливать задачи, но прирост не столь драматичен, как ожидалось. PyPy 3.11 оказался в 2-3 раза быстрее CPython 3.14, но требует в 2-3 раза больше памяти. Node.js и Rust оказались в 2-3 раза быстрее, но это сравнение не совсем корректно, так как они не тестировали рекурсию.

• Пользователи обсуждают производительность Python 3.14, сравнивая его с PyPy и другими языками, и обсуждают, почему сообщество продолжает тратить усилия на ускорение CPython вместо перехода на PyPy.
• Несколько комментаторов отмечают, что 3.14 всё ещё значительно уступает PyPy и даже Node.js в ряде тестов, хотя и демонстрирует прогресс.
• Обсуждается, почему Python не может быть переименован в π-thon, несмотря на то, что это было бы логично, и почему не используется возможность перехода на PyPy, несмотря на то, что он быстрее.
• Участники также обсуждают, что, несмотря на то, что Python всё ещё остаётся медленным, он остаётся незаменимым для прототипирования и имеет огромную экосистему библиотек, что делает его незаменимым для многих задач.
• Наконец, обсуждается, что, несмотря на то, что Python медленный, он всё ещё может быть использован для большинства задач, и что важнее всего - он всё ещё может быть использован для большинства задач.

Хороший вкус в разработке — это не техническое умение, а способность выбирать набор инженерных ценностей, подходящих конкретному проекту. В отличие от навыков, которые можно развить учёбой и практикой, вкус формируется через личный опыт и предпочтения. Например, одни разработчики ценят читаемость кода с map и filter, другие — производительность for-циклов, и это различие отражает их приоритеты, а не уровень компетенции.

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

• Обсуждение определяет "хороший вкус" в разработке как способность выбирать оптимальные решения, основанные на контексте и требованиях проекта, а не на личных предпочтениях.
• Участники подчеркивают, что хороший вкус тесно связан с опытом, гибкостью, умением аргументировать выбор и предвидеть последствия решений для поддержки и масштабирования.
• Многие отмечают, что хороший вкус — это баланс между читаемостью, производительностью, простотой и соответствием бизнес-целям, а не слепое следование догмам или модным тенденциям.
• Спорным остается вопрос, является ли "вкус" субъективным эстетическим понятием или его можно формализовать через принципы инженерии (например, поддерживаемость, ясность, минимальная сложность).
• Некоторые видят корень проблемы в смешении объективно плохих решений (например, неэффективные алгоритмы) и субъективных предпочтений (стиль кода, выбор парадигм).

Redis показал заметно лучшую производительность по сравнению с Postgres при использовании в качестве кэша. В тестах на чтение Redis обрабатывал больше запросов в секунду, при этом нагрузка на CPU у сервера с Redis была умеренной (~1280mCPU из доступных 2000mCPU), а потребление памяти стабильно держалось на уровне ~3800 МБ. Сервер HTTP стал узким местом в случае Redis, исчерпав свои CPU-ресурсы.

Для Postgres основным ограничением стал CPU самой базы данных, который постоянно работал на максимуме. Это подтверждает, что Redis эффективнее справляется с высоконагруженными сценариями кэширования, особенно когда требуется низкая задержка и высокая пропускная способность операций чтения.

• Критика методологии бенчмарка: сравнение ненастроенных Postgres и Redis считается некорректным, так как Postgres требует тонкой настройки под железо для серьёзных тестов.
• Сомнения в целесообразности использования Postgres как кэша: отсутствие встроенного TTL, нагрузка на основную БД и сложности с вакуумом делают Redis более надёжным решением.
• Подчёркивается важность контекста: для небольших нагрузок (<1000 RPS) и упрощения стека использование Postgres может быть оправдано.
• Замечания о специфике теста: сравнение ограниченного Postgres (2 ядра) с неограниченным Redis, малый размер данных и отсутствие пайплайнинга искажают результаты.
• Обсуждаются альтернативы: использование UNLOGGED таблиц, специализированных клиентов (rueidis) или встроенного кэша приложения вместо распределённого решения.

Приложения на Electron вызывают серьёзные задержки в работе всей системы на macOS 26. Пользователи сообщают о замедлении интерфейса, лагах при вводе текста и проблемах с отзывчивостью даже при минимальной нагрузке. Это связано с тем, что фреймворк использует общие ресурсы системы неэффективно, особенно в многозадачных сценариях.

Проблема проявляется при одновременной работе нескольких Electron-приложений, таких как Slack, Discord или VS Code. Система начинает проседать по производительности, что негативно сказывается на пользовательском опыте. Разработчики Electron признают проблему и изучают её, но пока не предложили конкретного решения.

• Проблема с производительностью в macOS 26 вызвана использованием приложениями (включая Electron) приватных API Apple, что приводит к утечкам ресурсов и лагам.
• Некоторые пользователи не сталкиваются с проблемами, возможно, из-за высокой производительности железа (например, чипов M4), которое маскирует недочеты.
• Обсуждается, кто виноват: разработчики приложений за использование приватных методов или Apple за отсутствие регрессионного тестирования и обратной совместимости.
• Для части приложений (Chrome/Chromium) уже выпущен фикс, а также известны временные решения через терминал.
• Спектр мнений варьируется от критики Electron до защиты его как кросс-платформенного решения с хорошим DX.

Новички в программировании часто зацикливаются на изучении структур данных и алгоритмов (DSA), потому что это проверяется на собеседованиях. Однако в реальной работе редко приходится реализовывать сложные алгоритмы вручную — вместо этого стоит понять базовые структуры, их trade-offs и основы Big O, чтобы эффективно организовывать и обрабатывать данные.

Гораздо полезнее сосредоточиться на тестировании: это навык, который постоянно применяется в разработке, улучшает качество кода и выделяет кандидата на фоне других. Тестирование помогает проектировать системы, учит писать проверяемый код и становится отдельной инженерной дисциплиной с богатым инструментарием.

• Участники обсуждают важность знания структур данных и алгоритмов (DSA) для разработчиков, отмечая, что понимание их характеристик (например, сложности операций) часто важнее умения реализовывать их с нуля.
• Подчеркивается необходимость баланса между теоретическими знаниями (DSA) и практическими навыками тестирования, при этом многие отмечают, что эти навыки не исключают, а дополняют друг друга.
• В дискуссии звучит критика статьи, указанной в исходном посте, за её провокационный заголовок, который, по мнению участников, упрощает сложную проблему и создает ложную дихотомию между DSA и тестированием.
• Несколько комментаторов приводят примеры из практики, где незнание базовых принципов DSA (например, сложности алгоритмов) приводило к серьезным проблемам с производительностью в продакшене.
• Обсуждается роль тестирования: одни видят в нем ключевой навык для обеспечения качества, другие указывают на его ограничения (например, сложность тестирования многопоточных систем) и необходимость сочетать его с другими методами, как property-based тестирование или формальные доказательства.

Добро пожаловать на LWN.net

Этот материал для подписчиков стал доступен благодаря читателю LWN. Тысячи подписчиков зависят от LWN как от источника новостей о Linux и свободном ПО. Если статья вам понравилась, пожалуйста, рассмотрите возможность оформления подписки. Спасибо за визит!

Антонио Куни, давний инженер по производительности Python и разработчик PyPy, на EuroPython 2025 в Праге представил доклад «Мифы и сказки про производительность Python». По его мнению, привычная «мудрость» о скорости Python часто вводит в заблуждение. На примерах он показал реальные узкие места и пришел к выводу: в конечном счете предел оптимизаций упирается в управление памятью. Он начал ранний проект SPy, который, возможно, приведет к сверхбыстрому Python.

Он попросил зал поднять руки, кто считает «Python медленным или недостаточно быстрым» — рук было много (в отличие от PyCon Italy). Годы работы с производительностью и общение с разработчиками породили набор мифов, которые он хочет развеять.

Мифы

Миф: «Python не медленный». Да, часто «достаточно быстрый», особенно как «склеечный» язык в эпоху «важен только GPU». Но это верно лишь для части задач. Есть множество программ, где скорость Python критична — отсюда постоянные усилия по оптимизации интерпретатора и перенос горячих участков в Cython, Numba и т.п.

В слайдах он показал множества: «программы, где Python достаточно быстр» — подмножество «всех Python-программ», а снаружи — «все возможные программы». В идеале Python должен подходить для всех; пока что задачи, требующие максимума от процессора, не могут быть на Python. Он хочет расширять «внутренние круги».

Королларий «это всего лишь клей»: «просто перепишите горячее в C/C++» (сегодня — в Rust). Прием рабочий, но быстро упирается в стену: принцип Парето подсказывает оптимизировать 20% кода, где 80% времени, но затем срабатывает закон Амдаля — ускорив горячую часть, вы упираетесь в остальной код, который начинает доминировать во времени выполнения.

Еще миф: «Python медленный, потому что интерпретируемый». Интерпретация — лишь малая часть. Даже выражение p.x * 2 в C/C++/Rust — это загрузка, умножение, сохранение. В Python же нужно определить тип p, вызвать getattribute(), распаковать p.x и 2, выполнить операцию с учетом перегрузок и протоколов, упаковать результат, выделить память и т.д. Это диктуют семантика и динамичность языка, не способ исполнения.

Статические типы

С распространением тайпингов слышно: «теперь компиляторы могут пропускать лишнее и считать напрямую». Пример:

def add(x: int, y: int) -> int:
    return x + y

print(add(2, 3))

Но аннотации не применяются во время выполнения, и можно вызвать:

print(add('hello ', 'world'))  # type: ignore

Чекер доволен, но семантика сложения уже другая. Аннотации бесполезны для оптимизации и скорости, если их не гарантирует рантайм. Более того, в Python легально перегружать операции, меняя поведение в рантайме, что разрушает предпосылки для агрессивных оптимизаций.

• Обсуждение сосредоточено на мифах о скорости Python: динамичность языка, непредсказуемость типов и плохая кэш-локальность мешают компиляторам и JIT достигать производительности системных языков без компромиссов по совместимости и простоте.
• Многие отмечают, что JIT и спекулятивное выполнение помогают на «хэппи-пате», но становятся хрупкими: небольшие изменения кода могут срывать оптимизации и резко просаживать скорость.
• Популярные пути ускорения — PyPy, Numba, Pythran, mypyc, а также перенос «горячих» участков в C/C++/Rust или использование DSL/субсетов (SPy); однако граница вызовов и динамика Python часто «съедают» выгоды.
• Отмечают альтернативы и эволюцию: Mojo как супермножество Python с статикой и компиляцией, возможное сосуществование компиляторов рядом с CPython вместо «Python 4».
• Критики указывают, что популярность Python не доказывает его производительность; многие реальные «тормоза» — это не CPU, а I/O и сеть, где помогают async и масштабирование.
• Скептики считают, что «быстрым» Python не станет без отказа от ключевых динамических свойств (примерно как в JS — оптимизации на общий случай, но с ограничениями); часть участников предлагает оставлять Python для скриптинга и клеевого кода.
• Вопросы многопоточности, старта интерпретатора и GIL остаются проблемными; параллельно обсуждают идеи «final»-квалификаторов, иммутабельности и GPU/параллельных подходов, но признают их практические ограничения.