Hacker News Digest

Cloudflare и VoidZero совместно с Максом Швенком из Owner.com работают над tsrs — портом компилятора TypeScript на Rust, который развивается в составе инструментальной цепочки Oxc. Это не форк: команда TypeScript сохраняет полный контроль над языком, а порт обязан строго следовать её решениям, иначе со временем станет несовместимым. Ранние замеры обещают до 8 раз большей скорости и примерно на 70% меньше памяти по сравнению с TypeScript 7.0 при том же числе обработчиков проверки типов. При этом TypeScript 7.1 beta уже до 2.5 раз быстрее 7.0, и часть оптимизаций пришла из tsrs.

Попробовать экспериментальную версию можно через npm install tsrs и npx tsrs. Rust выбран не только ради скорости: важна и сборка в WebAssembly, что упрощает запуск полноценной среды разработки прямо в браузере. По умолчанию tsrs использует адаптивную конфигурацию, зависящую от типа машины: она потребляет больше памяти, но работает ещё быстрее. Авторы подчёркивают, что раньше масштабные порты почти не удавались, а теперь передовые ИИ-модели способны выполнять их за считанные дни.

Процесс сопровождается автоматикой: агенты ежедневно проверяют изменения, собирают диффы и заводят задачи, а ночью прогоняют тесты Next.js против Vinext, выявляя расхождения. Тот же подход применят к TypeScript, стараясь не вносить отличий в поведение и возвращая улучшения производительности в кодовую базу TypeScript на Go. Пока есть расхождения, например порядок вывода диагностик, но к стабильному релизу их сведут к минимуму. В планах — более глубокая интеграция tsrs в стек Cloudflare, в том числе для типозависимых правил линтера в Oxlint.

tsrs демонстрирует до 8-кратный рост скорости и снижение потребления памяти на ~70%. Эти показатели достигнуты не только за счет Rust, но и благодаря алгоритмическим оптимизациям, которые планируют перенести в TypeScript 7.1. Основным драйвером порта стала необходимость легкого компилятора для WASM-песочницы, где Rust предпочтительнее тяжелого Go-runtime. При этом арена-модель памяти в tsrs вызывает опасения, так как скрывает unsafe-код и может быть небезопасной. Также отмечается, что AI-генерация порта ускоряет разработку, но требует тщательного ревью из-за риска архитектурных ошибок. tsrs хорошо масштабируется при многопоточном запуске и поддерживает инкрементные проверки, хотя bun остается эффективнее по общим метрикам.

Whistle — это открытая модель распознавания речи размером 16,9 МБ, которая работает на CPU без зависимостей и использует тот же C++ движок, что и модель Needle. Она транскрибирует аудио до 30 секунд на семи языках: английском, немецком, французском, испанском, итальянском, нидерландском и польском, определяя язык автоматически, если он не задан явно. Первый токен появляется за 11 мс, а вся обработка происходит локально на устройстве — аудио никогда не покидает его. Помимо транскрипции, Whistle выдаёт временные метки для каждого слова с вероятностью и генерирует речевые эмбеддинги — по одному вектору на каждые 80 мс аудио, полученные из выхода энкодера.

Архитектура Whistle делит обработку на энкодер и декодер. Аудио преобразуется в 80-полосные лог-мел спектрограммы с окном 25 мс и шагом 10 мс, затем проходит через свёрточный стебель, уменьшающий длину с 3000 до 375 кадров (по одному на 80 мс). Энкодер состоит из восьми блоков Simple Attention, общих с Needle, использующих mHC residual lanes и Monarch Hadamard MLP вместо стандартного FFN. Декодер содержит восемь Laddered Simple Attention блоков с гейтированным кросс-вниманием к энкодеру, где ключи и значения проецируются один раз при загрузке аудио и переиспользуются для всех лучей. Декодирование выполняется beam search с шириной 5, длинормализованным лог-вероятностным скором и смещением по ключевым словам через Aho-Corasick автомат. Модель поддерживает вывод текста, языка, латентности первого токена и скорости декодирования, а также расширенные опции вроде принудительного указания языка или подсказки ключевых слов. Установка возможна через pip, а готовые бинарники доступны для 17 платформ, включая мобильные устройства, микроконтроллеры и браузер через WASI. Вес модели и исходный код размещены на Hugging Face и GitHub.

