Hacker News Digest

Qodo Command набрал 71,2 % на SWE-bench Verified — стандартном бенчмарке для оценки способности агентов решать реальные задачи из GitHub.

• SWE-bench Verified включает 500 задач из 12 популярных репозиториев (Django, scikit-learn, sympy и др.).
• Каждая задача: описание бага/фичи + тест, который должен проходить после исправления.
• Оценивается только успешность прохождения тестов; стиль и качество кода не учитываются.

Результаты

• 71,2 % — новый рекорд среди публичных решений.
• +18,2 п.п. от предыдущего лидера (CodeStory Aide).
• +31,2 п.п. от первого релиза SWE-bench (2023).

Ключевые инсайты

• Контекст важнее модели: использование 128k-токенного окна и RAG-поиска по 500+ файлам дало +12 %.
• Итерации решают: 3–5 попыток сборки/тестов повышают успех на 8 %.
• Маленькие PR легче: задачи <30 строк кода решаются в 84 % случаев, >200 — лишь 38 %.

Что дальше

• Публикация детального тех-отчёта и открытого датасета.
• Расширение до 1 000 задач и добавление новых языков (Go, Rust).

• Qodo показал 71,2 % на SWE-bench-verified — 5-е место, всего на 1 % уступая официальному Claude Sonnet 4.
• Участники сомневаются в честности результатов и просят независимую платформу с peer-review.
• Поднимаются вопросы о стоимости, эффективности, размере модели и специфике подготовки именно под тест.
• Обсуждают, что сам бенчмарк «закрыт» для Python-ошибок и не отражает реальную разработку.
• Некоторые уже отказались от Qodo в пользу BugBot и сомневаются в жизнеспособности «обёрток» над LLM.

GitHub репозиторий danterolle/tilf

Публичный репозиторий, форков нет.

Навигация

• Продукты: Copilot, Spark, Models, Advanced Security, Actions, Codespaces, Issues, Code Review, Discussions, Code Search.
• Решения: по размеру компании, сценариям (DevSecOps, CI/CD) и отраслям (здравоохранение, финансы и др.).
• Ресурсы: статьи по AI, DevOps, безопасности; вебинары, электронные книги, истории клиентов.
• Open Source: Sponsors, ReadME Project, темы, тренды, подборки.
• Enterprise: платформа, Advanced Security, Copilot для бизнеса, премиум-поддержка.
• Цены: github.com/pricing.

Поиск
Поддерживает фильтры и сохранённые запросы. Требуется вход для настройки уведомлений и форков.

• Пользователи делятся инструментами для создания пиксель-арта (unfake.js, PixelLab, mtPaint, Aseprite, LibreSprite).
• Автор Tilf подтвердил: проект ручной, зависит только от PySide6, собран PyInstaller’ом, иконки и логотип нарисованы вручную/частично с AI.
• Название Tilf = «Tiny Elf» («крошечный эльф»), выбрано за простоту и образ.
• Предложены улучшения: сдвиг строк/столбцов, добавить GitHub-теги, нарисовать логотип пиксель-артом.
• Сообщество обсуждает «стыд за AI-код» и отмечает приятную «домашнюю» атмосферу проекта.

• Добавлена поддержка моделей Mistral-Small-3.1-24B-Instruct-2503 и Mistral-Small-24B-Instruct-2501
• Улучшена работа с Mamba-2 и Sliding Window Attention
• Новые правила конвертации: convert-hf-to-gguf.py теперь корректно обрабатывает sliding_window, mamba2, attention_bias, tie_word_embeddings
• Обновлён llama_model_loader и llama_model: добавлены поля mamba2 и sliding_window, упрощена логика KV-cache
• Поддержка mamba2 в llama_context и llama_decode
• Удалены устаревшие llama_model и llama_vocab
• Добавлены тесты test-mistral.py и test-mistral-vision.py

• Mistral предлагает mistral-common как официальный токенизатор, но пока только через Python-библиотеку и временный REST-обвязанный FastAPI.
• Сообщество жалуется: «cpp-бинарь, зависящий от Python-сервера — временное и грустное решение», ждут нативный C++ порт.
• Пользователи расстроены, что Mistral, выпуская веса, не сразу поддерживает llama.cpp, на котором держится большинство «домашних» запусков.
• Некоторые замечают, что llama.cpp и так тянет Python для шаблонов, но это не отменяет желания увидеть полноценную C++ реализацию.
• Сторонники Mistral отвечают: компания маленькая, пока не ясно, какие именно инференс-фреймворки поддерживать, зато открыли собственный mistral-inference.