Whistle — компактная модель для локальной работы на CPU без зависимостей с низкой задержкой (первый токен за 11 мс), подходящая для встраиваемых устройств и веб-приложений. Основные характеристики и ограничения: * **Точность:** В режиме свободного распознавания точность низкая (70/170 против 168/170 у Qwen). Однако при использовании как детектора шаблонов (обучение сети на сгенерированных фразах) точность возрастает до 164/170. * **Языки и акценты:** Хорошо работает с английским языком и различными акцентами (индийским, хорватским, испанским), превосходя стандартные системы и встроенное распознавание iOS, особенно в технических терминах (ASP.NET, .NET 10.0). Плохо работает с испанским, не поддерживает норвежский, японский и другие языки. * **Технические недостатки:** Отсутствует поддержка потоковой транскрипции в реальном времени. Ограничение длины аудио — до 30 секунд; при обработке длинных файлов модель может зацикливаться на одной фразе (например, «Thank you.»). * **Специфика:** Не подходит для распознавания речи людей с речевыми нарушениями. Альтернативы: * ZWhispr: для локальных систем с 8 ГБ GPU, обеспечивает высокую точность за счет трех SOTA моделей. * Yapsnap: бесплатный вариант для CPU без GPU с поддержкой 10 языков, потоковым режимом, диаризацией и временными метками.

MicroLLM lab позволяет запускать небольшие языковые модели (25–360 млн параметров) прямо в браузере с ускорением через WebGPU, обеспечивая конфиденциальность и отсутствие серверных затрат. Модели квантованы в формате Q4 (4 бита на параметр), что снижает их размер в 4 раза — например, модель в 100 млн параметров занимает ~50–84 МБ в памяти браузера. Это позволяет использовать их для быстрой триажи запросов, фильтрации спама или определения намерений за миллисекунды, решая, нужен ли дорогой облачный LLM.

Lab предлагает загружать модели через IndexedDB, тестировать их в чат-панели и проводить бенчмарки в отдельной вкладке, генерируя сертификаты производительности. Без WebGPU (на CPU через WASM) скорость составляет 8–20 токенов/секунду, тогда с аппаратным ускорением — 100–300+ токенов/секунду (10–20× быстрее). Доступны модели вроде PetitGPT (125M), SmolLM2 (135M/360M) и MiniMind2 (26M/104M), все под лицензией Apache-2.0. Для работы требуется современный браузер с поддержкой WebGPU (Chrome 113+, Edge 113+, Brave или Firefox с флагом) и включённым аппаратным ускорением.

Обсуждение подтверждает, что микромодели действительно работают в браузере быстро, но выявляет существенные проблемы: перегруженный UI, ограниченная поддержка языков, несовместимость с Firefox и частые галлюцинации моделей, а также подчёркивает потенциал стандартизации через Web Models API.

• Пользователи отмечают, что запуск моделей в браузере происходит очень быстро, что делает их подход идеальным для быстрых демонстраций без серверной части.

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

• Большинство отзывов указывают на плохой дизайн интерфейса: мелкий шрифт, перегруженная страница и непонятный футер затрудняют использование даже простого продукта.

• Тесты показывают, что приложение работает в Chromium, но падает в Firefox с ошибкой «GPUShaderStage is not defined», что свидетельствует о проблемах совместимости WebGPU.

• Модели, представленные в MicroLLM Lab, обучены только на английском, запросы на других языках, например немецком, просто отдаются без обработки.

• Некоторые участники демонстрируют, что с помощью WebGPU можно запускать более крупные модели в виде одностраничных HTML‐приложений, даже в изолированных (air‐gapped) средах.

• Совет: Для упрощения доступа к локальным моделям в браузерах рекомендуется следить за развитием стандарта Web Models API, который предлагает единый интерфейс для запуска открытых весов.

Фото-реактивная LED-скульптура Phyllotaxis воссоздаёт природный узор, встречающийся в подсолнухах и кактусах — спиральную структуру, основанную на золотом сечении. Автор написал простой код, который распределяет точки по радиусу, поворачивая каждую на множитель 1.618..., создавая визуально естественный паттерн. После визуализации в цифровом виде он перенёс его в физический мир: с помощью CadQuery и 3D-печати сформировал 89 ячеек, каждая из которых содержит RGB-светодиод Neopixel. Внутренние стенки ячеек вырезаны так, чтобы оставить прочную оболочку, а в центре каждой — отверстие под диод.