Переписал Ghuloum-туториал на Python (~300 строк). Убрал читалку S-выражений и бинарный код — теперь текстовая ассемблерная печать.

Lambda-lifting требует:

• знать связанные переменные;
• собирать свободные переменные лямбд;
• накапливать создаваемые code-объекты.

Связывают let и lambda; для них обновляем окружение.

Lifter

class LambdaConverter:
    def __init__(self):
        self.labels = {}

    def convert(self, expr, bound, free):
        match expr:
            case int() | Char() | bool():
                return expr
            case str() if expr in bound or expr in BUILTINS:
                return expr
            case str():
                free.add(expr)
                return expr
            case ["if", t, c, a]:
                return ["if",
                        self.convert(t, bound, free),
                        self.convert(c, bound, free),
                        self.convert(a, bound, free)]

lift_lambdas запускает обход и возвращает (labels …).

Lambda

Лямбда:

• связывает параметры;
• выделяет код;
• захватывает внешнее окружение.

Пример:

(lambda () x)  ; x свободна

превращается в

(labels ((f0 (code () (x) x)))
  (closure f0 x))

Даже если x связан снаружи, внутри лямбды он считается свободным.

• Участники рекомендуют три современные книги по компиляторам, вдохновлённые статьёй Ghuloum: «Writing a C Compiler» (Sandler), «Essentials of Compilation» на Racket и Python (Siek).
• Обсуждали «lambda lifting»: преобразование, выносящее замыкания наверх, уменьшая их размер вплоть до полного исчезновения.
• Уточнили, что «lambda lifting» в статье связан с разделом 3.11 о сложных константах в Scheme.
• Разбирали, почему современный ИИ использует Python, а не Lisp: удобство как «клея» для C++/CUDA, упадок доли рынка Lisp и смена парадигмы ИИ.

POML — язык разметки Prompt Orchestration Markup от Microsoft.
Проект в открытом доступе на GitHub: microsoft/poml.

• Назначение: структурировать, версионировать и переиспользовать промпты для LLM.
• Формат: YAML-подобный, читаемый человеком и парсером.
• Возможности:
  – параметризованные шаблоны,
  – условные ветвления,
  – импорт фрагментов,
  – метаданные (автор, версия, модель).
• CLI: poml build → компиляция в чистый текст, poml test → прогон с примерами.
• CI/CD: экшены GitHub для валидации и деплоя промптов.
• Интеграции: Python SDK, VS Code-расширение, экспорт в OpenAI, Azure, Bedrock.

• POML — это XML-подобный DSL от Microsoft Research для «view-слоя» промптов, но выглядит как «JSX, только хуже» и заставляет писать код в строках.
• Участники сравнивают его с YAML-промптами GitHub, BAML (TypeScript-подобные схемы), Jinja и обычным XML, споря о необходимости новой библиотеки.
• Критика: один контрибьютор при $3T-спонсоре, нет SDK для .NET/C#, лишний tooling, «IP squatting», циклы в XML выглядят как костыль.
• Ирония: из-за потребности в точности неформальные LLM-промпты всё структурнее, как юридические документы.

abogen — консольный инструмент, превращающий EPUB, PDF и обычный текст в аудиокниги с синхронными субтитрами.

Возможности

• Форматы: EPUB, PDF, TXT.
• TTS-движки: Coqui TTS, OpenAI TTS, Edge TTS, Google TTS.
• Субтитры: SRT/VTT, привязанные к словам.
• Языки: 40+, включая русский.
• CLI: abogen book.epub --voice en-US-AriaNeural --output book.m4b.

Установка

pip install abogen

Использование

abogen mybook.pdf --voice ru-RU-SvetlanaNeural --format m4b

Ссылки

• GitHub
• PyPI

• Пользователи обсуждают Abogen — GUI-обёртку над Kokoro TTS для генерации аудиокниг из текста.
• Качество голоса признаётся «ровным», но без эмоций и актёрской игры; для художественных книг это критично.
• Отмечены проблемы: долгие предложения обрезаются, «Mr.» читается с лишней паузой, видео-демо без звука в Firefox.
• Кто-то хочет API и автоматический пайплайн Calibre-Web → Abogen → Audiobookshelf, другие — формат DAISY и «голос Моргана Фримена».
• Итог: инструмент годен для личного использования и доступности, но пока не дотягивает до коммерческих аудиокниг.