Пайка 89 светодиодов заняла месяцы из-за сложности монтажа — контакты расположены под самими чипами, что требует горячего воздуха. Вдохновлённый встречей на Recurse Center, автор завершил сборку с помощью друга и переписал прошивку на Rust под ESP32. Устройство теперь доступно через веб-интерфейс: посетители могут загружать свои анимации через WebAssembly. Для рассеивания света использована тонкая шелковая бумага, приклеенная снизу — она придаёт узору мягкость и органичность. Автор планирует улучшить проект: заменить светодиоды на более удобные для пайки, использовать PCB-производство, добавить защитный акрил и магнитные крепления.

Обсуждение дополняет статью практическими советами по сборке и настройке проекта. Предлагаются варианты автоматической пайки светодиодов на фабрике и контраргументы в пользу ручной пайки. Раскрывается метод реализации пяти‐кратной симметрии через вращение точек. Отмечаются проблемы с хрупкостью бумажного диффузора и способы их решения. Делются рекомендациями по увеличению площадок пайки, использованию CadQuery для органического моделирования и возможностям перенести проект на ESP32 с WLED. XRG советует передать сборку светодиодов фабрике, чтобы сэкономить время и снизить риск повреждения. asdfasdfe считает, что ручная пайка компонентов тривиальна и не требует дополнительных расходов. Для достижения пяти‐кратной симметрии автор вращает сгенерированные точки пять раз и использует обработку в Processing. Репозиторий теперь имеет MIT‐лицензию, что облегчает модификацию и повторное использование кода. Бумажный диффузор из мульберри‐бумаги оказался хрупким, а клей может просачиваться, вызывая неравномерную светопередачу. Автор планирует улучшить крепление и уменьшить риск протекания клея. Для удобства пайки советуют делать площадки SMT немного больше, чтобы обеспечить место для впитывания припоя. Neopixel‐LED (5050) легко паять вручную благодаря боковым выводам. QFN‐чипы тоже возможны при достаточной практике. CadQuery отлично подходит для создания органических форм. Пользователи интересуются аналогичными инструментами для проектирования печатных плат. Можно воспроизвести эффект на ESP32 с WLED, разместив 2‐D карту светодиодов. Это делает проект более доступным для хобби‐энтузиастов. Филлотаксис‐спирали, основанные на золотом угле, обеспечивают равномерную плотность точек, избегая искажения, характерного для концентрических колец. Важно правильно балансировать отклик на транзиенты и сглаживание, чтобы избежать дрожания светодиодов. Использование тонкой мульберри‐бумаги под прозрачной печатью дает хороший диффузор и может имитировать эффект витража, если подобрать подходящий рисунок. Автор добавил MIT‐лицензию в репозиторий, что облегчает модификацию проекта. Многие участники выразили желание собрать собственную версию и адаптировать её под свои нужды. Создание качественного финального вида требует тщательной работы с освещением и отделкой. Быстро собрать прототип легко, но достичь профессионального уровня сложно.

Anubis — это система защиты веб-сайтов от агрессивного скрапинга со стороны ИИ-компаний, использующая механизм Proof-of-Work, вдохновлённый Hashcash. При небольшом трафике нагрузка пренебрежимо мала, но при массовом скрапинге она резко увеличивает стоимость таких операций, делая их экономически невыгодными. Разработка заняла год, поскольку требовалось тщательно оптимизировать реализацию под WebAssembly, чтобы обеспечить достаточную производительность вычислений прямо в браузере пользователя без значительного влияния на легитимный трафик.

Цель Anubis — временное решение, позволяющее выиграть время для разработки более точных методов обнаружения headless-браузеров, например, через анализ особенностей рендеринга шрифтов. В будущем планируется полностью отказаться от показа капчи-подобных страниц обычным пользователям, направляя проверку только на подозрительный трафик. Система требует поддержки современных JavaScript-функций, поэтому пользователям с плагинами вроде JShelter, блокирующими такие возможности, необходимо отключить их для корректной работы защиты. Anubis не блокирует доступ полностью, но делает массовый сбор данных слишком дорогим для злоупотребляющих сторонами.