Debian 13 «trixie» вышел 9 августа 2025 года после 2 лет разработки.
Поддержка — 5 лет (Security + LTS).

Десктопы: GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1, Xfce 4.20.
Пакетов: 69 830 (+14 100 новых, –8 840 устаревших, 44 326 обновлённых).
Размер: 403 ГБ, 1,46 млрд строк кода.
Ядро: 6.12 LTS; первый релиз с официальной поддержкой riscv64.
Архитектуры: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x.
i386 больше не поддерживается; armel последний релиз.

Ключевые обновления: Apache 2.4.64, Bash 5.2.37, BIND 9.20, GCC 14.2, LibreOffice 25.2, MariaDB 11.8, Nginx 1.26, OpenJDK 21, PHP 8.4, PostgreSQL 17, Python 3.13, Rust 1.85, systemd 257 и др.

Облако: образы для EC2, Azure, OpenStack, PlainVM, NoCloud с cloud-init и оптимизированным загрузчиком.
Live-образы: amd64/arm64, GNOME/KDE и др.; установка через Calamares или стандартный установщик.

• Debian 13 «Trixie» вышла: 63 % пакетов обновлены, поддержка 7 архитектур, включая RISC-V.
• i386 теперь только как «amd32»-совместимый, официального ядра/инсталлятора нет.
• Появился новый формат APT-репозиториев debian.sources, старый sources.list пока работает.
• 95 % пакетов достигают bit-for-bit воспроизводимости на amd64/arm64/riscv64.
• /tmp теперь tmpfs по умолчанию (до 50 % ОЗУ), но можно вернуть старое поведение.
• Пользователи хвалят стабильность, скорость обновления «stable→stable» и отсутствие snap.

LLM-разработка: краткий итог

• Мифы: LLM не делают код продакшн-готовым, требуют понимания задачи и хорошо структурированных кодовых баз. Использование LLM снижает навыки чтения документации и глубокого мышления.
• Агенты — это просто цикл «LLM → вызов локального API → ответ → LLM снова». Инструменты: навигация, редактирование, shell, поиск, MCP-серверы.
• Проблемы продуктов
  • Нестабильность: модели и цены меняются еженедельно.
  • Нет детерминизма, приходится постоянно обновлять промпты и MCP.
• Тесты
  • Python, TypeScript, Rust, Flutter, сложные рефакторинги — справляются.
  • Не справились: Token Field во Flutter (редкий компонент, сложное управление состоянием). Claude Opus 4.1 и GPT-5 провалили задачу.

Продукты

• GitHub Copilot

  • Плюсы: быстрое автодополнение, стабильность, низкая цена.
  • Минусы: слабые «агенты», нет контекста всего проекта.

• Claude Code Pro

  • Плюсы: лучший «умный» режим, хорошо работает в больших кодовых базах.
  • Минусы: дорого, медленно, иногда «теряется».

• Gemini CLI / Jules

  • Плюсы: бесплатный CLI, быстрый.
  • Минусы: слабые модели, ограниченные возможности.

• Kiro, Cursor, Windsurf

  • Плюсы: встроенные редакторы, удобные интерфейсы.
  • Минусы: дороже, часто баги, привязка к конкретному редактору.

Когда LLM полезны

• Лучшие языки: Python, TypeScript/JavaScript, Go.
• Лучшие задачи:
  • Репетитивный код, тесты, миграции.
  • Документация, примеры, объяснение legacy.
• Плохо:
  • Редкие фреймворки, сложные UI, архитектурные решения.
  • Надёжность и безопасность.

Вывод
LLM — полезный инструмент для рутины и прототипов, но не заменяет мышление и глубокое понимание.

• Многие спорят с тезисом «использовать LLM в коде тривиально»: на практике нужны месяцы, чтобы понять, что делегировать, как формировать промпты и управлять контекстом.
• Кто-то сравнивает LLM с «однорукими бандитами»: результат часто случаен, а «навыки» сводятся к удаче и базовому гуглению.
• Другие делятся успешным опытом: при жёсткой архитектуре, тестах и узких промптах Claude Code и аналоги дают 9/10 полезных патчей.
• Утверждение, что LLM «заставляют» выбирать мейнстек, опровергают разработчики на Clojure, D и других нишевых языках.
• Общий вывод: LLM — мощный инструмент, но требует экспериментов, критического ревью и понимания своих ограничений; без этого он быстро превращается в источник технического долга.

1984: словарь в 256 КБ

Представьте: вам поручили написать спеллчекер для MS-DOS-текстового редактора. У части пользователей всего 256 КБ ОЗУ — и туда должны поместиться редактор, сам документ, ОС и ещё словарь. Сегодня /usr/share/dict/words весит 2,5 МБ и содержит 235 000 слов; тогда это был нереальный объём.

Сжатие трие, вырезание редких слов, кастомная БД на гибком диске 360 КБ — всё это требовало месяцев инженерной работы и гениальных структур данных.

Сейчас

Загрузить словарь в хеш-таблицу — 3–5 строк на Perl или Python; поиск слова — встроенная операция. Всё.

• Пользователи жалуются, что встроенный спелл-чекер iPhone (и Android) часто хуже человеческого глаза и LLM: «No Guesses Found» при очевидных ошибках.
• Причины: жёсткие ограничения по скорости и памяти, отсутствие контекста, излишняя буквальность алгоритмов.
• Многие отказались от встроенных средств и ищут слова в Google или используют LLM.
• Участники вспоминают, как в 80-е спелл-чекер был прорывом, но требовал переключения дискет и выдавал лишь список ошибок без подсказок.
• Сегодня задача «проверить орфографию» тривиальна, а вот «предложить правильное» по-прежнему требует сложной инженерии.

• Выбор хранилища метаданных рабочих процессов оказался ключевым. Нужно было простое: чекпойнт состояния и восстановление после сбоя. Postgres выбрали за технические возможности, а не только за популярность и 40-летнюю проверку временем.

• Масштабируемые очереди
  Классическая таблица-очередь страдает от конкуренции: все воркеры пытаются взять одни и те же задачи. Postgres решает это через FOR UPDATE SKIP LOCKED: строки блокируются и пропускаются, если уже захвачены. Воркеры без конфликтов берут следующие N записей, позволяя обрабатывать десятки тысяч задач в секунду.

• Наблюдаемость
  Каждый шаг сохраняется, поэтому можно строить дашборды и фильтры. SQL позволяет писать сложные запросы напрямую; индексы по created_at, executor_id, status ускоряют выборки из миллионов записей без лишних затрат.

• Exactly-once для шагов с БД
  Обычно гарантируется «по крайней мере один раз», но если шаг меняет данные в той же транзакции, что и чекпойнт, Postgres обеспечит, что изменения зафиксируются ровно один раз даже после перезапуска.

• Пользователи хвалят DBOS за простоту миграции с graphile-worker и отсутствие необходимости менять инфраструктуру.
• Сравнения с Temporal, Azure Durable Functions, Inngest, Restate и Cloudflare: DBOS выглядит проще и легче, но Temporal/Cloudflare критикуют за сложность самостоятельного хостинга и высокую цену.
• Некоторые жалуются, что «сервер» DBOS (Conductor) не open-source, что ограничивает самостоятельное развёртывание.
• Планы по добавлению Java, C#, Go и поддержке сообщества уже анонсированы; Python и TypeScript уже поддерживаются.
• Отмечена возможность комбинировать DBOS с Dagster/Oban/pgflow для более сложной оркестрации.

• Несколько лет назад мне выпал шанс выбрать async‑first, типизированный Python‑фреймворк для веба. Я взял Litestar — без хайпа и ракет в твитах — и не пожалел: уже около 18 месяцев все мои новые рабочие проекты на нём.

• Даже если вы пишете асинхронные веб‑приложения на Python, вы могли пройти мимо Litestar. Хочу это исправить.

• Вкус демо: простой файл

  from litestar import Litestar, get
  
  @get("/greet")
  async def greet(name: str) -> str:
      return f"Hi, {name}!"
  
  app = Litestar([greet])
  

  Запускаете через litestar run или любой ASGI‑сервер. /greet?name=Bob вернёт «Hi, Bob!». Без name — HTTP 400: параметр обязателен. Да, похоже на FastAPI и на знакомые по Spring/ASP.NET MVC подходы с аннотациями — и FastAPI тоже так умеет. Но у Litestar есть свои сильные стороны.