Обсуждение дополняет статью практическими замечаниями: необходимость fallback‐механизмов при отключённом WebAssembly, экономическая природа защиты, инструменты тестирования совместимости, готовые расширения для ускорения PoW, а также вопросы о применимости подхода к старым браузерам и реальной эффективности предположения о вычислительных ограничениях скреперов. **Fallback и старые браузеры:** Пользователям с отключённым WebAssembly нужно явное уведомление, аналогичное сообщению при отключённом JavaScript. Альтернативой служит JavaScript‐fallback — транспиляция WASM обратно в JS для совместимости. Однако старые браузеры на Smart TV могут не поддерживать WASM и будут вынуждены использовать JS‐fallback, что потенциально открывает путь скреперам к обходу более тяжёлого алгоритма. **Экономика защиты:** Защита от ботов — экономическая задача: достаточно повысить стоимость скрейпинга, чтобы он перестал быть прибыльным, а не делать его полностью невозможным. Скрейпинг вреден даже для статического HTML: боты собирают контент независимо от динамичности сайта. **Инструменты и оптимизации:** Для базового WASM рекомендуется целевой триплет Rust `wasm32v1-none` (ограничение до `#[no_std]`, упрощённая совместимость). Проверить поддержку WebAssembly можно через онлайн‐детектор wasm-feature-detect.surma.technology. Предлагается предоплачивать PoW через систему кредитов/токенов по модели Privacy Pass, чтобы избежать ожидания в реальном времени. Уже существуют браузерные расширения на WebAssembly и WebGPU, ускоряющие решение Anubis‐PoW. **Критика подхода:** Предположение об ограниченности скреперов вычислительными ресурсами ставится под сомнение: современные скрейперы могут использовать GPU и специализированные ускорители, что снижает эффективность чисто CPU‐ориентированных PoW. Также требует уточнения формула, по которой увеличение сложности на 1 бит даёт 1024‐кратный рост.

В 2025 году SIMD в Rust продолжает развиваться, предлагая значительный прирост производительности до 64x для операций с u8 на современных процессорах. Основная проблема - фрагментация наборов инструкций: ARM использует обязательный NEON (128 бит), WebAssembly - 128-bit packed SIMD, а x86 имеет сложную иерархию от SSE2 до AVX-512 (512 бит). Для x86 разработчики выбирают между указанием target-cpu (например, x86-64-v3) и использованием function multiversioning для поддержки различных процессоров.

В Rust существует четыре подхода к SIMD: автоматическая векторизация (самый простой), продвинутые итераторы, портируемые абстракции и сырые интринсики. В то время как ARM стандартизировал NEON, а WebAssembly требует компиляции двух бинарных файлов, x86 остается самой сложной платформой из-за множества расширений и необходимости обеспечения обратной совместимости.

• Обсуждение показало, что Rust пока не может предложить стабильный и удобный способ работы с SIMD, в отличие от C# и C++.
• Основная причина — std::simd всё ещё в nightly, а стабильная альтернатива отсутствует.
• Участники также отметили, что даже в ночной ветке API нестабилен и может измениться, что делает его использование в production-окружениях проблематичным.
• Некоторые участники выразили обеспокоенность тем, что отсутствие стабильной SIMD-поддержки может отпугнуть потенциальных пользователей Rust, особенно в областях, где эффективное использование SIMD критично.
• В то же время, другие участники подчеркнули, что Rust всё ещё молодой язык и что сообщество может в конце концов решить эту проблему, как это было с другими функциями в прошлом.

В .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).

Разработчик Mitchell Hashimoto анонсировал libghostty — библиотеку для встраивания полнофункционального терминала в любые приложения. Первым компонентом станет libghostty-vt: легковесная библиотека без зависимостей (включая libc) для парсинга терминальных последовательностей и управления состоянием терминала. Она извлечена из ядра Ghostty и предлагает оптимизированную обработку Unicode, поддержку SIMD и совместимость с продвинутыми протоколами вроде Kitty Graphics.

Проблема в том, что многие проекты (редакторы, веб-консоли, хостинги) реализуют эмуляцию терминала с нуля, часто с ошибками и неполной функциональностью. Libghostty-vt устраняет эту избыточность, предоставляя единое корректное и быстрое решение. Библиотека будет портирована на macOS, Linux, Windows, embedded-устройства и WASM, что шире, чем охват самого Ghostty.