• Про название: раньше проект назывался Starlite, потому что изначально строился на Starlette (как и FastAPI). Позже зависимость убрали, а чтобы не путать со Starlette, в релизе 2.0 (2023) переименовали в Litestar.

• Масштабирование кода, а не трафика:

  • Django плохо «масштабируется вниз»: «правильный» старт быстро разрастается в десяток файлов и папок. Однофайловые трюки работают, но против шерсти.
  • Микрофреймворки — наоборот: стартуют в одном файле, но по мере роста кода расползаются и начинают мешать.
  • В FastAPI маршруты обычно вешаются декораторами на объект приложения. Это удобно в одном файле, но при разбиении на модули ведёт к циклическим импортам. Решение — «вторичные» реестры маршрутов (APIRouter, blueprint): нужны, потому что декораторы привязаны к app. Litestar же позволяет описывать обработчики отдельно и передавать их приложению списком, что естественно масштабируется от одного файла к структуре проекта без костылей.

• Обсуждение сравнивает FastAPI, Litestar, Starlette и Django для построения бекендов: многие отмечают, что FastAPI удобен для простых сервисов, но усложняется в больших кодовых базах, тогда как Litestar воспринимается более продуманным и быстрым для сложных API.
• Несколько участников хвалят Litestar: высокая скорость, асинхронность, first-class msgspec, контроллеры для вложенных роутов, кеширование, плагины (в т.ч. для HTMX), и развивающийся Advanced Alchemy; отмечают, что у него больше одного мейнтейнера.
• Часть разработчиков предпочитает Starlette как легковесную основу без «всей кухни», а Django ценят за ORM; обсуждают плюсы/минусы SQLAlchemy и альтернативы (peewee), а также идею разделять модели API и БД с самого начала.
• Критика FastAPI касается структуры кода, управления зависимостями и разрыва между туториалами и реальными практиками; при этом приводят ссылки на репозитории-референсы, где показано, как масштабировать FastAPI.
• Запросы и сомнения: как обрабатывать ошибки при стриминге, как деплоить (NGINX Unit упоминался как «капризный»), и нужен ли референс-проект Litestar; приводят litestar-fullstack как пример.
• В целом тон дискуссии: многие либо мигрируют с FastAPI на Litestar, либо довольны Starlette; документацию нового поколения фреймворков часто критикуют за недостаток строгого API-референса и переизбыток туториалов.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

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

Но свои публиковать некомфортно: мои алиасы, кастомизации и решения кажутся слишком личными. Почему — точно не знаю.

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.

• Самая быстрая и надежная open-source платформа для трейдинга. Торгуйте любым классом активов в одном месте. Событийные бэктесты на любых исторических данных. Лайв-трейдинг без изменений кода.

• Решения:

  • Open Source — репозиторий на GitHub.
  • Cloud Platform — облачная платформа Nautilus Cloud.

• Компания: О нас, Команда, Партнеры, Правовое.

• Ресурсы: Документация, Образование (скоро), Блог, Начать, Discord.

• Платформа для алгоритмической торговли:

  • Интеграция данных: загрузка кастомных/сырых данных в формат parquet.
  • Построение стратегий: Python API, стрим до 5 млн строк/с, больше RAM.
  • Аналитика: моделирование рынка с наносекундной точностью, событийные результаты.
  • Быстрая итерация: экстремально быстрые бэктесты.
  • Лайв-торговля: надежный запуск, паритет кода бэктест/лайв.
  • Исполнение: высокопроизводительное low-latency исполнение на Rust.

• Классы активов:

  • Крипто: спот, фьючерсы, деривативы, опционы; нормализованные инструменты.
  • Фьючерсы: активация/экспирация, базовые активы, биржи, лоты, множители.
  • Акции: шорт-ограничения, кэш/маржин, круглые/нестандартные лоты, мульти-биржа.
  • Опционы: Греки и сигналы на внутренней шине; точные спецификации контрактов.
  • FX: спот и деривативы, базовая/котировая/расчетная валюты; биржи и ECN.
  • Беттинг: спортивные и альтернативные рынки, полный стакан, адаптер Betfair.

• Безлимитные бэктесты стратегий, площадок и рынков. Стратегии для любых инструментов и веню.

• Ключевые возможности:

  • Простые модульные компоненты: Clock, Cache, MessageBus, Portfolio, Actors.
  • Точное время: наносекундные часы для бэктеста и лайва.
  • Быстрая конфигурация: торговля на множестве веню и параметров без изменения кода стратегии.
  • Продвинутые ордера: post-only, reduce-only, OCO, OTO и др.
  • Интеграции API: быстрый коннект новых бирж и провайдеров данных.
  • Высокая производительность: ядро на Rust.

• Партнеры: Databento, OKX.

• Выразите идеи стратегий через чистый, мощный API:

  • Python API: совместим с ML/AI-фреймворками и любым Python-кодом.
  • Любые типы стратегий: настраиваемые компоненты для любой идеи.
  • Конфигурации стратегий: упрощение настройки.

• Обсуждение крутится вокруг алгоритмической торговли и платформ, с акцентом на рисках и иллюзии «успешных» стратегий: многие отмечают, что без информационного или инфраструктурного преимущества (HFT) торговля похожа на подбрасывание монетки.
• Несколько комментаторов поделились опытом: высокие проценты «успешных» сделок с редкими, но разрушительными просадками; out-of-sample провалы ML/бэктестов; необходимость чёткой «edge» (ребейты, латентность, маркет-мейкинг, арбитраж).
• Выделяют, что разработка OMS/интеграций и бэктестера — «лёгкая часть»; основная сложность — поиск и валидация стратегий и управление рисками (упоминание негативной асимметрии, LTCM, Карвер).
• Практический совет многим — предпочесть долгосрочное инвестирование (индексные фонды, buy-and-hold) вместо активного трейдинга; ряд участников подтвердили, что это повысило их результаты и снизило стресс.
• Обсуждается платформа Nautilus: впечатляющая полнота (особенно risk engine), но интеграция с брокерами (IBKR и др.) и регуляторные проверки сложны; указывается на список интеграций и сравнение с LEAN/QuantConnect.
• Скепсис к розничной алготорговле: необходимость капитала/инфраструктуры, риск банов у брокеров, низкомаржинальные «нейтральные» портфели в HFT требуют больших ресурсов; многие считают, что в одиночку стабильно зарабатывать почти нереально.
• Встречаются идеи обучающих симуляторов и простых целей (например, $1/день как POC), но общий тон — трезвый: дисциплина риск-менеджмента важнее «волшебных» моделей, а охота за стратегиями — глубокая и дорогостоящая нора.

Добро пожаловать на 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/параллельных подходов, но признают их практические ограничения.

• State-of-the-art модель TTS до 25 МБ 😻
• Пропустить к содержимому
• Навигация, вход, настройки внешнего вида
• Продукты: Copilot, Spark, Models, Advanced Security, Actions, Codespaces, Issues, Code Review, Discussions, Code Search
• Исследовать: Почему GitHub, все функции, документация, навыки, блог
• Решения по размеру компании: Enterprise, для команд, стартапов, НКО
• По задачам: DevSecOps, DevOps, CI/CD и др.
• По индустриям: здравоохранение, финансы, производство, гос сектор
• Ресурсы: темы (ИИ, DevOps, безопасность, разработка), курсы, события, книги, истории клиентов, партнёры, аналитика
• Open Source: Sponsors, ReadME Project
• Репозитории: Темы, Тренды, Коллекции
• Enterprise: платформа, допы — Advanced Security, Copilot for business, поддержка
• Цены
• Поиск кода и репозиториев, советы по синтаксису
• Обратная связь (с email), отправка/отмена
• Сохранённые поиски: создание/управление, документация по синтаксису
• Вход/регистрация
• Сообщения о перезагрузке сессии и переключении аккаунтов
• KittenML/KittenTTS (публичный), уведомления, форки

• KittenTTS (25 МБ, Apache-2.0) генерирует речь оффлайн на CPU, но звучит механически и путает цифры.
• На i9-14900HX 225 символов синтезируются за 5,5× реального времени, но латентность ~315 мс.
• Установка требует кучи зависимостей, поэтому «25 МБ» быстро превращаются в гигабайты.
• Для качественной речи пользователи рекомендуют F5-TTS, Fish-Speech или Piper-TTS; для STT — Whisper.
• Сообщество просит ONNX-порт, обучение на других языках и открытые данные.

marimo — новый open-source Python-ноутбук, в котором программа представлена графом потока данных. Это снимает главные боли Jupyter: скрытое состояние, невоспроизводимость, невозможность повторного использования и сложную поддержку.

Почему старый формат не подходит