• Пользователи высоко оценивают Ghostty за его производительность, минималистичный дизайн и поддержку Zig, но отмечают отсутствие некоторых ключевых функций, таких как поиск (Cmd+F) и проблемы с рендерингом шрифтов.
• Многие выражают восхищение разработчиком Mitchell Hashimoto, его предыдущими проектами (Vagrant) и его подходом к созданию простых и эффективных систем.
• Анонс библиотеки libghostty вызвал интерес для использования в embedded-сценариях (игры, кастомные приложения, веб-терминалы) и как потенциальная замена существующим библиотекам.
• Некоторые пользователи столкнулись с проблемами совместимости, особенно с tmux и графическими протоколами, что мешает им полностью перейти с iTerm2 или других терминалов.
• Обсуждаются технические детали, такие как лицензирование (MIT vs LGPL), поддержка Unicode и сравнение с другими терминалами (Kitty, Alacritty, WezTerm).

Создал две карточные игры на Go: без LLM — 3 месяца, с LLM — 3 дня

Truco без LLM (3 месяца)

• Начал 18 июня 2024, выбрал Truco — любимая игра детства.
• Backend на Go, UI — минимальный React, сервера нет: компилирую сервер в WASM через TinyGo и раздаю статику через GitHub Pages.
• Без LLM пришлось всё выяснять вручную: 3 месяца экспериментов.
• Игра живёт без рекламы и денег, но люди всё ещё играют.

Escoba с LLM (3 дня)

• Через год решил проверить, как LLM ускорит процесс.
• Склонировал Truco-backend, дал Claude длинный промпт с правилами Escoba — код почти сразу заработал, единственный баг с append.
• Frontend всё равно занял несколько дней: React + WASM-отладка.

Как повторить

1. Backend
   • Структура GameState, CalculatePossibleActions, RunAction, бот.
   • Компилируй в WASM: tinygo build -o main.wasm -target wasm .
2. Frontend
   • Создай игру, отрендери состояние, дай игроку выбрать действие, вызови бота.
3. Шаблоны
   • Форкни Tic-Tac-Toe:
     backend | frontend
   • Демо: играть

• Основной тезис: «написание кода никогда не было узким местом» вызвал споры; кто-то считает, что сложная механика, баланс и полировка требуют больше времени, другие — что код всё же тормоз.
• Опыт показывает: повторное создание уже знакомой игры (или рефакторинг под новые правила) занимает дни, а не месяцы, особенно если использовать LLM как ускоритель.
• Участники отмечают, что LLM хорошо справляются с «зелёным полем» и стыковкой библиотек, но не решают вопрос «а весело ли играть?» — это всё ещё требует живых тестеров и дизайнерской интуиции.
• Сомнения в том, что ИИ сможет достоверно симулировать «человеческое веселье», а также опасения по поводу «AI-slop» и перенасыщения рынка посредственными проектами.

ASCII-вывод в D2 0.7.1
Файлы с расширением .txt теперь рендерятся в ASCII. Пример: при сохранении .d2-файла Vim-плагин мгновенно показывает ASCII-превью.

Для документации кода
ASCII-диаграммы удобно вставлять в комментарии: выделите блок d2, плагин заменит его ASCII-версией.

Unicode или чистый ASCII
По умолчанию используются символы Unicode, но флаг --ascii-mode=standard вернёт строгий ASCII.

Ограничения (альфа-версия)

• Без стилей: animated, font, темы не поддерживаются; цвета в терминале — возможно позже.
• Неравномерные отступы из-за дискретной сетки.
  Сообщайте о багах: github.com/terrastruct/d2/issues.

Попробуйте сейчас
Откройте пример в D2 Playground.

• Представлена новая альфа-функция D2: рендеринг диаграмм в ASCII.
• Пользователи сравнивают D2 с Mermaid, отмечают лучший внешний вид и CLI без Chromium, но упрекают в отсутствии GitHub-рендеринга и сложных grid-раскладок.
• Появились вопросы о браузерной офлайн-работе, vim-/emacs-плагинах, Python-обёртке и возможности ручной подгонки элементов.
• Автор подтвердил, что WASM-версия (d2.js) уже работает в браузере, но пока неанонсирована; официальный релиз и поддержка PR-диаграмм ожидаются позже.