• Воспроизводимость. Исследования 2019–2020 гг. показали: только 4–24 % ноутбуков на GitHub можно перезапустить без ошибок и получить те же результаты. Причина — скрытое состояние: удаление или переупорядочивание ячеек ломает выводы.
• Интерактивность. В Jupyter интерактивен процесс, но не сами данные: выделение точек на графике не возвращает датафрейм.
• Поддержка и переиспользование. Файл .ipynb — это JSON-блоб, не валидный Python-код; сложно версионировать в Git и переиспользовать как модуль или пайплайн.

Как marimo решает задачу

• Каждый ноутбук — корректный Python-скрипт и модуль.
• Граф зависимостей ячеек строится статически; изменение одной ячейки автоматически перезапускает только зависимые.
• Реактивность: обновление переменной мгновенно отражается во всех графиках и виджетах.
• Один файл можно экспортировать как приложение или запускать без ядра Jupyter.

• Пользователи хвалят marimo за реактивное исполнение, «песочницу» uv и лёгкий обмен с коллегами.
• Сторонники Jupyter считают, что «restart kernel & run all» решает проблему воспроизводимости, но критики отвечают: это требует дисциплины и не работает при тяжёлых вычислениях.
• Некоторые видят в ноутбуках лишь инструмент разведки и предлагают после исследования переносить код в обычные .py-файлы.
• Участники сходятся, что метаданные зависимостей и чистые DAG-подобные модели вычислений могли бы улучшить ситуацию.

Открытые модели OpenAI

Продвинутые модели с открытыми весами для любого кейса и запуска где угодно.

Ссылки:

• Загрузить на Hugging Face
• Исходники на GitHub
• Попробовать демо

Модели:

• gpt-oss-120b — крупная модель для дата-центров и мощных ПК/ноутбуков.
• gpt-oss-20b — средняя модель, работает на большинстве ПК/ноутбуков.

Преимущества:

• Разрешительная лицензия: Apache 2.0 — свободная разработка, без копилефта и патентных рисков; подходит для экспериментов, кастомизации и коммерческого использования.
• Для агентных задач: сильное следование инструкциям и работа с инструментами в ходе рассуждений (веб-поиск, запуск Python-кода).
• Глубокая настраиваемость: выбор уровня «усилия рассуждений» (низкий/средний/высокий) и полно-параметрический финтюнинг под ваш кейс.
• Полная «цепочка рассуждений»: доступна для удобной отладки и повышения доверия к ответам.

Интерактивное демо:

• Простой playground для запуска обеих моделей в браузере.

• Обсуждение посвящено выходу открытых моделей OpenAI gpt-oss (20B и 120B), которые по бенчмаркам близки к o3/o4-mini и местами обгоняют открытые лидеры; многие отмечают, что 20B уже реально запускается локально на Mac/мобильных устройствах.
• Пользователи делятся первыми впечатлениями и ссылками на обзоры/модель-карты, отмечая конкурентную производительность, совместимый токенайзер и адекватное лицензирование; есть поддержка в llama.cpp, Ollama, LM Studio, Harmony формат ответов и растущая роль Rust в инструментах OpenAI.
• Скорости инференса сильно варьируются: от очень быстрых облачных провайдеров (Cerebras/Groq на OpenRouter) до заметных задержек локально при больших контекстах; производительность зависит от GPU/платформы и параметров квантования.
• Отмечают стратегический сдвиг OpenAI к модели Meta: открытые веса как средство захвата экосистемы и снижения порога входа; звучат предположения, что релиз предвосхищает скорый анонс ещё более сильной закрытой модели.
• Сообщество обсуждает экономику: гибридные пайплайны (локально — простые задачи, в облако — сложные), возможность заменять платные подписки локальным запуском, и общий тренд в пользу OSS при минимальной разнице в качестве.
• Есть критика: у 120B встречаются галлюцинации на фактах, часть пользователей недовольна агрессивной безопасностью/отказами, отсутствием оптимизаций под RTX 50, а также неполной мультимодальностью.
• В целом настроение позитивное: многие благодарят за «настоящий» открытый релиз с сопутствующими инструментами и ожидают независимых бенчмарков, которые могут закрепить лидерство gpt-oss среди текстовых открытых моделей.

I was fresh at university, around 2001, and our mathematics professor introduced us to Python with NumPy/SciPy as an alternative to the commercial math tools. There aren't many events that changed my career as much as that. Being exposed only to compiled languages before that, it